Chapter 14 - Case Studies

TL;DR

These composite case studies demonstrate how principles, scaffolds, evaluation harnesses, and governance from earlier chapters compose into end-to-end agent designs across HR Leave, Invoice Processing, IT Service Desk, Contact Centre, CRM Sales, Contract Review, and Scheduling domains.
Every case follows a consistent six-part structure — context and goals, principles in action, system shape, harnesses and evaluation, governance and lifecycle, and outcomes and lessons — so you can compare decisions across domains and reuse the template for your own designs.
Common anti-patterns recur across failures: unbounded retries without termination criteria, confident wrong answers from uncalibrated retrieval, and shadow AI from ignoring workflow fit and user research.
The failure case studies (Runaway Invoice Agent, Confident Wrong Answer, Shadow AI shelfware) are equally important to study; each maps directly to handbook disciplines that were skipped, not capabilities that were missing.
Use the cases and checklists as tools for design reviews, retrospectives, and governance gates — ask "which failure pattern is this most at risk for?" and require mitigation evidence before launch.

14.0 How to Use This Chapter

This closing chapter turns the book's ideas into end-to-end examples.

Each case study is a composite, not a single real deployment. The goal is to show how the same building blocks reappear across domains. You will see principles from Chapter 3 including scope, goals, autonomy, context-first design, oversight by design, and evaluation as a feature. You will see scaffolds and patterns from Chapters 4-5 covering the inner-loop behavioural architecture, tool contracts, and context and memory patterns. You will see harnesses and evaluation from Chapters 6-9 covering golden sets, red-teams, online evaluation, traces, and error analysis loops. You will see UX and production from Chapters 9-11 covering deterministic shells around a probabilistic core, preview-to-commit for writes, control surfaces, and observability. You will see governance and lifecycle from Chapter 12 covering AI dossier, evidence bundles, lifecycle gates, ongoing monitoring, and incident-to-learning loops.

Every case follows the same six-part structure:

Context and goals
Principles (Ch3) in action
Scaffolds and patterns used (Ch4-5)
Harnesses and evaluation setup (Ch6-8)
Governance and lifecycle aspects (Ch12)
Outcomes, anti-patterns avoided, lessons

Table 13.1 — Case Overview

Case	Primary users	Action class	Autonomy starting point	Primary risks	What this case teaches
13.2 HR Leave Agent	Employees, HR helpdesk	Read, guidance	L0-L1 (suggest only)	Policy misguidance, privacy	Context curation, citations, escalation UX, policy-change lifecycle
13.3 Invoice Intake and Approval Agent	AP clerks, approvers, audit	Low-impact write (drafts), routing	L1-L2 (recommend, prepare drafts)	Control breaches, fraud, auditability	Maker-checker, evidence bundles, red-team controls, conservative automation
13.4.1 IT Service Desk Agent	Employees, ITSM team	Mixed (read plus controlled writes)	L1 (guided self-service)	Security, identity abuse	Typed tools, safe side effects, handoff for security incidents
13.4.2 Contact Centre Triage and Summarisation	Contact centre agents, QA	Read plus suggestions	L1 (assist, never act externally)	Privacy, misrepresentation, compliance	Streaming summaries, compliance critics, operational telemetry
13.4.3 CRM Sales Co-pilot	Sales reps, managers	Read plus controlled writes	L1-L2 (drafts, updates with approval)	Hallucinated commitments, data leakage	Outcome metrics, calibration, guardrails for external messaging
13.4.4 Contract Review and Risk Screening	Legal, procurement	Read plus flags	L1 (screen and explain)	Missed risks, wrong citations	Explainability ladder, rubric judging, gold sets from prior negotiations
13.4.5 Scheduling and Coordination	Ops, project teams	High-impact write (calendar, resources)	L1 (propose), L2 (commit with approval)	Overstepping user intent, conflicts	Multi-agent orchestration, simulation harnesses, strong control surfaces

If you are short on time, read Section 13.1 for a reusable template you can clone into your own design doc or AI dossier. Read Sections 13.2 and 13.3 for two fully worked cases with very different risk profiles. Read Section 13.6 for failure case studies. Learning what not to do is equally important.

14.1 Case Study Template

Use this template as a starting point for your own case write-ups, design docs, or AI dossier sections.

13.x [Domain] Agent in [Org Context]

13.x.1 Context and Goals

Describe the organisation context and constraints. Include the sector, scale, regulatory constraints, data sensitivity, and existing workflow constraints.

Describe the starting pain points. These might include queues, manual effort, inconsistency, control breaches, or customer dissatisfaction.

Describe the business goals. These might include cycle time, cost, quality, CSAT, or control integrity.

Describe the non-goals. State what the agent explicitly will not do.

A useful one-liner to keep teams honest:

Job to be done: "When [situation], help me [desired outcome], without [failure outcome]."

13.x.2 Principles in Action

Anchor design decisions to Chapter 3 principles. Keep it concrete.

Principle (Ch3)	Design decision	Example you can verify
Select the right problems	Scope to a narrow workflow, exclude edge domains	Guidance only, no final approvals
Clear goals	One primary objective and measurable thresholds	"Policy-correct guidance >= 95%"
Outcome-first	Define gates, budgets, and hard fails early	"0 unauthorised payment suggestions"
Start simple	Earn autonomy using evidence	L0 to L1 after passing regression suite
Context-first design	Curate what the model can see	Approved corpus only, with provenance
Oversight by design	Place human checkpoints at risk boundaries	Maker-checker, escalation inbox
Evaluation is a feature	Evals are backlog items, not a phase	Every feature change includes new tests
Tools as contracts	Typed tools, schema outputs, safe side effects	Preview-to-commit for any write

13.x.3 System Shape

Describe the system as a stack. This helps readers map it to Chapters 2-5 and 9-10.

