Questions? Call 1.800.716.8955

Chapter 11

Capstone case studies

Each case crosses several domains, as the real exam does. Sketch your own answer before reading the model answer.

Case A: Global insurer, claims intake

Situation. A property insurer receives 60,000 claims a month as emails, PDFs, and photos in English, French, and Spanish. Adjusters spend 25 minutes per claim on intake. Leadership wants a 50% cut in intake time within two quarters. Data includes personal and financial information; EU customers are in scope. The company is committed to one major cloud provider. Model answer.

Discovery (D6): shadow adjusters, collect 300 historical claims with correct intake records as the eval set, agree on metrics: field accuracy, triage accuracy, intake minutes, cost per claim.

Pattern (D1): a workflow, not an agent. Classify claim type, extract fields to a schema, check against policy data through a read-only API tool, flag missing items, route to a queue. Fast tier for classification; balanced tier for extraction; escalate unclear documents. Platform (D1, D5): Claude through the company's existing cloud platform in an EU region to meet residency and procurement needs.

Integration (D3): policy lookup is a scoped, read-only tool authorized per adjuster; no write access to the claims system in phase 1.

Governance (D5): DPIA under GDPR, PII redaction in logs, adjuster confirms every extracted record (medium tier), coverage decisions remain human. Evaluation (D4): code checks on schema and fields, model-graded triage rationale, weekly human audit sample; regression suite gates prompt changes.

Cost (D2, D4): cache the shared instructions and schema; batch overnight backlog processing; measure cost per completed intake.

Case B: Software company, internal engineering assistant

Situation. A 1,200-engineer SaaS company wants an assistant that answers questions about internal systems and helps on call. Sources: wiki, 3,000 repos, runbooks, incident history, and an observability platform. Security has two concerns: secrets in repos and agents changing production. Model answer.

Retrieval (D3): hybrid search over wiki and runbooks with reranking; code search through a code tool, not embeddings alone; incident history filtered by service metadata. Enforce repo permissions at retrieval time.

Protocol (D3): expose wiki, repos, and observability as approved MCP servers in an internal registry behind a gateway with per-user OAuth; on-call tools are read-only.

Agent design (D1): a single agent with progressive tool discovery; subagents only for wide searches across many repos, returning summaries.

Claude Code (D7): managed settings deny reading secret files and block production deploy commands; hooks log tool use; shared CLAUDE.md templates per repo; CI usage for test-failure triage with human merge. Safety (D5): incident text and logs are untrusted content; no outbound communication tools; any remediation step requires an engineer's approval.

Lifecycle (D6, D4): pilot with two on-call rotations, measure time to mitigation and answer acceptance, grow eval set from rejected answers.

Case C: Regional hospital network, clinical documentation

Situation. A hospital network wants Claude to draft discharge summaries from clinician notes and lab results in the electronic health record (EHR). Clinicians must save at least 10 minutes per discharge. The CIO asks whether it can "go live in six weeks."

Model answer.

Compliance first (D5): a BAA and a HIPAA-eligible configuration before any PHI flows; minimum-necessary data pulled per patient; audit logs of every access. Expectations (D6): six weeks is enough for a supervised pilot on one ward, not a networkwide launch. Present phased options with risks and get the clinical safety committee's signoff. Design (D1, D3): a workflow that pulls structured data through the EHR's API under the clinician's authorization, drafts with citations to source notes, and shows the draft in the EHR for editing. Nothing is filed without clinician signature (critical tier).

Capstone case studies

Evaluation (D4): clinicians rate 200 drafts against a rubric (accuracy, omissions, medication correctness); medication and allergy fields have code-based checks against structured data; track edit distance and time saved.

Fairness and transparency (D5): test across patient groups and languages, label drafts as AIgenerated, document limitations.

Case D: Retail bank, customer-service agent with actions

Situation. A retail bank with 4 million customers wants an assistant in its mobile app that can answer questions and also act: freeze a lost card, dispute a transaction, change a contact address, and schedule a callback. The contact center handles 1.2 million contacts a month; 35% are these four requests. Regulators expect strong authentication, clear records of customer consent, and fair treatment of vulnerable customers. The bank's security team is worried about account takeover through the assistant. Questions to answer before reading on. Which actions should the assistant take on its own? How is authorization enforced? How do you handle vulnerable customers? What do you measure? Model answer.

Discovery (D6): confirm with operations which intents are highest volume and simplest; agree that the first release covers card freeze, callback scheduling, and dispute intake, with address change deferred because it is a common account-takeover step.

Pattern (D1): routing to intent-specific workflows rather than one open-ended agent. Each workflow has fixed steps, a structured confirmation, and a single tool. Open questions go to a retrieval-augmented answer path.

Authorization (D3): the app session's strong authentication carries the customer identity to every tool. Tools act only on that customer's accounts. Card freeze is reversible and low risk: allowed after an in-app confirmation. Dispute intake creates a case for staff, it does not refund. Address change, when added, requires step-up authentication outside the chat and a notification to the old address.

