End-to-end case studies

Real exam scenarios often touch several domains at once. Each case study below gives a brief, asks you to design a solution, then walks through a model answer. Try each one on paper before reading the answer; the reasoning matters more than matching every detail.

Case study 1: High-volume retail support

Brief. An online retailer receives 80,000 customer emails a day in English and French. It wants Claude to classify each email, look up the order, and draft a reply that a human agent approves. Drafts must appear within 10 seconds of an agent opening a ticket. The budget is tight, and leadership wants proof the system is accurate before launch. Design questions. Which models? Which API modes? Where does caching help? How do you prove accuracy? What could go wrong?

Model answer.

Two stages. Classification runs ahead of time on arrival, on Haiku, through the Batch API in hourly batches (no one is waiting; 50% off). Drafting runs on demand when an agent opens the ticket, on Sonnet with streaming so text appears immediately.

Tools. orders_get_order and crm_find_customer with strong descriptions and strict: true. The drafting call fetches order details through tools rather than pasting the whole order history. Caching. The reply guidelines, tone guide, and policy excerpts form a stable system prefix with a cache breakpoint. Continuous traffic keeps the 5-minute cache warm.

Human in the loop. Agents approve every draft, which also produces labelled data (approved, edited, rejected) for evaluation. Evaluation. Before launch: 500 historical emails with known categories (code-graded) and 200 with human-written gold replies (LLM-judge with a binary rubric, calibrated against two human graders). After launch: track edit rate and rejection rate by category. Risks. Injection in customer emails (treat as untrusted, no refund tools in the drafting step), French quality (separate eval slice), and cost drift (log usage per stage).

Domains touched: 1, 2, 4, 5, 6, 7, 8.

Case study 2: Contract review inside Google Cloud

Brief. A law firm wants associates to upload NDAs and receive a review against the firm's 40- point playbook, with every flagged issue tied to a clause. Documents must stay within the firm's Google Cloud environment. Volume is about 60 a day. Partners worry about the model "inventing" clauses. Model answer.

Platform. Claude through Google Cloud, with GCP identity and the firm's project; confirm that every feature used (citations, caching, the chosen model) is available there. Prompt structure. The 40-point playbook is a stable cached prefix. The NDA goes in the user turn as a document block, followed by the instruction to evaluate each playbook point. Grounding. Citations enabled on the document so each finding carries the exact clause text and location. The prompt instructs Claude to report "not addressed in the document" rather than infer.

Output. A structured result per playbook point: status (compliant, deviation, missing), clause reference, quote, risk level, suggested language. Note that citations cannot be combined with structured outputs in one request, so either use two calls (cited analysis, then structuring) or rely on quotes inside the structured output plus a code check that each quote appears verbatim in the document.

Verification. Code checks that every quoted clause exists in the source text. Any mismatch is flagged for the associate.

Evaluation. 50 historical NDAs reviewed by partners as the gold set; measure recall of real issues and false-positive rate.

Model choice. Low volume and high stakes favor a more capable model at higher effort; cost is small at 60 a day.

Domains touched: 2, 4, 5, 6, 7.

Case study 3: Automated dependency upgrades with Claude Code

Brief. A platform team maintains 120 microservices. Every month, dependencies fall behind. They want Claude Code to open upgrade pull requests automatically, run tests, and fix simple breakages, without ever pushing to main or touching production configuration. Model answer.

Execution. A scheduled CI job runs Claude Code in headless mode per repository: claude - p with a task prompt, --output-format json, and a narrow allowed-tools list (read, edit, the package manager, the test command, and git commands for branches and commits). Configuration. Each repository has a CLAUDE.md with build and test commands. A shared Skill, dependency-upgrade, describes the house procedure: upgrade in small groups, read

Appendix e: end-to-end case studies

changelogs for breaking changes, run tests after each group, and stop after three failed fix attempts.