The user surface might be a chat, sidecar, inbox, wizard, or dashboard. The scaffold might be a structured prompt, ReAct, Plan-Execute, state machine, or manager-worker pattern. Tool contracts include read tools, write tools with staging, approvals, and idempotency. The context builder handles retrieval recipes, redaction, and budgeting. The memory policy covers session state, long-term writes, and retention boundaries. Runtime controls include budgets, feature flags, kill switch, retries, and rate limits. The workflow orchestrator handles long-running tasks, SLAs, and compensation paths. Harness hooks provide traces, spans, evaluator stack, and replay keys.

A small diagram helps.

Figure 13.1 — Example scaffold overview

flowchart LR
  U[User] --> UX[UX Surface]
  UX --> S[Scaffold]
  S --> CB[Context builder]
  CB --> R[RAG / Policy corpus]
  S --> T[Typed tools]
  T --> SYS[(Enterprise systems)]
  S --> O[Output: answer or draft action]
  S --> H[Harness hooks: traces/spans]

13.x.4 Harnesses and Evaluation

Offline harnesses include golden sets, scenario suites, red-team probes, and simulation. Online evaluation includes shadow mode, canary, A/B, and monitoring with alert thresholds.

The metrics registry should cover task success and correctness, safety and compliance as hard fails, UX and adoption, and latency, reliability, and cost.

The evaluator stack combines deterministic checks, LLM-as-judge, and SME audits. The error analysis loop describes how failures become new tests.

Include a short "what to test" list that matches the action class.

13.x.5 Governance and Lifecycle

Document the risk tier and autonomy band, both initial and target.

Document the lifecycle gates: idea, design, pre-pilot, pilot, pre-production, production, and continuous improvement.

Document the AI dossier contents: intent, non-use, data sources, model and prompt versions, tool scopes, evaluations, and incidents.

Document the evidence bundles per release: harness results, residual risks, and rollback triggers.

Document day-2 governance: policy changes, drift monitoring, incident response, and periodic reviews.

13.x.6 Outcomes and Lessons

Document measured outcomes, both quantitative and qualitative. Document anti-patterns avoided such as scope creep, shadow AI, hero engineer, and eval theatre. Document reusable lessons and checklists.

📚 Related sections: - Checklists and templates → Appendix A - Governance dossier → Chapter 12, §12.2.2

14.2 Case Study: HR Leave Agent in a Large Organisation

This case study demonstrates how handbook principles compose into a working agent. The HR Leave Agent is the handbook's running example. It appears in Chapter 9 (pattern composition), Chapter 11 (production walkthrough), and Appendix B (complete reference). This section shows how principles drive design decisions in practice.

📚 Technical deep-dives: - Pattern composition and artifact set → Chapter 9, §9.9 - Production walkthrough with recovery and observability → Chapter 11, §11.A - Complete skill library and specifications → Appendix B

📚 Complete Reference Materials:

Appendix Focus Key Sections

B Architecture and patterns B.1–B.5

C Prompts and evaluation rubrics C.1–C.5

D Synthetic test datasets D.1–D.5

E Code implementation E.1–E.7

📦 Companion Repository: Clone the repository to run the interactive demo, execute evaluations, and adapt the code for your own domain.

14.2.1 Context and Goals

A large organisation with 10,000 to 20,000 staff has multiple employment schemes and a complex set of leave types including annual, sick, childcare, maternity, and paternity. Policies live across intranet pages, circulars, PDFs, and historical emails.

Before the agent:

Employees spent time navigating complex leave policies. HR staff spent time answering repetitive questions. Leave requests received inconsistent handling. Errors in policy interpretation created fairness concerns and occasional legal exposure.

Goals:

The primary goal is to guide and validate leave applications, then prepare recommendations for submission. The secondary goal is to reduce HR helpdesk load and improve employee experience through consistent policy interpretation.

Table 13.2a — Agent charter summary

Item	Decision
Goal	Guide and validate a leave application, then prepare a recommendation
Autonomy	Execute-with-approval for state changes; suggest-only for ambiguous policy interpretation
Risk tier	Medium to high, due to employment policy, fairness, and auditability
Oversight	Approval checkpoint before submission; human-in-the-loop triggers on conflicts or low evidence
Audit	Decision record with inputs, policy clause IDs and versions, validation, approvals, and final action

Scope:

The agent handles annual leave, sick leave, childcare leave, and maternity/paternity leave. It checks eligibility against policy, verifies balances, drafts leave requests, and submits to HRIS with approval. It does not handle payroll calculations, performance management, complex exceptions (which route to HR), or cross-company transfers.

Non-negotiables:

No statutory errors (legal exposure)
No PII leakage across employees
All decisions traceable to policy
No hidden autonomy

14.2.2 Principles in Action

Table 13.2b — Principles to design decisions

Principle (Ch3)	Design decision	Concrete example
Select the right problems	Scope to leave guidance and submission; exclude disputes, grievances, payroll	Leave workflow only; complex exceptions escalate to HR
Clear goals	Single objective: policy-correct guidance with auditable submission	KPI: correctness ≥95% on golden set; zero non-negotiable violations
Outcome-first	Define gates, budgets, and hard fails early	No unverifiable policy claims; no writes without Preview → Commit
Start simple	Earn autonomy using evidence	Start suggest-only; graduate to execute-with-approval when evidence supports it
Context-first design	Curate what the model sees; use step-scoped injection	Each step receives only the context needed; policy excerpts with version metadata
Oversight by design	Approval checkpoint before any write	Preview → Commit pattern; HITL triggers on conflicts, low evidence, disputes
Evaluation is a feature	Evals are backlog items, not a phase	Every policy update triggers regression suite; 7-category test checklist
Tools as contracts	Typed tools with schema validation, safe side effects	Write tools use idempotency keys; dry-run mode available; no double submissions
Design for explainability	Evidence, citations, and limitations	Clause references with policy version; confidence indicator; rationale summary