Safety (D5): content from transaction descriptions and uploaded documents is untrusted. The assistant cannot move money, change credentials, or add payees. A vulnerability classifier and keyword triggers (bereavement, financial hardship, distress) route to trained staff with a warm handoff.

Records (D5): every action logs the customer's explicit confirmation, the text shown to them, the tool call, and the result.

Evaluation (D4): intent classification accuracy; task completion rate; false-action rate (actions taken that the customer did not intend) with a target of zero in testing; red-team suite for social engineering and injection; vulnerable-customer detection recall.

Lifecycle (D6): launch to 2% of app users, expand weekly against metrics; a steering group with operations, risk, and compliance meets fortnightly.

Value (D1): measured as contacts contained without a human, time to freeze a lost card, and customer satisfaction, compared with a control group.

Exam lesson. Even when actions are in scope, give the model the narrowest tool for each, prefer reversible actions for automation, and enforce identity and consent outside the model.

Case E: Global manufacturer, engineering knowledge platform

Situation. A manufacturer with plants in 14 countries wants a shared knowledge platform. Content: 2 million documents in SharePoint, a product lifecycle management system with part data, maintenance logs in a work-order system, and quality reports. Engineers speak eight languages. Five business units each want their own assistant, and two have already built prototypes with different vector databases and prompt styles. The CIO wants one platform, but business units fear losing control. Model answer.

Operating model (D6): a central AI platform team owns shared components; business units own their assistants' scope, content, and evaluation sets. A design authority reviews new use cases by risk tier. Record this in a charter so both sides know their decision rights. Platform (D1, D3): shared ingestion and retrieval service; MCP servers for document stores, PLM, and work orders, owned by the system teams and registered centrally; a gateway with SSO, per-user authorization that respects source-system permissions, rate limits, and cost attribution per business unit. Retrieval (D3): hybrid search because engineers search by part numbers and standards codes; structure-aware chunking for procedures and tables; metadata for plant, product line, language, and document status; structured PLM queries through a tool, not embeddings. Multilingual (D2, D4): test retrieval and answers in all eight languages; consider cross-lingual retrieval so an engineer in Brazil can find a German procedure, with answers in the user's language and links to the source.

Migration of prototypes (D6): keep what works (their evaluation sets and prompts), move them onto shared components over a quarter, and show each unit its metrics before and after so the change is evidence-based.

Evaluation (D4): each business unit maintains its evaluation set; the platform runs them on every shared-component change, so a retrieval change that helps one unit and hurts another is caught.

Governance (D5): export-control and IP restrictions on some technical documents become access labels enforced at retrieval; region-appropriate deployment for data residency.

Capstone case studies

Enablement (D7): templates, a starter kit, office hours, and a shared library of skills and prompt modules.

Exam lesson. At enterprise scale, the architecture is as much an operating model as a technical design: shared platform, federated ownership, and evaluation that protects every consumer.

Case F: Public-sector agency, benefits casework

Situation. A government agency handles applications for a social benefit. Caseworkers read applications, supporting documents, and policy manuals to decide eligibility. Backlogs are six months. The agency must meet a government cloud authorization standard (for example FedRAMP for a US agency), accessibility standards, records-retention law, and strict rules on automated decisions about citizens. A public advocacy group is watching closely. Model answer.

Scope (D6, D5): Claude assists caseworkers; it does not decide eligibility. Uses: summarize the application, list missing documents, point to the policy sections that apply with citations, and draft letters for caseworker approval.

Platform (D1, D5): deploy only through a cloud environment authorized at the required level and region; confirm that every service used (model access, storage, logging) is inside the authorization boundary. Design (D1, D3): workflow per case: extract and validate data from documents, retrieve relevant policy sections with version dates, produce a structured case summary with citations, and draft correspondence. All tools read-only except a "save draft" action.

Fairness and transparency (D5): evaluate summaries and policy citations across applicant groups, languages, and document quality (scanned, handwritten); publish a plain-language notice of how AI assists caseworkers; give applicants a route to ask questions about their case.

Records (D5): retain drafts, final letters, and the sources used, according to records law; audit logs of every case access.

Accessibility (D6): letters and the caseworker interface meet accessibility standards; plainlanguage reading-level checks on drafts. Evaluation (D4): experienced caseworkers label 400 historical cases; measure citation accuracy, missing-document detection, and summary completeness; track time per case and decision consistency in the pilot.

Stakeholders (D6): brief the advocacy group early with the design principles and safeguards; involve the union representing caseworkers on workload and training. Exam lesson. In the public sector, authorization boundaries, records law, and transparency to citizens shape the architecture as much as accuracy does, and humans make the decisions.

What the six cases share

Discovery before design, the simplest pattern that meets the need, least-privilege integration under the user's own authorization, human control proportionate to risk, and an evaluation set that grows from real failures.

Capstone case studies

Use ← → to move between sections