Guardrails. deny rules on production config paths and secrets; a PreToolUse hook that blocks git push to protected branches and any force push; the CI token can push only to deps/* branches. Branch protection on main is the final, platform-level control. Review. Each PR includes a summary of changes and test results; humans review and merge.

Measurement. Track merge rate, time to merge, and how often humans had to fix Claude's PRs.

Domains touched: 1, 2, 3, 7.

Case study 4: Investment research agent

Brief. An asset manager wants an agent that, given a company name, researches recent news, filings, and analyst commentary, then writes a two-page briefing with sources. Analysts run it a few times a day. Accuracy and citations matter more than speed.

Model answer.

Architecture. Orchestrator-workers. A lead agent on a top-tier model plans the research questions. Worker subagents on a cheaper model each take one question, use the web search and web fetch server tools (with domain allow-lists for reputable sources) and internal filings tools, and return structured findings with source URLs and quotes. Context management. Workers return compact findings, not raw pages, keeping the lead's context focused. A task budget or turn cap prevents runaway research.

Synthesis. The lead writes the briefing using only findings that carry a source, and marks conflicts between sources explicitly.

Verification. Code checks that every cited URL appears in the workers' results; numbers (revenue, growth) are recomputed or cross-checked against filings data.

Security. Web content is untrusted: workers have no tools that send data outward, and the lead never executes instructions found in pages.

Hosting. Since analysts run it on demand and the firm does not want to host sandboxes, Claude Managed Agents is a reasonable option; a self-hosted Agent SDK deployment is the alternative if data policies require it.

Domains touched: 1, 2, 5, 6, 7, 8.

Case study 5: Patient intake summaries

Brief. A clinic network wants Claude to turn patient intake forms and nurse notes into structured summaries for physicians. Data includes names, dates of birth, insurance numbers, and medical history. Leadership asks about privacy first.

Model answer.

Data minimization. Remove identifiers the summary does not need (insurance numbers, addresses) before sending. Replace names with placeholders and re-insert them after. Contracts and retention. Confirm the organization's agreements and data-retention configuration meet the clinic's regulatory obligations before any production data flows; involve compliance.

Structured output. A fixed schema: chief complaint, history, medications, allergies, red flags, open questions. Structured outputs guarantee shape; code validates allergies and medications against the source text. Safety posture. Summaries are decision support for physicians, never sent to patients directly; every summary is reviewed. Red-flag detection has its own eval slice with high-recall targets.

Access control. Only the treating team can request a patient's summary; the application enforces this, and tools fetch records under the requesting clinician's identity. Logging. Prompt and response logs are treated as medical records: encrypted, access-controlled, and retained per policy. Domains touched: 2, 4, 6, 7.

Case study 6: A multi-tenant SaaS platform adding AI features

Brief. A project-management SaaS with 3,000 business customers wants to add "Ask your workspace" (questions over a customer's projects) and an assistant that can create and update tasks. Several internal teams will build features on top of the same capabilities.

Model answer.

Shared capabilities as MCP. The platform team builds an internal MCP server exposing project search, task read, and task write tools, deployed over Streamable HTTP with per-user OAuth. Every feature team, and Claude Code for internal developers, uses the same server. Tenant isolation. Tools enforce the calling user's permissions; no prompt, cache prefix, or conversation ever mixes tenants. The system prompt is identical across tenants, which keeps it cacheable, while tenant data arrives only through tools.

Write safety. Task creation and bulk updates show a confirmation to the user before executing; deletion is not exposed as a tool at all. Models. "Ask your workspace" on a mid-tier model with streaming; background summarization (weekly digests) on a small model through the Batch API. Configuration management. Prompts, tool schemas, and model IDs are versioned; each feature team has its own workspace and key with spend limits; the MCP server is versioned and changes are tested against every consuming feature's eval.

Appendix e: end-to-end case studies

Observability. Traces per request with tenant ID, tool calls, tokens, and latency, so cost can be attributed per customer.

Domains touched: 1, 2, 5, 7, 8.