The key discipline is resisting the "general HR chatbot" impulse. Leave guidance is valuable precisely because it is common, policy-heavy, and easy to scope with clear success criteria.

14.2.3 System Shape

User surface

The agent runs in Teams or Slack. The interface displays the current autonomy mode (suggest-only or execute-with-approval). For submissions, a sidecar shows the Preview → Commit flow with policy citations, confidence indicator, and approval status.

Scaffold choice

The scaffold determines how the agent structures its work. Two patterns suit the HR Leave use case.

Table 13.2c — Scaffold options

Option	When to use	Notes
Plan → Execute → Review	Discovery, evolving workflows	Flexible; makes review and oversight explicit
State Machine	Stable fixed workflow	Good for hardening; predictable handoffs and SLAs

Figure 13.2 — HR Leave Agent reference flow

flowchart TD
  U[User submits leave details] --> P[Plan: decide next steps]
  P --> V[Execute: validate inputs]
  V --> B[Execute: check leave balance]
  B --> RAG[Execute: retrieve policy clauses]
  RAG --> VAL[Execute: validate request vs balance and policy]
  VAL --> REV[Review: decide outcome and required oversight]
  REV -->|Clarify| Q[Ask user questions] --> P
  REV -->|Human review| H[Route to HR] --> OUT[Recommendation]
  REV -->|Proceed| D[Draft recommendation]
  D -->|Needs approval| A[Approval checkpoint]
  A -->|Approved| S[Submit leave request]
  A -->|Rejected| OUT
  S --> OUT[Outcome + audit summary]

This flow shows the 6-step pattern composition from Chapter 9 §9.9.3. Chapter 11 §11.A.1 expands this to 8 steps for production, adding Step 0 (establish scope and autonomy mode) and Step 8 (exception recovery path).

Skill library

The agent uses five skills with explicit contracts. Each skill has defined inputs, outputs, tools, risk tier, and approval requirements.

Table 13.2d — Skill library

Skill	Input	Output	Tools used	Risk tier	Side effects	Approval
check_leave_balance	employee_id, date_range	balance, constraints	HRIS read API	Medium	Read-only	None
retrieve_policy_clauses	topic, grade, jurisdiction, policy_version	clauses[]	Policy store, vector search	Medium	Read-only	None
validate_request	request, balance, clauses	violations[], requires_human_review	None (pure)	High	None	Human review if hard criteria fail
draft_recommendation	request, validation, clauses	recommendation, rationale, citations[]	None (pure)	Medium	None	None
submit_leave_request	request_id, final_fields	status, change_summary	HRIS write API	High	Write	Always required

An additional escalate_to_hr skill packages context for HR handoff when the agent cannot proceed.

Tool patterns

All tools use strict schemas for input and output. Untrusted inputs are validated before any tool call. Write tools support dry-run mode and idempotency keys. Tool outputs are compact and structured with no raw dumps.

Memory and context plan

Table 13.2e — Memory layers

Layer	What it stores	Write policy
Scratchpad	Plan, intermediate tool outputs, validation results	Always ephemeral, per run
Session memory	Clarifications, current application state, open questions	Only facts needed to complete current application
Long-term memory	Durable preferences, only if explicitly allowed	Opt-in only, minimal fields

Step-scoped injection ensures each step sees only what it needs. The planning step sees goal, constraints, and minimal state summary. The policy retrieval step sees retrieval parameters only. The drafting step sees curated clauses and validation results, not raw system dumps.

14.2.4 Harnesses and Evaluation Setup

6-step pattern plan

📚 Pattern composition: The six-step plan (Intake → Context assembly → Eligibility → Approval routing → Side effects → User response) and the patterns each step uses are detailed in Chapter 9, §9.9.3. The evaluation checklist below shows how to test each step.

Evaluation harness (7-category checklist)

This checklist converts directly into harness test cases.

Table 13.2f — Evaluation categories

Category	What to test	Examples
A. Knowledge/retrieval	Policy clause retrieval, version handling, citation presence	Wrong version, stale cache, missing clause, citation absent
B. Eligibility correctness	Balance checks, policy rule application, approval requirements	Insufficient balance, blackout period, overlapping leave
C. Write safety	Preview accuracy, idempotency, no double submissions	Submit twice with same key, partial failure retry
D. Autonomy transparency	Mode visibility, approval gating	Hidden auto-submit, missing approval prompt
E. Recovery/resilience	Tool failures, HRIS outages, preserved state	Draft recovery after timeout, queue-for-later path
F. Security/contextual integrity	Cross-employee queries, PII leakage, prompt injection	"Show teammate balance" refused even if data accessible
G. Observability/replay	Trace completeness, audit record, decision chain	Reconstruct decision from logs, replay with same result

Metrics

Correctness metrics include policy-correct answers by leave type, citation accuracy, and eligibility decision accuracy with target ≥95%. Safety metrics include non-negotiable violations (target: zero), cross-employee data leakage (target: zero), and unverifiable policy claims (target: zero). UX metrics include CSAT, escalation rate, task completion rate, and confidence calibration. Ops metrics include latency (P50, P95), tool error rate, approval turnaround, and cost per session.

Evaluator stack

Deterministic checks verify schema conformance, required citations present, no approval language without checkpoint, and idempotency key present for writes. LLM-as-judge evaluates policy correctness, rationale quality, and citation relevance, calibrated to HR rubrics. SME audits cover sampled sessions, especially for exceptions and disputes.

14.2.5 Governance and Lifecycle Aspects

Risk classification

Table 13.2g — Risk assessment

Dimension	Assessment
Data sensitivity	Medium (personal HR data, balances)
Decision impact	Medium (affects employee entitlements)
Reversibility	High (requests can be cancelled/modified)
Regulatory exposure	Medium (employment law, PDPA)
Overall risk tier	Medium

Lifecycle gates

