Chapter 13 — The Six-Scenario Playbook
Every item on the exam sits inside one of these six scenarios. Four are drawn at random for your sitting. Because they're published in the exam guide, you can walk in already knowing the context, the tools, the failure modes, and the shape of the right answers.
This is the cheapest advantage available on this exam. Work through all six.
For each scenario: the setup, the domains it draws on, its recurring question archetypes, and the reflexes that resolve them.
Scenario 1 — Customer Support Resolution Agent
Setup. An agent built with the Claude Agent SDK, backed by custom MCP tools: get_customer, lookup_order, process_refund, escalate_to_human. Target: 80%+ first-contact resolution.
Domains: 1 (Agentic Architecture), 2 (Tools & MCP), 5 (Context & Reliability).
Why this scenario exists: it's the one with money and irreversibility in it. Almost every enforcement item lives here.
Archetype 1 — Ordering enforcement 🎯🎯
"
process_refundis sometimes called beforeget_customerverifies identity. The system prompt already instructs verification first."
Answer shape: a programmatic prerequisite gate blocking process_refund until a verified ID exists. Not few-shot, not a better prompt, not merging the tools.
Reflex 1. The tell is "financial consequence" plus "the prompt already says so."
Archetype 2 — Refund limits and redirection 🎯
"Refunds over $500 must not be processed automatically."
Answer shape: a tool-call interception hook that blocks the call and redirects to escalate_to_human with an actionable reason. Block-and-redirect, never block-and-stop.
Reflex 1 + Chapter 04 §2.
Archetype 3 — Escalation criteria 🎯🎯
"The agent escalates too rarely when it should and too often when it shouldn't."
Answer shape: explicit criteria — explicit human request · policy exception or gap · inability to progress — reinforced with few-shot examples of each, including near-miss negatives. Distractors: confidence thresholds, sentiment analysis, tool-call counts, complexity. Reflex 10 + Chapter 12 §1.
Archetype 4 — Long-conversation fact loss 🎯
"Agreed refund amounts drift; customer-stated expectations get dropped."
Answer shape: a persistent structured "case facts" block outside the summarized history, re-injected each turn. Distractor: larger context window. Chapter 11 §1.
Archetype 5 — Heterogeneous backend formats 🎯
"Different systems return timestamps as Unix epochs and ISO 8601, and status as numeric codes. The agent occasionally misreads dates."
Answer shape: a PostToolUse hook normalizing every result before it enters the conversation.
Distractor: describe the formats in the system prompt.
Chapter 04 §2.
Archetype 6 — Ambiguous customer identity 🎯
"
get_customerreturns three possible matches."
Answer shape: ask for an additional identifier. Never select the most likely. Chapter 12 §1.
Archetype 7 — Handoff content
"What should the agent pass when escalating?"
Answer shape: a structured summary — customer ID, root cause, refund amount, recommended action. Not the raw transcript. Chapter 04 §3.
Archetype 8 — Tool errors
"The refund window has expired."
Answer shape: isError: true, errorCategory: "business", isRetryable: false, human-readable reason, alternative (escalate for policy exception). Business rules are never retryable.
Chapter 06 §2.
Scenario 1 in one line: money → gates; long conversations → pinned facts; escalation → situational triggers only.
Scenario 2 — Code Generation with Claude Code
Setup. A development team using Claude Code: custom slash commands, CLAUDE.md configuration, and a choice between plan mode and direct execution.
Domains: 3 (Claude Code Config & Workflows), 5 (Context & Reliability).
Why this scenario exists: it's the pure configuration scenario. Exact paths matter more here than anywhere else on the exam.
Archetype 1 — Team-wide commands 🎯🎯
"The team wants standardized slash commands available to every developer."
Answer shape: one Markdown file per command in .claude/commands/, committed.
Distractors: a commands array in .claude/config.json (doesn't exist), ~/.claude/commands/ (not shared), wiki documentation (not a mechanism).
Chapter 07 §3.
Archetype 2 — Cross-cutting conventions 🎯🎯
"Test conventions apply to test files spread across dozens of directories, and shouldn't load during unrelated work."
Answer shape: .claude/rules/ with paths: frontmatter globbing **/*.test.tsx.
Distractors: root CLAUDE.md (always loaded), per-directory CLAUDE.md (unmaintainable duplication).
Chapter 07 §2.
Archetype 3 — Plan mode vs direct execution 🎯🎯
"Decompose a monolith into microservices" vs "add a null check."
Answer shape: plan mode when any of — large scale, multiple viable approaches, architectural decision, multi-file coordination. Direct execution for well-scoped single changes. Discriminator: is there a decision to review, or just work to do? Chapter 08 §1.
Archetype 4 — Personal vs shared configuration 🎯
"This developer prefers verbose commit messages; the team hasn't standardized."
Answer shape: ~/.claude/CLAUDE.md — user-level, deliberately not shared.
Chapter 07 §1.
Archetype 5 — Skills vs CLAUDE.md 🎯
"CLAUDE.md has grown to include a long schema-migration procedure that applies to a handful of tasks."
Answer shape: move it to a skill (.claude/skills/<name>/SKILL.md). CLAUDE.md is always loaded; skills are on demand. Add context: fork if the procedure does verbose exploration.
Chapter 07 §4.
Archetype 6 — Configuration not taking effect 🎯
"The team added conventions but the agent doesn't follow them."
Answer shape: /memory to verify which files are actually loaded. Distinguishes "not loaded" (path problem) from "loaded and ignored" (vague content, or context dilution).
Chapter 07 §1.
Archetype 7 — Codebase exploration flooding context 🎯
"Discovery fills the session with file dumps before work begins."
Answer shape: the Explore subagent — verbose discovery in an isolated context, summary returned. Chapter 08 §1.
Archetype 8 — Underspecified requirements
"The developer keeps getting output that doesn't match their intent."
Answer shape: the interview pattern (have Claude ask clarifying questions first) and 2–3 concrete input/output examples. Not "write a longer prompt." Chapter 08 §2.
Scenario 2 in one line: team-wide → project path committed; personal → home; file-type scoping → .claude/rules/ globs; decisions → plan mode.
Scenario 3 — Multi-Agent Research System
Setup. A coordinator delegating to specialized subagents: web-search, document-analysis, synthesis, report-generation. Output: cited research reports.
Domains: 1 (Agentic Architecture), 2 (Tools & MCP), 5 (Context & Reliability).
Why this scenario exists: it's the orchestration scenario, and Domain 1 is 27% of the exam. Expect the most items here.
Archetype 1 — Narrow decomposition 🎯🎯
"Reports are thin. Logs show every subagent returned complete results with no errors, and all assigned subtasks concerned one narrow facet."
Answer shape: the coordinator's decomposition is at fault. Fix with scope partitioning across the topic's dimensions plus an iterative refinement loop that checks coverage and re-delegates gaps. Distractors: improve the subagents' prompts, add subagents, enlarge their context — all fix components that aren't broken. Chapter 03 §2. This is the highest-probability item in the scenario.
Archetype 2 — Duplicated subagent work 🎯
"Multiple research subagents return overlapping findings from the same sources."
Answer shape: explicit scope partitioning in each delegating prompt — "cover regulatory filings only; another agent is handling press coverage." Subagents are context-isolated and cannot know what others are doing. Chapter 03 §1–2.
Archetype 3 — Parallelization 🎯
"Four independent research streams run sequentially."
Answer shape: multiple Task tool calls in a single coordinator response.
Distractors: a parallel: true field (doesn't exist), separate coordinator processes.
Chapter 03 §3.
Archetype 4 — Delegation not happening 🎯
"The coordinator does all the work itself instead of delegating."
Answer shape: the coordinator's allowedTools must include "Task".
Chapter 03 §3.
Archetype 5 — Scoped tool access 🎯🎯
"The synthesis agent needs to verify facts. 85% of verifications can be done against already-collected sources."
Answer shape: a narrowly scoped verify_fact that checks against collected sources; route the 15% back through the coordinator.
Distractors: full web search, general fetch_url, routing everything to the coordinator.
Reflex 4 + Chapter 05 §2.
Archetype 6 — Access failure as empty result 🎯🎯
"A collection is inaccessible; the server returns an empty array with
isError: false; the report says no internal documents exist."
Answer shape: isError: true with errorCategory: "permission" and isRetryable: false. An access failure is not a valid empty result.
Chapter 06 §2.
Archetype 7 — Error propagation 🎯
"One subagent fails. What should happen?"
Answer shape: recover locally if possible; otherwise propagate structured context with partial results and annotate the coverage gap in the report. Distractors: suppress silently (confidently incomplete output) or terminate the workflow (throws away three successful streams). Chapter 12 §2.
Archetype 8 — Provenance through synthesis 🎯
"Citations no longer map to specific claims after synthesis."
Answer shape: preserve claim→source mappings through synthesis in a structured intermediate representation — never reattach afterward. Chapter 12 §4.
Archetype 9 — Conflicting sources 🎯
"Two credible sources report different revenue figures."
Answer shape: report both with attribution, including publication dates so a chronology isn't misread as a contradiction. Distractors: pick the more authoritative, take the most recent, average them. Chapter 12 §4.
Archetype 10 — Coordinator context degradation
"Subagents return long reasoning narratives; the coordinator starts losing track of findings."
Answer shape: require structured data returns, not verbose reasoning; put key findings first with explicit section headers. Chapter 11 §2.
Scenario 3 in one line: incomplete output with healthy subagents → coordinator decomposition; isolation means pass everything explicitly; failures propagate structured with partial results.
Scenario 4 — Developer Productivity with Claude
Setup. An Agent SDK agent combining built-in tools (Read, Write, Bash, Grep, Glob) with MCP servers. Purpose: explore unfamiliar codebases, understand legacy systems, generate boilerplate.
Domains: 2 (Tools & MCP), 3 (Claude Code), 1 (Agentic Architecture).
Why this scenario exists: it's where built-in tool selection is tested, and where large-codebase context management lands.
Archetype 1 — Grep vs Glob 🎯🎯
"Find all React test files across a monorepo where tests sit next to components."
Answer shape: Glob with **/*.test.tsx. Path pattern → Glob. Content search → Grep.
Chapter 06 §3.
Archetype 2 — Edit vs Read + Write 🎯
"The text to change appears several times with no unique surrounding context."
Answer shape: Read + Write. Edit requires a unique text anchor; when there isn't one, Edit is unusable. Chapter 06 §3.
Archetype 3 — Incremental codebase understanding 🎯
"How should the agent build an understanding of an unfamiliar codebase?"
Answer shape: Grep for entry points → Read to follow imports → repeat, narrowing. Traverse; never load everything. Chapter 06 §3.
Archetype 4 — Context degradation 🎯🎯
"The agent begins citing 'typical patterns' instead of the actual class and file names."
Answer shape: context degradation. Apply subagent delegation for exploration and a scratchpad file for established findings. Distractors: extended thinking, more detailed goal instructions, a bigger model. Chapter 11 §3.
Archetype 5 — MCP tool losing to a built-in 🎯
"We added an MCP knowledge-base search tool, but the agent keeps using Grep."
Answer shape: improve the MCP tool's description — when to use it, what it offers that Grep doesn't.
Distractors: remove Grep from allowedTools, instruct in the system prompt.
Chapter 06 §1.
Archetype 6 — MCP server distribution 🎯
"The team wants every developer to get the same MCP servers on clone, without committing credentials."
Answer shape: .mcp.json committed, with ${ENV_VAR} expansion for secrets.
Chapter 06 §1.
Archetype 7 — Too many tools 🎯
"Six MCP servers were configured; tool selection accuracy dropped."
Answer shape: tool distribution by role. 18 tools instead of 4–5 degrades selection. Every configured server is tool-count pressure, since all tools are discovered at connection time. Chapter 05 §2 + Chapter 06 §1.
Archetype 8 — Build vs adopt an MCP server 🎯
"The team needs Jira integration."
Answer shape: use an existing community MCP server for standard integrations. Custom servers are for proprietary internal systems. Chapter 06 §1.
Archetype 9 — Crash recovery in long tasks
"A multi-day migration was interrupted; the resumed run produced inconsistent conventions."
Answer shape: a structured state export / manifest that carries decisions and established conventions, not just a completed checklist. Chapter 11 §3.
Scenario 4 in one line: Glob for paths, Grep for contents, Edit needs a unique anchor; "typical patterns" means context degradation; MCP descriptions must earn selection.
Scenario 5 — Claude Code for Continuous Integration
Setup. Claude Code in CI: automated code review, test generation, PR feedback. Explicit requirement: minimize false positives.
Domains: 3 (Claude Code), 4 (Prompt Engineering & Structured Output).
Why this scenario exists: it's the precision scenario, and the home of the headless-CLI facts.
Archetype 1 — Headless invocation 🎯🎯
"Run reviews in CI with output a script can parse."
Answer shape: claude -p (--print) with --output-format json, and --json-schema to constrain the shape.
Distractors: CLAUDE_HEADLESS and --batch — neither exists.
Chapter 08 §3.
Archetype 2 — False positives destroying trust 🎯🎯
"40% of flagged issues are non-issues; developers now ignore the output. Coverage must be preserved."
Answer shape: identify the category producing most FPs, temporarily disable it, and rewrite its criterion as a determinate test. Distractors: "be conservative," "only high-confidence," permanently narrowing to critical-only (violates the coverage constraint), larger context window. Chapter 09 §1–2.
Archetype 3 — Vague criteria 🎯🎯
"'Check that comments are accurate' produces inconsistent findings."
Answer shape: "flag a comment only when the behaviour it claims contradicts the actual behaviour of the code." Plus explicit severity criteria with code examples, and explicit non-findings. Chapter 09 §1.
Archetype 4 — Attention dilution 🎯🎯
"PRs touch 12–20 files. Per-file performance in isolation is much better. The full diff fits in the context window."
Answer shape: per-file passes plus a cross-file integration pass. Distractor: a larger context window — the stem already told you it fits. Larger context does not fix attention dilution. Chapter 04 §4.
Archetype 5 — Self-review 🎯🎯
"The session that generated the code also reviews it and misses its own bugs."
Answer shape: review in a separate session with fresh context. The generating session carries the assumptions that produced the bug. Distractors: ask the same session to double-check, enable extended thinking. Independence, not depth. Chapter 08 §3 + Chapter 10 §5.
Archetype 6 — Batch scoping 🎯🎯
"Reduce cost: pre-merge review on every PR, plus a nightly aggregate report."
Answer shape: batch the nightly report only. Never batch a pre-merge gate — no latency SLA, up to 24 hours. Chapter 10 §4.
Archetype 7 — CI context 🎯
"The CI reviewer flags deliberate patterns in our codebase as problems."
Answer shape: CLAUDE.md (and .claude/rules/) carry project context into CI, giving the agent the conventions a human reviewer would have.
Chapter 08 §3.
Archetype 8 — Diagnosing false positives 🎯
"We know 40% are wrong but not which criteria are responsible."
Answer shape: emit a detected_pattern field naming the triggering criterion, so FPs can be analysed by category.
Chapter 09 §2.
Archetype 9 — Ambiguous-case inconsistency
"The reviewer treats borderline cases inconsistently."
Answer shape: 2–4 targeted few-shot examples, including a near-miss negative. Chapter 09 §3.
Scenario 5 in one line: -p for CI; precision is the binding constraint; split passes for dilution; review in a fresh session; batch only what nobody waits for.
Scenario 6 — Structured Data Extraction
Setup. A pipeline extracting structured data from documents with JSON-schema validation, high accuracy requirements, graceful edge-case handling, and downstream system integration.
Domains: 4 (Prompt Engineering & Structured Output), 5 (Context & Reliability).
Why this scenario exists: it's the schema scenario, and the home of the syntax-vs-semantics distinction.
Archetype 1 — Semantic errors 🎯🎯
"All output is valid JSON conforming to the schema, but in 6% of invoices the line items don't sum to the total."
Answer shape: a semantic validation step — recompute and compare, plus in-schema self-correction (calculated_total vs stated_total + conflict_detected), with retry-and-feedback.
Distractor: "tighten the JSON schema" — a schema cannot express a cross-field arithmetic relationship.
Chapter 10 §1, §3.
Archetype 2 — Reliable schema conformance 🎯
"How do we guarantee schema-conformant output?"
Answer shape: a tool whose input_schema is your output schema, forced with tool_choice: {"type": "tool", "name": ...}.
Chapter 10 §1.
Archetype 3 — Fabricated values 🎯🎯
"When a document has no PO number, the model invents one."
Answer shape: make the field nullable, with "null if absent; never infer" in its description. Chapter 10 §1.
Archetype 4 — Unclassifiable documents 🎯
"Documents outside our known types get silently misclassified."
Answer shape: add "unclear" and "other" enum values plus a detail string field. The detail field is how the enum evolves.
Chapter 10 §1.
Archetype 5 — Format ambiguity 🎯
"Dates arrive in several formats; some are ambiguous between day-first and month-first."
Answer shape: explicit normalization rules in the prompt alongside the strict schema — including what to do when genuinely ambiguous (null plus an ambiguity flag). Chapter 10 §1.
Archetype 6 — Retry design 🎯
"Validation fails on some extractions."
Answer shape: resend the document + the failed extraction + the specific validation errors.
And: ⚠️ retry is useless when the information is absent from the source → nullable field, "unclear", or human review.
Chapter 10 §2.
Archetype 7 — Batch pipeline design 🎯
"50,000 documents to process overnight, first run."
Answer shape: refine the prompt on a sample synchronously first, then batch. Use custom_id for correlation and resubmit only failed custom_ids with modifications.
Facts: 50% savings · up to 24 h · no latency SLA · no multi-turn tool calling in a single request (single-pass extraction is fine).
Chapter 10 §4.
Archetype 8 — SLA arithmetic 🎯
"Results must be available within 30 hours of arrival; batch takes up to 24."
Answer shape: worst case = submission interval + full processing window. ≤ 6-hour intervals satisfy 30 hours; 4-hour windows give margin. Chapter 10 §4.
Archetype 9 — Automating away human review 🎯🎯
"97% aggregate field-level accuracy. Leadership wants to remove review."
Answer shape: measure per document type AND per field; automate only the qualifying combinations. Aggregate accuracy masks per-type failure. Distractor: "97% exceeds the target, proceed" — true arithmetic, wrong architecture. Chapter 12 §3.
Archetype 10 — Sampling design 🎯
"How should the remaining human review be sampled?"
Answer shape: stratified random sampling by document type and field. Distractors: uniform 5% (under-samples rare risky types), first-N-of-batch (not random). Chapter 12 §3.
Archetype 11 — Confidence-based routing 🎯
"Route low-confidence extractions to humans."
Answer shape: legitimate only with field-level confidence calibrated on a labeled validation set. Raw self-reported confidence is not a routing signal. Chapter 12 §3.
Scenario 6 in one line: schemas fix syntax not meaning; nullable fields and escape-hatch enums prevent fabrication; validate per type-and-field before automating.
Cross-scenario summary — the answer that's right in every scenario
If you remember nothing else from this chapter:
| Situation, in any scenario | Answer |
|---|---|
| Money, compliance, or irreversibility involved | Deterministic gate or hook |
| Wrong tool being selected | Fix the descriptions |
| Output incomplete but components healthy | Fix the coordinator's decomposition |
| Performance degrades with volume, content fits | Split into focused passes |
| A component needs to report a failure | Structured error with category and retryability, plus partial results |
| Something must be shared with the team | Project path, committed |
| Something is personal | Home directory |
| Data might be absent from the source | Nullable field or escape-hatch enum |
| A metric looks good in aggregate | Break it down before trusting it |
| An option mentions a larger context window, self-reported confidence, or sentiment | It's the distractor |