Idea: Business case and initial risk tier. HR, security, and data protection involved from start.
Design: Threat modelling. Define non-negotiables. Establish evaluation criteria.
Pre-pilot: AI dossier created. Golden set defined with ≥50 cases across leave types. Escalation criteria signed off.
Pilot: Limited cohort (5% traffic). Suggest-only mode. Weekly reviews with HR SME.
Pre-production: Expanded red-team testing. Execute-with-approval mode tested. Change management plan. Release gates defined.
Production: Canary rollout (5% → 25% → 100%). Quarterly dossier updates. Policy-change gates. Incident-to-learning workflow.
Continuous improvement: Feedback loop from escalations to golden set. Drift monitoring. Periodic reviews.

Non-negotiables (ship gates)

📚 Full list: The eight non-negotiable ship gates (no unverifiable claims, no writes without preview-commit, no hidden autonomy, deterministic policy guards, preserved state on failure, idempotent submissions, no cross-person leakage, replayable runs) and the contextual integrity implementation pattern are detailed in Chapter 9, §9.9.4.

AI Dossier summary

agent:
  name: "HR Leave Agent"
  version: "1.2.0"
  risk_tier: "Medium-High"
  lifecycle_state: "Production"

evidence:
  golden_set_pass_rate: "94.2%"
  non_negotiable_violations: 0
  regression_suite_status: "PASS"
  red_team_findings: "2 low severity, mitigated"

approvals:
  technical_lead: "approved"
  hr_business_owner: "approved"
  risk_compliance: "approved"
  security: "approved"

rollout_plan:
  strategy: "Canary 5% → 25% → 100%"
  rollback_trigger: "Error rate >2% or compliance violation"

14.2.6 Outcomes, Anti-patterns Avoided, Lessons

Illustrative outcomes you should be able to measure

Expect 30% to 50% reduction in leave-related helpdesk volume. Golden set correctness should be above 95% with failures concentrated in edge cohorts handled by escalation. Expect improved employee satisfaction with HR self-service. Expect faster request turnaround with the execute-with-approval path.

Anti-patterns avoided

The team avoided "chatbot for everything" scope creep into disputes, grievances, and payroll. They avoided shadow AI deployment without logging, gates, or HR ownership. They avoided treating evaluation as a one-off certification. They avoided autonomous writes without Preview → Commit. They avoided policy enforcement by prompt alone without runtime guards.

Lessons

In policy-heavy domains, context curation and provenance matter as much as model choice. The knowledge layer is a product—if retrieval quality degrades, the entire agent fails. Escalation design is a product feature, not just a governance requirement. The fastest path to trust is not a smarter model; it is repeatable evidence and conservative defaults. Progressive autonomy works: start suggest-only, measure, then graduate to execute-with-approval.

14.2.7 Multi-Jurisdiction Considerations

The HR Leave agent becomes significantly more complex when the organization operates across multiple jurisdictions. This subsection addresses what changes when the same agent must handle Singapore, US, and EU employees.

14.2.7.1 Policy corpus per jurisdiction

Each jurisdiction has different statutory leave entitlements, different employment law frameworks, different cultural norms around leave, and different language considerations.

Corpus structure:

policies/
├── global/
│   └── company_leave_policy_v2024.md
├── singapore/
│   ├── statutory/
│   │   ├── employment_act_leave.md
│   │   ├── childcare_leave.md
│   │   └── maternity_paternity.md
│   └── company/
│       └── sg_addendum.md
├── united_states/
│   ├── federal/
│   │   └── fmla.md
│   ├── california/
│   │   ├── cfra.md
│   │   └── paid_family_leave.md
│   └── company/
│       └── us_addendum.md
└── european_union/
    ├── eu_wide/
    │   └── working_time_directive.md
    ├── germany/
    │   └── de_leave_law.md
    └── company/
        └── eu_addendum.md

Retrieval must be jurisdiction-filtered. Apply jurisdiction filter at query time based on employee work location. Boost statutory documents over company policy.

14.2.7.2 Date and calendar handling

Dates are a common source of internationalization bugs.

Table 13.2h — Date and calendar handling by jurisdiction

Issue	Singapore	US	Germany
Date format	DD/MM/YYYY	MM/DD/YYYY	DD.MM.YYYY
Week start	Monday	Sunday	Monday
Public holidays	Different set	Different set	Different set (+ state)
Fiscal year	Jan–Dec (often)	Varies	Jan–Dec

Store all dates in ISO 8601 (YYYY-MM-DD) internally. Convert to locale format for display only. Maintain holiday calendars per jurisdiction. Handle business days calculation per jurisdiction.

14.2.7.3 Statutory leave type mapping

Different jurisdictions have different leave categories.

Table 13.2i — Statutory leave type mapping

Concept	Singapore	US (varies by state)	Germany
Parental (birth parent)	16 weeks maternity	FMLA 12 weeks unpaid + state varies	14 weeks Mutterschutz + Elternzeit
Parental (other parent)	2 weeks paternity	Often none federally	Elternzeit (shared)
Child sick care	6 days childcare leave	Varies	Kinderkrankengeld
Personal sick	14 days paid	Varies widely	6 weeks full pay then insurance
Annual/vacation	Statutory minimum 7 days	No federal minimum	Minimum 20 days

The agent must map natural language like "I need time off for my kid's surgery" to jurisdiction-specific leave types. It must explain the relevant entitlement in jurisdiction-appropriate terms. It must not assume one jurisdiction's rules apply to another.

14.2.7.4 Evaluation stratification by jurisdiction

Golden sets must be stratified by jurisdiction. Track accuracy, latency, and user satisfaction per jurisdiction. Set jurisdiction-specific thresholds where legal risk differs. Use a higher bar for statutory entitlement accuracy because of legal exposure.

golden_sets:
  hr_leave:
    total_cases: 200
    stratification:
      by_jurisdiction:
        singapore: 60
        us_california: 50
        us_texas: 30
        germany: 40
        uk: 20
      by_leave_type:
        annual: 50
        sick: 40
        parental: 50
        childcare: 30
        other: 30

14.2.7.5 Cross-jurisdiction edge cases

The hardest cases involve employees who span jurisdictions.

Table 13.2j — Cross-jurisdiction edge cases

Scenario	Challenge
Transfer during leave	Which jurisdiction's rules apply?
Remote work from different country	Which leave policy governs?
Secondment/assignment	Home vs host policy
Multiple employments	Leave entitlement aggregation

The agent should recognize cross-jurisdiction scenarios and flag for human review rather than guess. It should provide relevant information from both jurisdictions and document the ambiguity clearly.

14.2.7.6 Multi-jurisdiction implementation checklist

Policy corpus:

[ ] Policy documents organized by jurisdiction hierarchy
[ ] Statutory requirements clearly marked and sourced
[ ] Company addenda linked to base policies
[ ] Version control per jurisdiction

Retrieval:

[ ] Jurisdiction filter applied at query time
[ ] Employee location resolved before retrieval
[ ] Cross-jurisdiction contamination tested
[ ] Statutory documents boosted in ranking

Date handling:

[ ] Internal storage in ISO 8601
[ ] Display format per user locale
[ ] Holiday calendar per jurisdiction
[ ] Business day calculation tested

Evaluation:

[ ] Golden set stratified by jurisdiction
[ ] Edge cases for each jurisdiction included
[ ] Cross-jurisdiction scenarios tested
[ ] Metrics tracked per jurisdiction

📚 Related sections: - Multi-tenant governance → Chapter 12, §12.3.6 - Evaluation stratification → Chapter 6, §6.5 - Policy versioning → Chapter 12, §12.3.6.2

📚 Related sections: - Complete HR Leave reference → Appendix B - Pattern composition → Chapter 9, §9.9 - Production walkthrough → Chapter 11, §11.A - Best practices applied → Chapter 9

14.3 Case Study: Invoice Intake and Approval Agent in a Regulated Finance Shared Service

14.3.1 Context and Goals

A regional shared service centre processes tens of thousands of invoices monthly. Invoices arrive via email and portals in multiple formats. Staff manually extract fields, reconcile against purchase orders and contracts, and route for approval.

Before the agent, peaks created backlogs and long cycle times. Exceptions were costly to diagnose including missing POs, mismatched goods receipts, and wrong vendors. Control failures were rare but high impact including wrong coding, wrong approver, and duplicate invoices.

The primary goal is to accelerate intake and routing without weakening controls. Secondary goals are to reduce manual data entry and reduce avoidable exceptions. Maker-checker remains in force. No autonomous payments are permitted. The system must support audit and investigation.

14.3.2 Principles in Action

Table 13.3 — Invoice Agent: Principles in Action

Principle (Ch3)	Design decision	Concrete example
Outcome-first	Controls outrank speed	"0 new control breaches" is a hard fail gate
Start simple	Automation earns scope	Start with draft coding and routing only
Oversight by design	Maker-checker stays	Agent proposes, finance officer approves
Tools as contracts	No direct ERP posting	Writes go to a staging table with review
Evaluation is a feature	Risk and audit co-design evals	Golden sets include known audit findings
Design for explainability	Evidence bundle per invoice	PO match, clause, vendor master, confidence

14.3.3 System Shape

User surface

The user surface includes an inbox view showing pending invoices, confidence scores, and exception flags. The detail view shows extracted fields, matches, proposed coding, and the approver chain.

Scaffold

The scaffold is a state-machine with explicit states and approval gates. The states are: (1) Ingest—extract fields and classify invoice type; (2) Match—PO match, vendor lookup, contract clause retrieval; (3) Code—assign GL codes, cost centres, and tax treatment; (4) Route—determine approval path based on policy; (5) Stage—hold for review before commit; (6) Commit—approved by human and posted to ERP. Each state produces a typed artifact with provenance.

Tool contracts

The tools are: extract_invoice(doc) -> InvoiceFields which is read-only; po_match(invoice_fields) -> MatchResult which is read-only; lookup_vendor(vendor_id) -> VendorRecord which is read-only; and stage_posting(invoice_id, coding, evidence) -> StagingRecord which writes to staging, not ERP.

14.3.4 Harnesses and Evaluation Setup

Harness types

The offline replay harness replays historical invoices with known outcomes and compares recommendations. The control red-team harness uses synthetic invoices to probe bypass attempts including splits, duplicates, over-limit, and wrong vendor. The shadow-mode harness logs recommendations without acting and compares against human decisions. The canary harness uses limited vendors and business units with strict rollback triggers.

Metrics

Control metrics are hard gates. They include unauthorised payment suggestions which must be zero, wrong approver path rate, and duplicate detection rate. Accuracy metrics include correct coding and cost centre, and correct exception classification. Efficiency metrics include cycle time reduction and touches per invoice. Risk metrics include "if blindly followed" breach potential and confidence calibration comparing confidence to actual correctness.

Evaluator stack

Deterministic validators check thresholds, approval matrices, and policy constraints. LLM-as-judge evaluates explanation quality and evidence consistency but is never the sole control. Audit and SME reviews cover sampled invoices and all exceptions.

What to test (minimum set)

Duplicate and near-duplicate detection
Split invoicing attempts to bypass thresholds
Mismatched PO quantities and amounts
Evidence trace completeness so auditors can reconstruct the decision

14.3.5 Governance and Lifecycle Aspects

This use case should be treated as high risk because it sits near financial decisions.

Internal audit and risk are involved from design, not as a gate at the end. The AI dossier explicitly ties control objectives, tool scopes, evaluation results, and residual risks and mitigations.

Any change to approval matrices, thresholds, or policy rules triggers offline regression runs, red-team suite runs, and a controlled rollout from shadow to canary.

14.3.6 Outcomes, Anti-patterns Avoided, Lessons

Illustrative outcomes you can measure

Expect 30% to 40% reduction in average processing time for in-scope invoices. High accuracy on non-exception invoices with exceptions routed faster. No increase in control breaches and often improved detection of duplicates.

Anti-patterns avoided

The team avoided autonomous payment fantasies. They avoided treating evaluation as a one-time certification. They avoided storing only the final answer without the evidence trail.

Lessons

Evidence bundles are not paperwork. They reduce investigation time and make rollout safer. Confidence and conservative automation are product features. Risk and audit co-design creates better tests and smoother sign-off.

📚 Related sections: - Risk table → Chapter 11, §11.0 - Governance requirements → Chapter 12, §12.2 - Runaway agent failure → Chapter 14, §14.6.1

14.4 Other Case Sketches

These sketches reuse the same template in short form. Their purpose is to show what changes when the action class, risk, and users change.

14.4.1 IT Service Desk Agent

The context and goal is to triage common IT issues such as password resets, VPN access, and software installs. The aim is to reduce queue length and resolution time. The distinctive constraints are that security and identity policies dominate. Define clear "do not attempt" zones. The scaffold is Plan-Execute with strong clarification patterns and a state machine for common flows. Tools include ITSM for ticket read/write, knowledge base search, and identity management which is highly controlled and requires approval. Harness focus is on replaying historic tickets, measuring first-contact resolution and re-open rates, and adversarial prompts for social engineering. Governance requires security operations sign-off and strict audit logs for any identity-related action.

14.4.2 Contact Centre Triage and Summarisation Agent

The context and goal is to assist agents in high-volume CX by summarising interactions, suggesting next actions, and surfacing knowledge articles. The distinctive constraints are privacy, tone, and compliance. Summaries must not invent facts. The scaffold is streaming summarisation plus a compliance critic pass. Tools include CRM read, KB retrieval, and QA checklist tools. Harness focus is on multi-turn evaluation on call logs, compliance rubrics, and CSAT and after-call work time. Governance requires PDPA and recording policies and periodic audits for bias or omissions.

14.4.3 CRM Sales Co-pilot

The context and goal is to prep for meetings, draft emails, update opportunities, and improve pipeline hygiene. The distinctive constraints are external messaging risk. Hallucinated commitments are banned. The scaffold is ReAct-style retrieval plus drafting with preview-to-commit for any write. Tools include CRM, email drafts, call notes, and account insights. Harness focus is on draft quality rubrics, factuality checks against CRM, and outcome metrics like forecast quality and stage-change integrity. Governance requires rules for data sharing and safe claims and approval flows for outbound messages.

14.4.4 Contract Review and Risk Screening Agent

The context and goal is to screen contracts for standard clauses, highlight deviations, and flag risks. The distinctive constraints are explainability and traceability. No autonomous approval is permitted. The scaffold is a critic-builder pattern with clause extraction followed by risk critique. Tools include template library, clause taxonomy, and retrieval over an approved precedent set. Harness focus is on golden sets labelled by legal SMEs, rubric-based judging for issue detection, and false-negative analysis. Governance requires strong record-keeping of what was flagged or missed and periodic calibration against new case law or policy.

14.4.5 Scheduling and Coordination Agent

The context and goal is to coordinate meetings or field operations and manage constraints and preferences. The distinctive constraints are high-impact writes and user intent. Mistakes create real disruption. The scaffold is multi-agent orchestration with a constraints agent, calendar agent, and negotiation agent. Tools include calendars, room booking, resource systems, and notifications. Harness focus is on a simulation harness that generates scheduling scenarios with success defined by constraint satisfaction and user acceptance. Governance requires clear rules for what the agent may schedule, logging of decisions, and approval for external coordination.

14.5 Cross-Case Patterns and How to Apply Them

Across all cases, the same recurring lessons show up.

1. Start from constraints, then pick patterns. The action class, data sensitivity, and autonomy level determine the scaffold, tool design, and harness strategy.

2. Treat the scaffold as behavioural architecture. ReAct, Plan-Execute, state machines, and manager-worker patterns are not academic. They are how you keep behaviour predictable enough to test, explain, and govern.

3. Evaluation is a live system. Golden sets, red-team suites, and judge prompts must be maintained like code. Every meaningful change—model, prompt, tools, corpus, policy—should trigger a regression run.

4. Evidence bundles earn autonomy. Autonomy expands only when evidence supports it. Make "what evidence is required" explicit before you raise autonomy, not after an incident.

5. Escalation is a designed success path. Every case needs a safe way to say "I cannot proceed" and hand off with enough context for a human to finish quickly.

A practical checklist you can reuse across a portfolio:

What is the action class, and what is the highest-impact side effect?
What are the non-goals, explicitly?
What is the smallest autonomy level that creates value?
What is your metrics registry, and what are your hard fail gates?
What is your golden set coverage plan, by cohort?
What is your red-team plan, and who owns it?
What does the evidence bundle contain for a release?
What is the escalation workflow, and what does the handoff include?
What are your control surfaces in production (flags, budgets, kill switch)?
What changes over time (policies, tools, data), and what is the change gate?

The point of these case studies is not to copy an architecture verbatim. It is to copy the discipline: scope, contracts, evidence, and lifecycle operations.

14.6 Lessons from Failures

Every case study so far describes what worked. This section describes what goes wrong. These are composite cases drawn from real failure patterns. They are not single deployments but common anti-patterns that recur across organizations.

14.6.1 The Runaway Invoice Agent

What was built: A multi-agent system for end-to-end invoice processing—intake, matching, coding, approval routing, and exception handling—with the goal of "minimal human touch."

What went wrong: The system worked in demos but failed catastrophically in production.

The failure cascade

The exception-handling agent was designed to "keep trying until it finds a solution." For a mismatched invoice, it would query the vendor database with no match, search email history with no match, attempt fuzzy matching on PO descriptions with partial matches, generate clarification questions sent to the wrong person, retry with different parameters, and loop for 47 steps before timeout.

A single complex invoice could cost $15+ in API calls and take 20 minutes of compute time. The finance team did not notice until the monthly bill arrived.

The coding agent and approval routing agent had inconsistent assumptions about cost center hierarchies. Edge cases produced valid-looking but incorrect coding. Approvers rubber-stamped because "the AI did it."

The system had a step limit of 50 but no quality gate. It would produce an answer after 50 steps regardless of whether it was correct.

Table 13.4 — Runaway Invoice Agent: Root causes

Anti-pattern	Manifestation	What should have been done
No verification loop	Agent output went directly to approval	Critic agent or deterministic validation before approval
Unbounded retry	"Keep trying" without termination criteria	Explicit failure states, max 3 attempts then escalate
Multi-agent without clear contracts	Agents had implicit assumptions	Explicit schemas and contracts between agents
Cost not treated as constraint	No per-task budget	$0.50 budget per invoice, alert if exceeded
Success defined as "produces output"	Any answer counted as success	Success = correct answer verified by rules

Figure 13.3 — How it should have been built

flowchart TD
  A[Invoice intake] --> B{Simple match?}
  B -->|Yes| C[Auto-code and route]
  B -->|No| D[Exception agent: 3 attempts max]
  D -->|Resolved| C
  D -->|Unresolved| E[Human queue with context pack]
  C --> F{Coding validation passes?}
  F -->|Yes| G[Route to approver]
  F -->|No| E
  G --> H{High value?}
  H -->|Yes| I[Require human approval]
  H -->|No| J[Auto-approve if rules pass]

Lessons

Multi-agent systems need explicit termination criteria at every handoff. Cost is a hard constraint, not a reporting metric. "Minimal human touch" should be earned, not assumed. Verification must happen before consequential actions.

14.6.2 The Confident Wrong Answer

What was built: An HR policy assistant that answered employee questions about benefits, leave, and company policies using RAG over the HR knowledge base.

What went wrong: The agent gave confident, well-formatted, and wrong answers that employees acted on, causing real harm.

The failure pattern

An employee asked about parental leave for adoptive parents. RAG retrieved chunks about "parental leave" and "adoption benefits" but not the specific policy for adoptive parent leave. The model synthesized a plausible-sounding answer from general parental leave policy. The answer was wrong because adoptive parents had a different and more generous entitlement.

The response was well-written and cited "HR Policy Section 4.2." The citation was real but the interpretation was wrong. The employee acted on it, discovered the error months later, and missed the benefits window.

The agent never said "I'm not sure" or "you should verify with HR." Confidence was not calibrated to retrieval quality. Edge cases got the same confident tone as common questions.

HR discovered the error through a complaint. There was no mechanism to trace back to the agent interaction. There was no systematic check for similar errors. The same error likely occurred multiple times before discovery.

Table 13.5 — Confident Wrong Answer: Root causes

Anti-pattern	Manifestation	What should have been done
Retrieval-generation gap	Model hallucinated when retrieval was partial	Explicit "evidence sufficiency" check before answering
Miscalibrated confidence	Same confident tone regardless of certainty	Confidence score tied to retrieval quality
Citation without verification	Cited documents without checking coverage	Verify answer is actually supported by cited content
No uncertainty UX	Binary answer/don't-answer	Graduated response: certain/likely/unclear/unknown
No feedback capture	Error discovered by accident	Systematic sampling and SME review

What good looks like:

response_confidence_levels:
  high:
    criteria: 
      - direct_match_in_policy: true
      - multiple_supporting_chunks: true
      - no_contradicting_info: true
    ux: "Answer with citation, no hedging"

  medium:
    criteria:
      - related_content_found: true
      - partial_coverage: true
    ux: "Answer with caveat: 'Based on general policy, but I recommend confirming with HR for your specific situation'"

  low:
    criteria:
      - tangentially_related_only: true
    ux: "I found related information but couldn't find a specific answer to your question. Here's what I found: [excerpts]. I recommend contacting HR directly."

  none:
    criteria:
      - no_relevant_retrieval: true
    ux: "I don't have information about this in my knowledge base. Please contact HR at hr@company.com"

Lessons

Fluent generation is not evidence of correctness. Confidence must be calibrated to evidence quality. Citations require verification, not just attribution. Edge cases need different handling than common cases. Feedback loops must be designed, not assumed.

14.6.3 The Shadow AI Problem

What was built: A contact center agent assist tool that suggested responses, summarized conversations, and recommended next actions.

What went wrong: After initial excitement, usage dropped to near-zero. The tool became "shelfware" while costing $50K/month in API fees.

The adoption failure pattern

In weeks 1-2 there was high engagement as agents were curious about the new tool. In weeks 3-4 usage dropped to power users only. In month 2 most agents actively avoided the tool and reverted to the old process. In month 3 management noticed low adoption and mandated usage. In month 4 agents gamed metrics by opening the tool but ignoring suggestions. In month 6 the tool was quietly deprecated.

Table 13.6 — Shadow AI: Why adoption failed

Factor	What happened	What was missed
Workflow mismatch	Tool required switching apps mid-call	Should have integrated into existing call interface
Latency	Suggestions arrived 5+ seconds after needed	Useless for live conversation pacing
Irrelevance	Generic suggestions didn't match actual conversation	No learning from corrections, static prompts
Trust deficit	A few bad suggestions killed confidence	No confidence indicators or quality signals
No feedback loop	Agents had no way to improve the tool	Corrections weren't captured or used
Metrics mismatch	KPIs didn't change, so why use it?	No credit for AI-assisted resolutions

The deeper problem

The team built and evaluated the tool in isolation. They tested on historical transcripts and offline eval passed. SMEs approved response quality and quality eval passed. Security review passed and safety eval passed. But they never tested with agents in their real workflow.

What would have caught this

Observation sessions would have let them watch agents work and understand their actual cognitive load. Workflow mapping would have shown where the tool fits in the existing process. Latency requirements would have defined the acceptable delay for each use case. A pilot with real users—a 2-week pilot with 10 agents—would have measured actual adoption. Feedback mechanisms would have given agents a way to tell the team the tool was wrong or unhelpful. Success metrics would have defined what changes for agents if they use this effectively.

The rebuild

Six months later the team rebuilt with a different approach:

design_principles:
  - "No app switching: embed in existing call interface"
  - "Pre-call, not mid-call: brief before pickup, not suggestions during"
  - "Agent controls timing: surface when asked, not constantly"
  - "Capture corrections: every 'not useful' click improves the model"
  - "Measure what matters: first-call resolution, not 'AI suggestions shown'"

pilot_gates:
  week_1:
    - 10 agents, voluntary use
    - measure: adoption rate, override rate, qualitative feedback
    - pass_criteria: >50% daily use, <30% immediate dismissal

  week_2:
    - same agents, incorporate week 1 feedback
    - measure: sustained use, task completion impact
    - pass_criteria: maintained adoption, net positive sentiment

  week_3_4:
    - expand to 50 agents
    - measure: all above plus handle time, FCR
    - pass_criteria: no degradation in KPIs, continued adoption

Lessons

Offline eval success does not equal production adoption. Workflow fit matters more than feature quality. User research is not optional for productivity tools. Feedback loops enable improvement. Without them you are flying blind. Pilot gates should measure adoption, not just accuracy.

14.6.4 Cross-failure patterns

Across these three failures, common themes emerge.

Table 13.7 — Cross-failure patterns

Pattern	Runaway Invoice	Confident Wrong	Shadow AI
Termination criteria	Missing	N/A	N/A
Verification loop	Missing	Missing	N/A
Confidence calibration	N/A	Missing	Missing
Workflow fit	Assumed	Assumed	Missing
Feedback loop	Missing	Missing	Missing
Cost as constraint	Missing	N/A	Missing
User research	Skipped	Skipped	Skipped
Pilot gates	Weak	Weak	Missing

The meta-lesson

Each failure could have been prevented with practices already described in this handbook. Scaffolds with explicit termination are covered in Chapter 4. Confidence calibration in evaluation is covered in Chapter 6. User research in evaluation is covered in Chapter 7, Section 7.5. Workflow fit assessment is covered in Chapter 3, Section 3.1. Feedback loops and continuous improvement are covered in Chapter 7.

The teams that failed did not lack capability. They skipped the discipline. These case studies exist as reminders that the "boring" parts of the process exist for reasons that only become obvious in failure.

14.6.5 Failure prevention checklist

Before launching any agent, review against these failure modes.

Termination and bounds:

[ ] Every loop has explicit termination criteria
[ ] Step limits are set and enforced
[ ] Cost budgets are defined per task
[ ] Failure states are designed, not just success paths

Verification and confidence:

[ ] Outputs are verified before consequential actions
[ ] Confidence is calibrated to evidence quality
[ ] Uncertainty is surfaced in UX, not hidden
[ ] Citations are verified, not just attributed

Workflow and adoption:

[ ] User research conducted with real workflows
[ ] Latency meets workflow requirements
[ ] Integration minimizes context switching
[ ] Success metrics align with user incentives

Feedback and improvement:

[ ] Correction capture is designed into UX
[ ] Feedback flows to evaluation datasets
[ ] Error patterns are systematically reviewed
[ ] Improvements are validated against feedback

14.6.6 Using failure cases in your team

These cases work as teaching tools.

In design reviews, ask questions like: "How is this different from the Runaway Invoice Agent?" or "What's our termination criteria if retrieval fails?" or "How would we discover a Confident Wrong Answer scenario?"

In retrospectives, ask questions like: "Did we have any Shadow AI signals this sprint?" or "What adoption barriers did we miss?"

In training, walk through each failure case with new team members. Ask them to identify the anti-patterns before revealing the root causes. Have them map failures to handbook principles.

In governance, include failure mode review in lifecycle gates. Ask "which of the three failure patterns is this most at risk for?" Require mitigation evidence for each relevant pattern.

📚 Related sections: - Problem selection → Chapter 3, §3.1 - User research → Chapter 7, §7.5 - Cost control → Chapter 11, §11.6 - Confidence calibration → Chapter 10, §10.4

13.7 Key Takeaways

One template, many domains — The six-part case structure (context, principles, system shape, harnesses, governance, outcomes) works across every agent type because the underlying design discipline is domain-independent.
Constraints before patterns — The action class, data sensitivity, and autonomy level should determine your scaffold, tool design, and evaluation strategy; never pick an architecture first and retrofit the constraints.
Evidence earns autonomy — Progressive autonomy (suggest-only to execute-with-approval) succeeds when each level-up is backed by measurable evidence from golden sets, red-team runs, and production telemetry.
Escalation is a designed success path — Every agent needs a well-designed way to say "I cannot proceed" and hand off with enough context for a human to finish quickly; this is a product feature, not a governance checkbox.
Failure cases are as instructive as successes — The Runaway Invoice Agent, Confident Wrong Answer, and Shadow AI cases each trace back to skipped disciplines, not missing capabilities; study what went wrong to avoid repeating it.
Evaluation is continuous, not ceremonial — Golden sets, red-team suites, and judge prompts must be maintained like production code; every change to models, prompts, tools, or policy should trigger a regression run.
Workflow fit trumps feature quality — An agent that scores well on offline evaluations but ignores real user workflows, latency constraints, and adoption incentives will become expensive shelfware.

Start building → Return to the quick-start paths or revisit any chapter to go deeper on a specific topic.

Appendix	Focus	Key Sections
B	Architecture and patterns	B.1–B.5
C	Prompts and evaluation rubrics	C.1–C.5
D	Synthetic test datasets	D.1–D.5
E	Code implementation	E.1–E.7