The Six Scenarios, Worked

A support agent has a verified duplicate charge, a refund tool and an angry customer. Should it refund the charge, ask another question or hand the case to a person? The answer depends on the order record, the policy and what the customer asked for. The six scenarios in this chapter put the book’s design decisions into cases like this, where several useful techniques are available and only some address the problem.

The exam presents four of six production scenarios. Here, six worked items introduce those scenarios, followed by a complete Customer Support agent design and shorter designs for the other five. A further twenty-seven items bring the practice bank to thirty-three. The support design connects the tools, permissions, context and recovery decisions developed in the preceding chapters; the shorter designs show how those decisions change with the workload.

How an item is built

Each item asks you to choose a design under stated constraints. Read the requested outcome and the answer count before comparing the options.

An exam item gives you a stem describing a situation inside one of the six scenarios, then four or five options, and the stem tells you how many of them are correct. Read that number as part of the question, because it is the only thing that distinguishes the two formats. A multiple-choice item has exactly one correct option; a multiple-response item says “select two” and has exactly two, both of which have to be right for the item to score. Everything not keyed is a distractor — and good distractors are not nonsense. They are built one of three ways, and all three appear below:

• A real principle applied to the wrong situation. Retrying is correct for a transient failure and wrong for a business rule. The distractor offers the retry.
• The right instinct taken one step too far. Escalating is correct for a demand and wrong for a complaint. The distractor escalates both.
• Something that sounds like more rigor but is not. A bigger context window, a stricter schema, an aggregate accuracy number. Each buys something real — and none of them buys what the stem needs.

A distractor can be a useful technique applied to the wrong constraint. Retrying a transient failure makes sense; retrying a closed refund window does not. When two options look defensible, identify which fact in the stem separates them.

Use the same five steps for each item:

1. Name the objective. What outcome does the stem actually ask for? “Meets a 30-hour deadline” and “improves accuracy” are different questions, and an option can be excellent at the one you were not asked.
2. Mark the constraints. Every stem carries the clause that decides it — a deadline, a ceiling, a policy that covers or does not cover the request, a wording like “explicitly demands.” Find it before you look at the options.
3. Eliminate by failure mode. For each option, say the specific thing that goes wrong, not that it feels weak. An option you cannot fault is either the key or a gap in your knowledge, and telling those apart is the point of the exercise.
4. Check the count. If it says select two, you owe two defensible options and no more. Picking one right answer on a select-two item scores the same as picking none.
5. Budget a review pass. Sixty items in the allotted time leaves room to revisit the ones you flagged. Change an answer when you can name the constraint you missed the first time — and only then. “Second thoughts” without a reason is a coin flip; a re-read that turns up a clause you skipped is new evidence.

Six items, worked

Item 1 — Customer Support Resolution Agent

A customer writes: “This is the third time I’ve contacted you about this charge and I’m getting nowhere. I want it fixed.” The session is authenticated and the account is the writer’s own. The agent has get_customer, lookup_order, search_orders, process_refund, and escalate_to_human. The two prior contacts are on the case record: both were closed without action because the earlier agent could not identify the order. The charge is a duplicate billing of $47.50, the refund policy covers duplicate charges explicitly, and $47.50 is under the amount that requires human approval. What should the agent do?

A. Call escalate_to_human immediately, given the customer’s evident frustration. B. Look the charge up, confirm from the order record that it is the covered duplicate, acknowledge the frustration, refund it with process_refund under an idempotency key minted for this case, and escalate only if the customer then asks for a person. C. Refund the amount straight from the customer’s description of the charge, without looking it up, since the policy covers duplicates. D. Ask the customer whether they would prefer to speak to a human before doing anything.

Correct: B.

The discriminating clause is “I want it fixed.” That is a complaint — not a demand for a human. The customer wants the outcome; nothing in the message asks for a person. The issue is in policy and within the agent’s capability, so the agent resolves it and acknowledges the frustration on the way.

The stem supplies the facts that make the refund permissible: authenticated identity, an amount below the approval threshold, an explicit policy match and a record explaining the two earlier failures. Change one and the next action may change. An unauthenticated session needs verification. An amount above the threshold needs human approval. A record showing an earlier successful refund needs a duplicate-payment check. A production agent must establish those facts through the lookup and validation steps in B.

Why A is tempting and wrong. It reads sentiment as an escalation trigger. Sentiment is an unreliable proxy for complexity, and three prior contacts describe the history — not the difficulty. An angry customer with a simple in-policy request does not need a human. Escalate on an explicit request, a policy gap, or an inability to progress, and this stem contains none of the three.

Why D is subtler and still wrong. Offering the escalation looks respectful — and it converts a resolvable case into a routing decision the customer now has to make. It also spends a turn before doing anything useful. Acknowledge, resolve, and honour a request for a human if one actually arrives.

Why C fails on a different axis. It reaches the same refund by skipping the step that makes it defensible. Acting on the customer’s description of a charge rather than on the order record means the agent has verified nothing: not that the duplicate exists, not that it has not already been refunded on one of the two prior contacts, not that the amount is what was said. It is also the option that most resembles a real production bug, because it looks efficient and it works most of the time.

Change the request to “I want to speak to a manager” and the agent should escalate immediately. Frustration alone does not make that request; the customer’s wording does.

Item 2 — Structured Data Extraction at volume

You must process 40,000 documents through a single-shot extraction prompt. The business requires every result within 30 hours of its source file landing, and files land continuously. Batch processing carries a hard 24-hour ceiling with no guarantee of when inside it a batch finishes, and a resubmitted batch is bound by the same ceiling. Which two design choices meet the requirement? (Select two.)

A. Use the synchronous API for all 40,000 documents so every one completes predictably. B. Use the Batches API and submit accumulated documents every 4 hours. C. Use the Batches API and submit one batch per day at midnight. D. On completion, resubmit the failed items, identified by custom_id, in a follow-up batch with fixes applied. E. On completion, re-run the failed items, identified by custom_id, through the synchronous API with fixes applied.

Correct: B and E.

Do the arithmetic, because the arithmetic is the item. Call the submission interval W and the reserve left for repairing failures R. A document that lands one minute after a submission waits almost the whole of W, then runs for at most 24 hours. So the deadline holds only when W + 24 + R ≤ 30. At W = 4 that is 4 + 24 = 28, which leaves R = 2 hours. Submit once a day instead and W is 23 hours 59 minutes, so the same document finishes at just under 48 hours. C misses by nearly a day, and it misses the same way whether you notice or not, since there is no error and the results eventually arrive.

Now spend R, which is where the real trap sits. A resubmitted batch is a batch, so it gets its own 24-hour ceiling. D therefore costs 4 + 24 + 24 = 52 hours in the worst case, which is 22 hours past a deadline it was chosen to protect. The repair has to run on a path whose latency you can bound, and that is the synchronous API. A batch entry’s params are ordinary Messages API parameters, so the same forced-tool extraction runs unchanged as a synchronous call. Only the envelope changes.

The assumption that makes B and E hold, stated out loud. The failed fraction has to be small enough that your synchronous concurrency clears it inside those 2 hours. Measure that fraction on a pilot rather than assuming it. If failures grow past what R can absorb, the fix is a shorter W, because R is the residue of a ceiling that does not move. Keep two failure classes out of the repair queue entirely: a refusal is not retryable and routes out of the pipeline, and a document that keeps hitting max_tokens is chunked before it is re-run rather than sent again as-is.

Why A is not a deadline guarantee. Choosing the synchronous API does not establish that capacity, rate limits and retries can clear 40,000 documents on time. A synchronous-only design could work with sufficient measured capacity, but A’s promise does not follow from the API choice. B and E use the stated batch ceiling and reserve synchronous capacity for the failed fraction; their two-hour repair assumption still needs validation.

Why D is the sharpest distractor here. It is right about the mechanism — and wrong about the clock. Results really do correlate by custom_id so that you can repair individual failures, and re-running only what failed really is better than resubmitting all 40,000. The clause that disqualifies it is the one the stem hands you: the ceiling applies to the second batch too.

The trap variant of this item swaps “single-shot extraction” for “an agent that looks up each vendor with a tool.” Then the whole answer changes. A batch request accepts tool definitions and can come back with a tool_use block, but it cannot execute that tool and continue the turn. Batch is one-and-done.

Item 3 — Multi-Agent Research System

A coordinator has dispatched four search subagents for an internal market-research brief. Publication policy allows a report with annotated coverage gaps; no source is mandatory. One subagent times out repeatedly against its source after three attempts, having already gathered two usable findings from other sources. What should that subagent return?

A. An empty result set, so the coordinator can proceed without special handling. B. A generic error string, “search unavailable,” so the coordinator knows something failed. C. A structured error carrying the failure type, what it attempted, the two partial findings, the resulting coverage gap, and alternative approaches. D. Raise an exception that terminates the research workflow so nothing incomplete is published.

Correct: C.

Why A is the most dangerous option on the page. It is silent suppression — dangerous precisely because everything downstream keeps working. The coordinator cannot distinguish “this source had nothing” from “this source was unreachable,” so the final report presents an absence of evidence as evidence of absence. The valid-empty-result versus access-failure distinction is a Domain 2 tool-design rule — and this is where it gets paid.

Why D is the opposite failure — under this stem. Terminating the workflow discards the good output of three healthy subagents, plus two findings from this one, all in the name of not publishing something incomplete. The blueprint’s answer to incompleteness is to annotate it, not to destroy the work.

The publication policy determines what the coordinator can do with the gap. If the missing source were mandatory, the coordinator would block publication while retaining the completed research. The failing subagent would still return C: its partial findings and failure details are useful in either case. What changes is whether the coordinator may publish the incomplete result.

Why B is nearly right and still loses. It reports the failure, which puts it ahead of A and D. But it hands the coordinator a string. The coordinator cannot tell that three attempts were already made, cannot recover the two findings, and has no idea which slice of the topic is now uncovered. Every recovery decision it might make is blocked by missing information the subagent had — and threw away. The four-field structure exists so the coordinator can choose intelligently among retrying differently, substituting a source, or proceeding with an annotated gap.

Note the pre-condition hiding in the stem: “after three attempts.” Local recovery for transient failures has already happened. Propagation is what you do after local recovery has failed, not instead of it.

Item 4 — Developer Productivity with Claude

An agent has been exploring an unfamiliar 300,000-line codebase for two hours. It has begun giving inconsistent answers and describing “typical patterns” instead of the specific classes it identified earlier. get_context_usage() reports the window at 71% and auto-compaction has not run. The exploration has hours left and must survive a restart. Which single change best addresses this?

A. Switch to a model with a larger context window. B. Have the agent write findings to scratchpad files and reference them; delegate specific investigations to subagents; summarize each phase before spawning the next. C. Increase max_tokens so the agent can produce more complete answers. D. Restart the session with a summary of everything discovered so far.

Correct: B.

The shift from named classes to generic patterns suggests that useful findings are getting lost in the growing conversation. B gives those findings a durable home: files survive a restart, subagents keep detailed exploration in separate contexts, and phase summaries carry selected conclusions into the next investigation. Those summaries still need checks for omitted names and decisions.

Why A does not address the stated symptoms. More capacity does not provide durable findings or a restart plan. The reported window usage leaves room, while the agent is already losing specificity. A bigger window buys more room to be read poorly, at higher cost and latency; it delays the capacity limit and does nothing for attention. B addresses preservation across the remaining work.

Why C is a category error worth recognizing. max_tokens bounds the output. It has nothing to do with how much input the model retains. Distractors that swap an output-side knob for an input-side problem are common — and free marks once you see them.

Why D is not wrong so much as incomplete. Restarting with a summary is real compaction and it will help once. It does nothing to stop the same degradation recurring in hour three, and the summary is where precise findings get lost. D is a recovery; B is a design — and the stem’s “hours left” and “must survive a restart” are what force the design.

The reported 71% usage gives no indication that the window is full. “Hours left” and “must survive a restart” make a durable preservation strategy necessary. If the exploration were nearly finished, a carefully checked summary and restart could be enough; here it would leave the next long phase with the same preservation problem.

Item 5 — Claude Code for CI/CD

A pipeline runs an automated review over a 40-file pull request in a single Claude Code invocation. The findings are inconsistent across files and miss an interface change that broke two downstream modules. Which change best addresses the scope problem behind both symptoms?

A. Ask the model to be more thorough and re-run the same single pass. B. Enable extended thinking for the review. C. Run a per-file pass over each file against a fixed rubric, then a separate cross-file integration pass over the module interactions, and merge the findings on location and claim. D. Have the session that generated the code review its own diff, since it has the most context.

Correct: C.

Two symptoms, two causes. Inconsistency across files is attention spread thin over a scope too large for one pass. The missed interface break is a different failure: no single-file pass can see an interaction between files, no matter how attentive. So the fix is two passes with different units. The file is the unit for local correctness; the data flow is the unit for integration correctness.

Be precise about what the split does and does not buy, because the option is easy to overread. Decomposing the scope fixes the coverage problem. It does not, by itself, make the findings consistent — two independent passes with no shared rubric produce two independently-worded verdicts on the same line, which is why the keyed option names the rubric and the merge as part of the architecture rather than leaving them implied. Three controls turn the split into a working reviewer, and each is a separate decision: a fixed rubric with categorical criteria, so “inconsistent” stops meaning “graded differently each time”; typed findings carrying file, line, category and severity, so they can be compared at all; and a merge on location and claim that keeps the highest severity and the union of fixes, so the same defect seen by both passes is reported once. Then the gate condition on top — which severities block the pipeline — is its own decision again. Two passes with none of that is better coverage and the same noise.

Why A and B are the same wrong answer in two costumes. Neither changes the scope. Asking for more thoroughness and enabling more reasoning both apply more effort to a pass whose problem is structural. The blueprint is explicit that this class of failure is not fixed by effort.

Why D is the most instructive distractor here. It is the right answer to a different question, and it is even correct about the facts: that session does have the most context. That is exactly what disqualifies it. A session invested in its own reasoning rationalizes past its own flaws, and “it has the most context” is the argument against it, not for it. A fresh reviewer should receive the requirements and rationale for unusual choices, then assess the diff against the shared rubric. Chapter 11 develops that separation, and item 31 tests the decision context that must be passed to each reviewer.

Item 6 — Structured Data Extraction, trust

An extraction pipeline reports 97% overall accuracy across six document types and eight fields. The team proposes disabling human review entirely, and routing any remaining spot-checks by the model’s self-reported per-field confidence. Which two objections are correct? (Select two.)

A. The aggregate figure can hide a segment, such as handwritten receipts or the tax_id field, performing far below it; accuracy must be validated per document type and per field. B. Self-reported confidence cannot be used for routing under any circumstances. C. Self-reported confidence is only a routing signal once calibrated against a labeled validation set, and calibration must be re-checked when the model, prompt, or input distribution changes. D. A stricter JSON schema would make human review unnecessary. E. The pipeline should move to synchronous processing to improve accuracy.

Correct: A and C.

A is the aggregate-accuracy trap stated plainly. Ninety-five percent clean invoices at 99% and 5% handwritten receipts at 70% blend to 97.6%, and that number is true while three in ten handwritten receipts are wrong forever.

C is the confidence rule stated with its condition attached, and the condition is what makes it correct rather than B.

Why B is the sharpest distractor in this chapter. It sounds like the cautious answer, and this book does say elsewhere that raw model confidence is noise. But the position across chapters 11, 13 and 14 is one sentence with three clauses: uncalibrated self-reported confidence is noise; calibrated against a labeled set it is a legitimate batch-review routing signal; it is never an escalation trigger for a live case. B collapses the second clause into the first. Batch review of an offline extraction workload is exactly the setting where calibrated confidence is the right tool. If an option about confidence contains no conditional, check whether it should.

Why D is the schema trap. A strict schema guarantees shape, not correctness. It will not tell you that a well-formed tax_id belongs to a different company. Syntax, not semantics.

Why E is a non sequitur. Synchronous versus batch is a latency and cost decision. It does not touch accuracy.

Scenario 1, carried end to end

Items test recognition. Building tests whether you actually know the material. Here is the Customer Support Resolution Agent as a complete design, with each decision traced to the chapter that argued for it: tool interface, working context, execution controls and recovery. Assemble this one yourself and the other five stop being unfamiliar.

The tools, and their descriptions. Offer five MCP tools: get_customer, lookup_order, search_orders, process_refund and escalate_to_human. Each description states the input format, an example, edge cases and the boundary against neighbouring tools. For example, lookup_order says “use this when you have a specific order ID; for finding orders by customer, use search_orders.” That guidance depends on search_orders being available. Keep the roster, descriptions, permission rules and test fixtures using the same five names.

The errors those tools return. Structured, never "Operation failed": an errorCategory of transient, validation, business or permission, an isRetryable boolean, and a human-readable message. A refund outside the return window is business and isRetryable: false, so the agent explains the closed window instead of burning turns retrying a rule that will never pass. A search returning three matches is a success, not an error, and the agent asks for a disambiguating identifier rather than picking one.

The context layout, in this order and for this reason. System prompt and tool definitions first; then the returns policy and escalation criteria; then a cache breakpoint; then the case-facts block; then the conversation. The policy is long and unchanging, so it belongs above the breakpoint. The case-facts block changes every time a tool discovers something, so it belongs below. Put it above and the prefix differs every turn, the cache is invalidated on every turn, nothing errors, and you pay full price forever. Confirm it with two per-response numbers rather than one running total: from the second turn onward, cache_read_input_tokens should be large and cache_creation_input_tokens near zero. A large creation figure on every call, with a read that stays at zero, is the broken layout.

CASE FACTS (verbatim, never summarized):
- as-of date: 2026-07-16
- order: A17    amount: $47.50    status: delivered 2026-06-01
- customer expectation: refund by Friday 2026-07-17
- policy: 30-day returns; window closed 2026-07-01; delivered 45 days ago -> outside window

The loop. Drive on stop_reason, never on parsed prose. Handle tool_use and end_turn, then handle the two a four-case loop forgets. refusal must not be retried, and model_context_window_exceeded is a full window — not a completion. Under the SDK, check is_error before subtype, because a rate-limited run reports subtype == "success" with the HTTP status in api_error_status.

The retries. The anthropic client already retries twice with jittered exponential backoff and honours retry-after, so do not add a third layer of attempts. Add a deadline, a retry budget, and a circuit breaker. Cut the default 600-second read timeout to something a waiting customer will tolerate. Tell transient from fatal by class: 400, 401, 403, 404, 413 and 422 will not improve on retry; 408, 409, 429, 5xx and 529 may.

Idempotency on process_refund. A refund may succeed even when its response is lost. Give every retry of the same intended refund the same idempotency key, and have a replay return the original result. Check the refund client’s retry policy separately from the anthropic client’s policy: the Messages API does not execute the refund. If the refund client also retries 409 responses, returning 409 for a successful replay creates unnecessary retries.

The gate. Escalation criteria live in the system prompt with few-shot examples — the hard limits live in code. can_use_tool receives the tool name and input and returns allow or deny. Its updated_input field can approve a modified call, and the rule for using it is narrow: normalize freely, never rewrite the money. Silently capping a $250 refund to $100 and allowing it executes a transaction nobody authorized and logs it as an approval. Deny instead, with a message that says what would be allowed, and let a human approve the real number. Remember that bypassPermissions skips the callback entirely; if the gate is a compliance control rather than a convenience, put it in a PreToolUse hook.

async def gate(tool_name, tool_input, ctx):
    if tool_name == "process_refund" and tool_input["amount_cents"] > 10_000:
        return PermissionResultDeny(
            behavior="deny",
            message="Refunds over $100 require a human. Call escalate_to_human.",
        )
    return PermissionResultAllow(behavior="allow")

The escalation policy itself. Immediate on an explicit request for a person. Immediate on a policy gap, such as competitor price matching when the policy covers only own-site adjustments, even though the request is simple. On an inability to progress. Never on sentiment. Never on the model’s own confidence for a live case.

The record. One audit entry per decision: timestamp, session and agent id, model, prompt hash and version. Then the tool calls with their idempotency keys and outcomes, the decision, the gate rule that fired, the reviewer, and the usage numbers. A null reviewer is a valid and important value. Hash the prompt rather than storing it, and store the calibration version beside any confidence figure.

Recovery after a crash. Conversation recovery and transaction recovery need separate records. The SDK ships a SessionStore protocol and an in-memory implementation whose docstring marks it unsuitable for production; use durable storage for a service that must resume after restart. For processes the SDK does not own, export structured state and reload a manifest. Before replaying a refund whose outcome is unknown, reconcile it against the payment system using its idempotency key.

Test the design with a duplicate refund request, a tool denial and a crash after the payment service accepts a refund. Inspect both the customer-visible response and the stored outcome. A completed conversation alone does not show that the refund happened exactly once.

The other five, condensed

Scenario 2: Code Generation with Claude Code

Claude Code in a dev workflow: generation, refactoring, debugging, with slash commands, CLAUDE.md, and plan mode. Domains 3, 5.

• Plan mode versus direct execution: plan a multi-file refactor or an architectural change; execute a single-file bug fix directly. Combine them by planning the investigation and executing the approved plan.
• CLAUDE.md placement: team conventions go in the project file, not user-level, which is the teammate-not-getting-instructions trap. Path-specific rules cover file-type conventions that span directories.
• Commands versus skills: the distinction is structural, not who pulls the trigger. A command is one Markdown file; a skill is a directory with progressive disclosure, so its metadata stays in context and its body and scripts/ load only when it fires. Both are invocable both ways by default, and invocation is set separately by two booleans — disable-model-invocation (default false) makes a /deploy user-only, user-invocable (default true) hides one from the slash menu. Use context: fork to isolate a verbose skill in a subagent.
• Refinement: concrete examples and failing tests beat more adjectives, and the Explore subagent keeps discovery from eating context.

Scenario 3: Multi-Agent Research System

A coordinator delegating to search, analyze, synthesize, and report subagents, producing cited reports. Domains 1, 2, 5.

• Decomposition must be complete and disjoint: partition the topic so coverage has no gaps and no duplication. Trap: decomposition so narrow it leaves gaps.
• Context isolation: subagents inherit no conversation history, so the coordinator passes each its scope explicitly. Summarize the current phase before spawning the next, so each wave starts from conclusions rather than raw discovery.
• Error propagation: a failed search subagent returns structured error context with what it tried and any partial results, and synthesis carries coverage annotations. Traps: suppressing the error as an empty result, or killing the whole workflow on one failure.
• Provenance: claim-source mappings survive synthesis. Where a subagent supplied its own documents, enable citations and get spans back that you can verify against the source. Conflicting statistics are annotated with attribution, not arbitrarily resolved, and dates prevent temporal differences from reading as contradictions.

Scenario 4: Developer Productivity with Claude

An agent exploring unfamiliar codebases with the built-in tools plus MCP servers. Domains 2, 3, 1.

• Built-in tool selection: Grep for content, Glob for file patterns, Read to follow imports. When Edit reports a non-unique anchor, the remediation order is fixed: widen the anchor first, reach for replace_all when the change really is a rename across the file, and fall back to a whole-file rewrite almost never — and when you do, only after reading the file and diffing the result. Build understanding incrementally: grep the entry points, then read to trace, rather than reading everything upfront.
• Context degradation: scratchpad files persist findings, subagents isolate verbose discovery, phase summaries carry conclusions forward, and /compact reclaims context. Steer automatic compaction with PreCompact custom instructions so it does not summarize away the specific classes you found.
• Crash recovery: a long exploration should survive a restart. Export structured state, reload a manifest, resume.
• MCP integration: project-scoped .mcp.json with env-var secrets, and enhanced tool descriptions so the agent prefers a capable MCP tool over built-in Grep. Remember that every tool definition is context on every turn.

Scenario 5: Claude Code for CI/CD

Claude Code in a pipeline running automated reviews and test generation, minimizing false positives. Domains 3, 4.

• Non-interactive execution: -p to prevent hangs, and --output-format json with --json-schema for parseable findings to post as PR comments.
• Precision: explicit categorical criteria beat “be conservative”, as in “flag a comment only when it contradicts the code.” Disable a high-false-positive category to protect trust in the accurate ones, and use few-shot examples to fix the finding format.
• Independent review, and multiple passes: the review runs in a fresh instance, not the session that generated the code. Large changes get a per-file pass and a separate cross-file integration pass, because one diluted pass produces inconsistent findings and misses interface breaks.
• No duplicate work: include prior findings on re-runs, provide existing tests so generation does not duplicate coverage, and keep the review criteria in CLAUDE.md.

Scenario 6: Structured Data Extraction

Extracting from unstructured documents, validating against JSON schemas, handling edge cases. Domains 4, 5.

• Guaranteed shape: tool_use with a JSON schema, forced via tool_choice (or "any" when the document type is unknown). Trap: believing a strict schema validates correctness. It fixes syntax, not semantics.
• Schema design against fabrication: optional and nullable fields so the model returns null instead of inventing a required value, and "unclear" or "other" plus a detail field for edge cases.
• Validation loops: retry with specific error feedback, and extract calculated_total alongside stated_total to catch discrepancies. Trap: retrying when the information is simply absent from the source. Recognize it and stop.
• Scale and trust: the Batches API for overnight volume, with submissions paced against your SLA, and only failed items resubmitted by custom_id. State the limitation precisely, because the loose version of it is a distractor in its own right: a batch item accepts tool definitions and can return a tool_use block; what it cannot do is execute that tool and continue the turn. Forced-tool extraction over a batch is a good design. A multi-turn tool-using agent over a batch is the trap, because nothing sits between the model and the tool to run it. Validate by document type and field, size your samples deliberately, and route review by calibrated confidence.

The pattern behind the patterns

The scenarios reuse several controls, with different consequences when a control is missing:

• Structure over heuristics. Loop on stop_reason, not on parsed text. Escalate on policy coverage, not sentiment. Enforce with hooks and gates, not prompts.
• Be honest about uncertainty. Annotate coverage gaps and source conflicts, return null over a fabricated value, surface ambiguity instead of guessing.
• Isolate to stay reliable. Independent reviewers, forked skill contexts, subagent-scoped exploration, case facts kept outside the summary.
• Scope tightly. Few well-described tools, criteria over adjectives, decomposition that is complete and disjoint.
• Assume it will be retried. At-least-once is the default everywhere, so state-changing tools are idempotent and duplicate work is identified rather than repeated.

Those five instincts will get you to the right answer more often than any fact, but they are instincts, not rules. Return to the stem’s constraints before trusting them, because a human gate, another retry or a larger context window can each be appropriate. The decision depends on what failed, which policy applies and what must remain true when the workflow resumes.

Twenty-seven more, weighted to the blueprint

Six items dissected at length teach the anatomy. What they cannot give you is coverage. The exam draws sixty items across five weighted domains, so here are twenty-seven more, taking the chapter to thirty-three.

This is a teaching set, not a simulated exam. Each of the thirty-three items accounts for about three percentage points of the bank, so the domain shares only approximate the blueprint. Domains 2 and 3 are underrepresented; Domain 5 is overrepresented:

Domain	Items	Share	Blueprint
1 · Agentic Architecture & Orchestration	9	27%	27%
2 · Tool Design & MCP	4	12%	18%
3 · Claude Code Configuration	5	15%	20%
4 · Prompt Engineering & Structured Output	7	21%	20%
5 · Context Management & Reliability	8	24%	15%

Domain 5 has extra items to cover its six task statements, including context preservation, failure handling and provenance. Four tool-design items provide limited coverage of Domain 2. Review those chapters even if you answer all four correctly.

So do not convert a score here into a predicted exam score. Use it to find the domain you are weakest in, then go back to that domain’s chapters. Each item below says how many answers to select, the way the exam does. Read the dissections even for the items you get right, because the reason a distractor fails is the part that transfers.

Working the bank under exam conditions

Work the bank once without reading the explanations, then use it for review. Keep a record of your answer, the deciding constraint and any uncertainty.

One sitting, at the exam’s pace. Allow roughly two minutes per item, or about an hour for the bank. Flag a difficult item and return to it after answering the rest.

Cluster by scenario. Every item names its scenario in the line under the title, so group them before you start. Read a scenario’s premise once and carefully, then answer its cluster quickly. That is the shape of the real exam, and it is where the two-minute average comes from — the reading is amortized across a cluster and the answering is not, so an item read cold costs far more than its share.

Answers closed until the block is done. Write your letters down and keep going. Then read every dissection, including the ones you got right, because a correct answer for the wrong reason fails the next stem that words it differently.

Then score by domain against the table above rather than by total, and be careful what you take from the number. Thirty-three items is half an exam, so what you have measured is your pace and your recall, not a score. A domain where you were slow is worth as much attention as one where you were wrong.

Item 7 — Auto-approval is not availability

Domain 1. Scenario 4.

A headless agent is meant to be read-only. It was configured with allowed_tools=["Read", "Grep"] and nothing else, and it modified a file anyway. Which two statements describe the configuration correctly? (Select two.)

A. allowed_tools suppresses the permission prompt for the tools it names. It does not remove any tool. B. Restricting what the agent has is tools; removing a tool from the model’s context is disallowed_tools. C. Leaving a tool out of allowed_tools makes it unavailable to the model. D. disallowed_tools rejects a call at execution time while leaving the tool’s definition in context. E. Naming a tool in allowed_tools makes it available even when tools never offered it.

Correct: A and B. Three levers, three jobs: tools is availability, allowed_tools is auto-approval, disallowed_tools is removal — and only the first and third prevent anything.

Why C is the reading the name invites. Omission does not remove a tool. It makes the call prompt — and in a headless run with nobody to answer, the symptom is a stall or a refusal that looks exactly like a missing tool. Why D understates the strongest lever. A disallowed tool is absent from context entirely, so no tokens are spent describing a capability you intend to refuse. Why E inverts the layering. Auto-approval cannot add a tool to a roster tools never put it on.

Item 8 — What a subagent can see

Domain 1. Scenario 3.

A coordinator spends a search phase identifying three vendors, then dispatches an analysis subagent. The subagent reports that it cannot find the vendors it was asked about. What is the correct fix? (Select one.)

A. Raise the subagent’s maxTurns so it has room to rediscover them. B. Pass the vendor names explicitly in the invocation, because a subagent inherits none of the coordinator’s conversation history. C. Move to a mesh topology so subagents can query each other directly. D. Set model="inherit" so the subagent shares the coordinator’s state.

Correct: B. A spawned subagent starts with its own system prompt, the project CLAUDE.md, and its own tools. Nothing else. It cannot see what the coordinator discussed, what a sibling found, or even the user’s original wording — not unless the coordinator passes that context into the invocation.

Why A treats a visibility problem as a budget problem. No number of turns shows a subagent a conversation it was never given. Why C is the expensive answer. A mesh multiplies the interaction paths and makes failures hard to trace, and it answers a passing problem with a topology change. Isolation is the feature here — not the bug. Why D is a category error. inherit on model means “use whatever the parent is using.” It is a cost and capability decision, and it carries no conversation.

Item 9 — Decomposition that leaves holes

Domain 1. Scenario 3.

A research coordinator runs search, analyze, synthesize, and report for every request, including one-line factual questions. Its four search subagents were given topics, two of which cover the same ground. Which two criticisms are correct? (Select two.)

A. A fixed pipeline throws away the coordinator’s judgment about which subagents a request actually needs. B. The overlapping topics break disjointness, so the same ground is researched twice and the report inherits duplicate findings. C. The pipeline should be replaced with a mesh so the agents can negotiate their own scopes. D. Four subagents is too many; a coordinator should not dispatch more than three. E. The overlap is harmless, because the synthesis agent will deduplicate it.

Correct: A and B. Good decomposition is complete and disjoint: every part of the task covered by exactly one subagent, no gaps and no duplication. And a coordinator that always runs the full sequence has thrown away its own judgment — the pre-configured pipeline anti-pattern, wearing a multi-agent costume.

Why C swaps a fixable problem for an unfixable one. The decomposition is wrong, and that is a coordinator prompt away from being right. A mesh is the least debuggable topology on the list. Why D invents a number. The test is coverage and disjointness — never a headcount. Why E defers an upstream defect downstream. Deduplication at synthesis still pays for the duplicated research in turns and budget, and it cannot recover the topic nobody was assigned.

Item 10 — The gate is only as wide as its matcher

Domain 1. Scenario 2.

A PreToolUse hook with the matcher "Write" returns a deny decision, and the run uses bypassPermissions. The hook fired, the Write was denied and recorded in permission_denials, and the file exists anyway. What happened? (Select one.)

A. bypassPermissions overrode the hook’s decision. B. A hook gates only the tools its matcher matches, and the file was written with Bash, which the matcher never saw. C. PreToolUse cannot deny under bypassPermissions, so the permission callback should be used instead. D. The denial was recorded, but hook decisions are advisory rather than binding.

Correct: B. Widen the question from was this tool blocked to was this outcome prevented — and the design changes. If what you must prevent is “a file gets written,” enumerate every tool that can write a file, or invert it and let tools decide what is on the table at all.

Why A and C both contradict the observed run. The deny held in both modes and was counted. Why C also points at the weaker mechanism. bypassPermissions is precisely what skips the permission callback, which is why the SDK’s own advice is to use a PreToolUse hook when you need every call gated. Why D inverts which half is soft. The hook is the guarantee. The matcher is the hole.

Item 11 — A redaction hook that redacts nothing

Domain 1. Scenario 1.

A PostToolUse hook strips card numbers from tool results by returning updatedToolOutput. In production, unredacted numbers still reach the model, and failed tool calls produce no log line at all. Which two explain it? (Select two.)

A. An updatedToolOutput shape the SDK does not recognize is discarded in silence, and the original output reaches the model. B. PostToolUseFailure is a separate event that fires instead of PostToolUse, so a hook attached only to the success event never sees a failure. C. updatedToolOutput applies only to MCP tools; built-in tools need updatedMCPToolOutput. D. A PostToolUse hook cannot modify output at all, so redaction belongs in PreToolUse. E. Dropped edits are reported in permission_denials.

Correct: A and B. Verify the content that reaches the model after the hook runs, and attach logging to both success and failure events. A callback executing is insufficient evidence that its returned edit took effect.

Why C has the sibling backwards. updatedMCPToolOutput is the MCP-only field. updatedToolOutput is the one the SDK tells you to prefer, and it works for both. Why D forecloses a real capability. PostToolUse can rewrite output, and PreToolUse runs before the output exists. Why E borrows a field from another surface. permission_denials lives on a CLI result object and names refused tool calls — not dropped edits.

Item 12 — A failure marshalled as a success

Domain 2. Scenario 1.

An MCP tool handler returns {"isError": True, "content": [...]} when a refund is declined. The agent reads it as a normal return value and tells the customer the refund went through. Why? (Select one.)

A. A declined refund must be raised as an exception rather than returned. B. The handler must return is_error. The camelCase key is ignored, and the result goes out as isError=False. C. The error needs structuredContent before the SDK will recognize it. D. isError is correct, but it must be paired with an errorCategory field.

Correct: B. Camel case is the wire; snake case is your Python. You write is_error in an SDK handler and in a raw tool_result block, and you only see isError when reading a serialized MCP message.

Why A inverts the loop’s contract. A failing tool re-enters the loop as content — it does not escape as an exception. Why C reaches for a field the wrapper never reads. A handler that returns structuredContent has it dropped on the floor, which is why structured errors are serialized as JSON in a text block today. Why D applies a real rule at the wrong layer. Category, retryable flag and message belong in the payload, and none of them rescue a key the wrapper never looked at.

Item 13 — The tool that keeps getting the wrong call

Domain 2. Scenario 1.

lookup_order is being called with customer email addresses, and when it returns nothing the agent retries it four times. Which single change addresses both symptoms? (Select one.)

A. Add a retry limit around the tool. B. Rewrite the description with the exact input format, an example ID, the boundary against search_orders, and the fact that an unknown ID returns a valid empty result rather than an error. C. Merge lookup_order and search_orders into one tool that accepts either input. D. Raise max_turns so the agent has room to recover on its own.

Correct: B. Both symptoms are description failures. The model cannot tell two neighbouring tools apart, and it cannot tell an empty result from a broken tool — and the description is the only thing it sees.

Why A treats the louder half and leaves the misroute. The retries stop; the wrong tool is still being called with the wrong input. Why C deletes the boundary instead of describing it. One tool with two jobs has to disambiguate them at call time, which is the problem you started with. Why D funds the loop that should not be running.

Item 14 — The optional parameter that isn’t

Domain 2. Scenario 6.

A tool is declared with the short dict-of-types schema. Its currency parameter is meant to default when the document does not state one, and the model supplies a currency on every call. What is happening? (Select one.)

A. The model is fabricating. Add “leave currency blank if unknown” to the description. B. The dict form lists every key in required, so it cannot express an optional parameter. Write the full JSON Schema. C. additionalProperties has to be set to true. D. The parameter needs a default declared in the tool’s annotations.

Correct: B. The moment a tool has a parameter with a sensible default, the short form is wrong — and nothing warns you. The compiler is silent, and the symptom is a model dutifully inventing a value for a field you meant to be optional.

Why A is a prompt patch for a schema fact. The model is doing exactly what a required field asks of it. Why C moves in the wrong direction. additionalProperties governs unexpected keys, not the required list. Why D misreads what annotations carry. They describe the part of the interface that is not prose, and their defaults assume the worst until you say otherwise. They do not make a required field optional.

Item 15 — A server nobody else has

Domain 2. Scenario 4.

You wired an MCP server in with claude mcp add. A teammate who cloned the repository does not have it, and the configuration holds an API key in plain text. Which two changes fix this? (Select two.)

A. The default scope is local, so re-add with --scope project to write a .mcp.json into the repository. B. Reference the key through ${VAR} expansion so the secret stays out of the committed file. C. The default scope is user, so the server is already shared and the teammate only needs to restart. D. Once .mcp.json is committed, the server connects automatically on checkout, so nothing further is needed. E. List the key in disallowed_tools so no tool can read it.

Correct: A and B. The default local scope belongs to this user’s checkout. Project scope puts the shared configuration in .mcp.json, while environment-variable expansion keeps the key out of that file.

Why C gets the default wrong in the most common way. local is what you get by typing the command without thinking. Why D is wrong in the safe direction. A project-scoped server someone else committed shows as pending approval and is not connected to until you accept it. Checking out a repository does not silently run its servers — the presence of the file is not the connection. Why E confuses two different controls. disallowed_tools shapes the tool roster and has nothing to say about a secret.

Item 16 — Conventions the team never sees

Domain 3. Scenario 2.

You documented the team’s testing conventions in ~/.claude/CLAUDE.md. A teammate’s Claude Code ignores them. You also assumed packages/api/CLAUDE.md replaced the root file. Which two statements are correct? (Select two.)

A. User-level memory never reaches a teammate; shared conventions belong in the committed project CLAUDE.md. B. Every file in scope is concatenated rather than overridden, and longest-matching path resolves a conflict between two loaded instructions. C. A subdirectory CLAUDE.md shadows the root file out of context. D. CLAUDE.local.md is the right home for conventions the whole team must follow. E. Managed memory is the level an individual developer can opt out of per project.

Correct: A and B. Put each instruction at the level where exactly the right people and files see it — and nowhere else.

Why C is the intuition every other configuration system trains. Longest match settles a conflict between two instructions that are both in front of the model. It does not delete the shallower file out of context. Why D picks the private file. CLAUDE.local.md is gitignored, and its own description calls it your notes about this repo. Why E inverts the point of managed memory. It is the one level a developer cannot edit or opt out of, which is why it exists.

Item 17 — Plan first, or just do it

Domain 3. Scenario 2.

The task is renaming a widely used interface across 40 files and updating every caller. A teammate proposes running it directly, since Claude Code can edit files. What is the right approach? (Select one.)

A. Plan the investigation, review the plan, then execute the approved plan directly. B. Execute directly. Plan mode is a sandbox that blocks writes, so it would prevent the refactor. C. Execute directly and rely on --permission-mode dontAsk to catch mistakes. D. Plan it and stay in plan mode, because leaving through ExitPlanMode discards the plan.

Correct: A. Plan mode buys safe exploration before a costly, multi-file, or architectural change. A single-file bug fix does not need it — a 40-file rename does.

Why B states the common misreading. Plan mode is a workflow control, not a sandbox, and its boundary has needed real fixes. It is not what stands between you and a bad write. Why C answers a design question with a permission posture. dontAsk auto-denies whatever would have prompted — it reviews nothing. Why D reverses the mechanism. ExitPlanMode is the tool you leave through, carrying the approved plan into execution.

Item 18 — A command, or a skill

Domain 3. Scenario 2.

You want a verbose repository-wide audit that Claude should apply on its own, and a /deploy that must never fire unless a human types it. Which two are correct? (Select two.)

A. The audit is a skill: a directory whose metadata stays in context and whose body loads on trigger, with context: fork isolating the verbose work in a subagent. B. /deploy is a command, and disable-model-invocation: true makes it user-only. C. Commands are user-invocable only and skills are model-invocable only, so the split happens automatically. D. argument-hint will stop /deploy from running when the environment argument is missing. E. Putting the audit in CLAUDE.md is equivalent, since both end up in context.

Correct: A and B. The real distinction is structural — a command is one file, a skill is a directory with progressive disclosure. Who pulls the trigger is set separately, by two booleans.

Why C is the folklore. Both artifacts are invocable both ways by default. Commands are model-invocable unless you say otherwise, and skills are user-invocable unless you say otherwise. Why D expects a passive string to act. argument-hint is placeholder text in the slash menu. It gates nothing, so validate the argument in the prompt body. Why E collapses the point of a skill. CLAUDE.md is context you pay for on every turn, while a skill’s scripts/, references/ and assets/ load only when needed.

Item 19 — The pipeline that went green and did nothing

Domain 3. Scenario 5.

A claude -p review step exits 0, reports subtype: "success" and is_error: false, and posted no findings at all. What is the likely cause, and what should the pipeline assert on? (Select one.)

A. The reviewer found nothing. Assert on a minimum finding count instead. B. -p grants no permission, so calls that would have prompted were denied and recorded. Gate on is_error === false and an empty permission_denials, and set the posture with --permission-mode dontAsk plus an explicit --allowedTools list. C. Exit codes are unreliable in CI. Re-run with more verbose logging. D. --output-format json suppresses findings. Drop it.

Correct: B. -p prevents the hang — it grants nothing. A run denied every tool it attempted still exits 0, and that is strictly worse than the hang the flag was added to prevent, because a hang is loud.

Why A is the reading that reaches production. A clean review and a review that could not run look identical from the exit code — one of them is a lie. Why C is right about the exit code and wrong about the remedy. The evidence is already in the result object; more logging is not needed to read a field. Why D removes the machine-readable output the pipeline depends on and does not touch permission at all.

Item 20 — The conventions that vanished

Domain 3. Scenario 5.

After the pipeline was switched to --bare for a faster, more hermetic run, the automated review stopped following the project’s documented conventions. Nothing in the output said so. What happened? (Select one.)

A. --bare skips CLAUDE.md auto-discovery. Supply the conventions explicitly with --append-system-prompt, --add-dir, or --settings. B. --bare lowers the model’s reasoning effort, so raise it. C. CLAUDE.md only applies to interactive sessions and never reached CI in the first place. D. The conventions need to move to user-level memory to survive --bare.

Correct: A. Under --bare, context stops being discovered and becomes explicit. The mode also skips hooks, plugin sync, auto-memory and keychain reads, and narrows authentication to an API key or an apiKeyHelper.

Why B invents a knob. --bare is about what gets loaded, not how hard the model thinks. Why C is false in the way that matters. CLAUDE.md does carry into a CI-invoked run, right up until somebody adds --bare for good reasons and loses it silently. Why D moves the file to the level that reaches nobody, and discovery is skipped regardless of level.

Item 21 — A forced tool call that returns nothing

Domain 4. Scenario 6.

A forced extraction names the tool in tool_choice and sets strict: True. On the longest invoices it returns an empty input object, or an object with one field filled in. What is the correct diagnosis? (Select one.)

A. strict: True guarantees a complete object, so the schema must be wrong. B. stop_reason is max_tokens. The cap truncates the tool input like any other output, so gate on stop_reason before reading, then raise max_tokens or chunk the document. C. Set temperature=0 so the model stops padding its answer. D. Add minimum and pattern keywords so the server rejects a partial value.

Correct: B. Forcing the call does not extend the budget the call is written into — the cap applies to JSON exactly as it applies to prose. Two other holes sit beside it: refusal and model_context_window_exceeded return no structured block at all.

Why A reads a shape guarantee as a completion guarantee. The schema says what a finished object looks like. It has nothing to say about generation stopping halfway. Why C aims a sampling knob at a length ceiling. Why D reaches for keywords that are not enforcement. A numeric range, a regex, a string length and an array size are asked for in prose, not checked.

Item 22 — What a schema actually promises

Domain 4. Scenario 6.

An extraction team wants a confidence field constrained to the range 0 to 1, and proposes putting minimum and maximum in the schema and deleting the post-hoc check. Which two statements are correct? (Select two.)

A. The first-class routes are output_config with a JSON schema and messages.parse with a Pydantic model, and parse also validates the reply client-side and raises an error naming the field. B. Under parse, the SDK’s transform demotes minimum and maximum to a hint in the description, so a range check belongs in your validator. C. A schema guarantees correctness as well as shape, so the post-hoc check is redundant. D. Forced tool_choice is the only mechanism that guarantees a shape. E. additionalProperties must be true before optional fields will validate.

Correct: A and B. What you actually get is a type-and-membership guarantee: the right fields exist, they hold the right types, and enum values come from your list. Hand-write output_config and the schema reaches the server as you wrote it, so the enforcement surface there is the server’s rather than the transform’s — which is a reason to know which route you are on, not a reason to skip the validator.

Why C is the schema trap at full strength. A well-formed tax_id belonging to a different company passes every check you have. That is exactly why extraction pulls calculated_total alongside stated_total. Why D promotes a good mechanism to the only one. Forced tool_choice is right when the extraction lives inside a tool loop. Why E inverts a setting the transform forces to false.

Item 23 — The cache that never fired

Domain 4. Scenario 5.

A review rubric of roughly 3,000 tokens sits in the system turn with cache_control set. Costs did not fall, and cache_creation_input_tokens and cache_read_input_tokens are both zero on every call. What is going on? (Select one.)

A. The breakpoint is in the wrong turn and should move to the last user message. B. The prefix is below the model’s minimum cacheable length, measured at 4,096 tokens on the model used here, so the breakpoint is ignored. Both counters staying at zero is the only signal you get. C. Caching requires temperature to be 0. D. The cache expired between calls, so the calls need to come closer together.

Correct: B. The threshold is per-model, so check it for whichever model you deploy. What generalizes is the failure mode — there is no error, no warning, and no field that says the cache_control did nothing.

Why A moves a correctly placed breakpoint. The layout you want is stable material first and volatile material last, and a rubric is the stable half. Why C invents a dependency. Why D is the story a reader tells themselves, and the numbers rule it out. An expiry shows a write and then no read — this shows no write at all.

Item 24 — Retries, and the refund paid twice

Domain 5. Scenario 1.

A support agent wraps each Messages API request in a “retry three times” loop, on top of the anthropic client’s defaults. Separately, its refund tool uses an HTTP client configured with the same retryable status codes. A customer was refunded $47.50 twice, and the refund endpoint answers a replayed idempotency key with a 409. Which two statements are correct? (Select two.)

A. The anthropic client already retries twice, so a three-attempt wrapper is really a nine-attempt policy. B. A replay must return the original result, because 409 is on the SDK’s retry list and an idempotency check that answers with one turns into a loop. C. 409 is fatal, so the client will not retry it and the wrapper is harmless. D. The idempotency key should be random per attempt, so a replay is never mistaken for a new refund. E. Setting max_retries=0 removes the need for idempotency.

Correct: A and B. The wrapper can multiply a retryable Messages API failure into nine attempts. The refund client has its own retry policy, which the stem defines as the same retryable status list the SDK uses, so option B’s point about 409 applies at the refund boundary; the anthropic client itself does not execute refunds. The duplicate-payment fix belongs at the refund boundary: reuse one operation id per authorized refund and replay the stored result without moving money again.

Why C has the taxonomy backwards. 409 sits with 408, 429, 5xx and 529 as may improve on a retry, since a lock contention should clear. That is precisely what makes answering a replay with one so damaging. Why D defeats the mechanism it names. The key is derived from the intent, so every retry of the same refund carries the same key. A fresh key per attempt is how you get the second refund. Why E confuses the layers. At-least-once arrives from the network and from your own recovery logic, not only from the client’s retry count.

Item 25 — The block that could not check itself

Domain 5. Scenario 1.

A support agent keeps a case-facts block outside the summarized history and re-injects it in every prompt. Two failures recur anyway. After an automatic compaction, findings the agent derived mid-conversation vanish, including a shipping exception it had confirmed with a second tool call. And the agent has twice told a customer the return window is still open, reading a block whose temporal lines are status: delivered 2026-06-01 and policy: 30-day returns; delivered 45 days ago -> outside window. Which two changes address these? (Select two.)

A. Write the as-of date into the block. A time-sensitive fact set that omits its own as-of date is not self-contained, and “45 days ago” is checkable only against a reference the block does not carry. B. Attach custom_instructions to a PreCompact hook naming what compaction must preserve, since compaction accepts instructions about what to keep. C. Move the case-facts block above the cache breakpoint, so the prefix stops changing and the facts stop being recompacted. D. Switch to a model with a larger context window, so automatic compaction never fires. E. Tell the model in the system prompt not to forget findings it has confirmed.

Correct: A and B. The block is the layer summarization cannot touch, and PreCompact is how you extend that protection to facts the block does not yet hold. Both fixes are about where a fact lives, which is the whole of this task statement.

Why C is the right rule in the wrong situation. Stable material belongs above a breakpoint and volatile material below it, and the case-facts block changes every time a tool discovers something. Promote it and you invalidate the cache on every turn, pay full price forever, and get no error. Compaction never read the block in the first place. Why D answers a preservation problem with capacity. A bigger window delays compaction rather than steering it, and the findings are still what a summary drops first. Why E is a prompt patch where a mechanism exists. A sentence asking the model to remember is not a gate, and it is competing with the compaction step itself.

Note which loss is which. The vanished shipping exception is summarization loss, and the misread window is a self-containment failure. Two symptoms, two different fixes — an item that gave you only one symptom would have only one key.

Item 26 — Three candidate orders and an angry customer

Domain 5. Scenario 1.

A customer writes: “I’ve been charged twice and I need this sorted today. This is unacceptable.” search_orders returns three orders for that customer in the relevant week, any of which could carry the duplicate charge. The agent’s own confidence in its identification of the right one reads 0.62, against no calibration. Nothing in the message asks for a person. What should the agent do? (Select one.)

A. Escalate, given the hostile tone and a self-reported confidence below the 0.7 threshold. B. Ask for a disambiguating identifier — the order number, the charge date, or the last four digits — then resolve. Escalate only on an explicit request for a human, a policy gap, or an inability to progress. C. Refund the most likely of the three and record the choice in the audit log. D. Escalate, because a human resolves a three-way ambiguity faster than a clarifying round trip.

Correct: B. A search returning three matches is a success, not an error. The right response to ambiguity is to ask the one person who can settle it in a single turn.

Why A stacks two forbidden triggers. “Unacceptable” is a complaint, not a demand for a human, and sentiment is an unreliable proxy for complexity. The confidence figure is worse. Uncalibrated self-reported confidence is noise, and even a calibrated score is a population property: knowing that 0.62 means 62% across ten thousand cases tells you how to allocate reviewer hours and nothing about this caller. It is never an escalation trigger for a live case. Why C guesses where it should ask. Logging a guess documents it; it does not license it, and a wrong pick here is a refund on the wrong order. Why D takes the right instinct one step too far. An inability to progress means the agent has no path forward. It has one, and it costs a question.

Item 27 — One stage failed, and what that means depends

Domain 5. Scenario 3.

A pipeline runs extract, then enrich, then compliance screening, then publish. The enrich stage calls an external vendor that times out after three attempts, having already enriched two thirds of the records. Publication policy marks enrichment optional and permits a report with annotated gaps; it marks compliance screening required. Which two statements describe correct propagation? (Select two.)

A. Enrich returns a structured error carrying the failure type, what it attempted, its partial results and the alternatives available; the pipeline continues and the report ships with an annotated coverage gap. B. A required stage that cannot complete fails closed. Compliance screening blocks publication rather than proceeding with an annotation. C. Enrich should raise an exception that terminates the pipeline, because a partly enriched report is an incomplete report. D. Enrich should return an empty result, so the downstream stages need no special handling. E. Compliance screening should annotate its own failure and publish too, so a reviewer can see the gap and decide.

Correct: A and B. Whether a gap may be published is a policy input, not a universal, and the stem states the policy for both stages precisely so you can tell them apart.

Why C destroys the work of three healthy stages. The answer to incompleteness in an optional stage is to annotate it, and the two thirds already enriched are real output. Why D is the most dangerous option on the page. An empty result is silent suppression: downstream cannot distinguish “nothing to enrich” from “vendor unreachable,” so an absence of evidence gets published as evidence of absence. Why E is the same rule as A, applied where it does not hold. A report 90% complete against a mandatory control is not 90% right. It is unfit, and annotating it makes it a document that looks checked.

One pre-condition is worth naming because it flips a different item. Enrichment here is a read, so a timeout is simply a failure and a retry is free. Had the stage changed state, that timeout would be a third outcome — neither success nor failure but unknown — and the move is to reconcile against the operation’s own status before replaying, not to retry.

Item 28 — Forty files, read front to back

Domain 5. Scenario 4.

An agent is tracing the payment path through an unfamiliar service. Its first move is to Read every file under src/payments/: forty files averaging 600 lines. Each subsequent lookup returns a 40-field record of which four fields matter, and all forty fields land in context. Two hours in, the answers have gone generic. Which two changes address the cause? (Select two.)

A. Discover incrementally: Grep the entry points, Glob for the file patterns, and Read only to follow the imports the grep turned up. B. Trim each tool result to the fields the task needs before it enters context, writing the raw response somewhere durable and carrying a hash reference in the projection. C. Trim the stored responses to the same four fields, so the record matches what the model actually saw. D. Raise max_tokens, so each answer has room to be specific. E. Summarize the forty files into one overview document and read that instead.

Correct: A and B. Both symptoms are one cause: material entered context that never needed to be there, at two different scales.

Why C is the sharpest distractor here. It takes a correct rule one step past where it is correct. Trimming context is a display decision and reversible; trimming the record is not. The thirty-six fields you dropped are what an auditor asks about six months later, when a customer disputes the refund. Why D swaps an output knob for an input problem. max_tokens bounds what the model writes, not what it retains. Why E replaces bloat with imprecision. Summarization drops exactly what an exploration needs — the specific class names and call sites — and “typical patterns” instead of specifics is the symptom the stem already reports.

The option list leaves out the strongest counter, and a real design would not. Delegate the verbose discovery to a subagent: its exploration burns its context budget, which is a separate budget entirely rather than a smaller share of yours.

Item 29 — Every span checked out, and the report still lied

Domain 5. Scenario 3.

A coordinator merges findings from four search subagents into a report. Each subagent enabled citations against the documents it supplied, and every span was verified by slicing the source and matching cited_text. The published report still carries a revenue figure nobody can trace to a source, and a refund-policy quotation that is correctly quoted from a version superseded in June. Which two statements are correct? (Select two.)

A. Citations bind a claim to a span within a single request against documents you supplied. Carrying provenance across synthesis needs explicit claim-source mappings, validated structurally so that no published claim is orphaned. B. Span integrity, entailment, currency and source quality are four separately scored properties, and a verified span proves only the first — which is why a correctly quoted stale passage passes every check that was run. C. A verified span demonstrates the claim is supported, so the untraceable figure is a rendering defect rather than a provenance one. D. Instructing the synthesis agent in its prompt to preserve source mappings is sufficient, since the coordinator is the one agent that sees every finding. E. Where two sources conflict, synthesis should resolve it by taking the higher-quality source, so nothing untraceable reaches the report.

Correct: A and B. Collapse those four properties into one green tick labelled “cited” and you have built the most convincing kind of wrong answer: one with a footnote.

Why C reads pointer integrity as entailment. What a span check proves is that the quoted words really are at that offset in that document. That is a genuine and cheap guarantee, and it is the whole of what it buys. Why D asks nicely where it should enforce. Synthesis is the one place in the pipeline where losing provenance is invisible: the report reads beautifully either way, and nobody notices the two claims that arrived with nothing attached. Why E solves a different problem, and solves it wrongly. Conflicts are annotated with attribution rather than arbitrarily resolved, and they carry dates so a temporal difference is not mistaken for a contradiction. Picking a winner also does nothing for a claim that had no source at all.

Item 30 — Fifty thousand at once, then the wrong answers

Domain 4. Scenario 6.

A nightly extraction submits 50,000 requests in a single client.messages.batches.create. The server rejects the call. On the re-run, split across two batches, results were stored against the wrong documents. Which two changes are correct? (Select two.)

A. Validate the request count and total payload size before create, and chunk large workloads by policy. A batch rejected at submission never started its 24-hour clock; it consumed part of the submission lag and produced nothing. B. Key results storage on (batch_id, custom_id), because custom_id uniqueness is scoped to the batch and a second batch may reuse the same id. C. create accepts an unbounded Iterable[Request], so the SDK chunks a large workload for you. D. Pair results() positionally against the submitted list, since a batch returns results in submission order. E. Move the whole workload to the synchronous API, since batch cannot carry 50,000 documents.

Correct: A and B. Both limits are invisible in the SDK types. Look them up on the day, the same category as pricing.

Why C is right about the type and wrong about what follows. The Iterable really is unbounded in Python, which is exactly the problem: the list builds happily and the rejection arrives from the server. Why D is the cause rather than the fix. Results may be returned out of request order, which is the entire reason custom_id is required. Positional pairing attaches every answer to the wrong document — with three tickets you would notice, and with fifty thousand invoices you would not. Why E is over-engineering in the expensive direction. A nightly, non-blocking, latency-tolerant workload is precisely what batch exists for. The defect is the shape of the submission, not the choice of API.

Item 31 — Forty reviewers, one contradictory fix

Domain 4. Scenario 5.

A CI review uses a multi-instance, multi-pass architecture: forty per-file passes plus one cross-file pass, each a fresh instance with no prior reasoning context. Two complaints come back. The merged report offers a remediation for one three-line hunk that contradicts itself, and the reviewers keep flagging a deliberately odd branch — written around a bug in a dependency — as a defect. Which two changes address them? (Select two.)

A. Union suggested fixes only within a root_cause cluster. Where two findings sit on the same lines with conflicting diagnoses, keep both and mark them conflicting. B. Give each fresh instance the rubric and the decision context: the requirements, and the rationale for the non-obvious choices. Independence removes the generator’s bias, and it removes everything the generator’s reasoning contained. C. Have the session that wrote the code review its own diff, since it knows why the branch is there. D. Take the highest severity across every finding on the same lines, regardless of cluster. E. Collapse the forty passes into one instance with a larger context window, so a single reviewer sees the whole change.

Correct: A and B. Multi-instance review buys independence and costs context. Both fixes here are about paying that cost deliberately rather than discovering it in the merged output.

Why C gives up independence to recover context. Supply the requirements and rationale to a fresh reviewer so it can assess the unusual branch without inheriting the generator’s full reasoning history. Why D flattens a signal you want. Highest severity is a sensible default within a group of genuine duplicates and a poor one across a disputed merge. Two passes disagreeing by more than one level is a finding about your rubric, so log it. Why E walks back into attention dilution, which is the failure the split exists to prevent. A larger window does not provide the focused per-file review or the explicit integration pass that this design needs.

Item 32 — The loop that would not stop, and the one that stopped early

Domain 1. Scenario 2.

A team builds an agentic loop directly on the Messages API. Two bugs reach production. The loop sometimes exits with the task half-finished, leaving a tool result unread, and it sometimes returns a truncated answer as though it were complete. Their loop continues while stop_reason == "tool_use" and returns otherwise. Which two changes address these? (Select two.)

A. Treat max_tokens as a truncation signal rather than a completion: the model stopped mid-sentence, so the turn needs continuing or failing, not returning. B. Handle pause_turn by sending the response back to continue the turn, since a paused turn is an interruption rather than an ending. C. Cap the loop with a turn counter, so a task that never reaches end_turn cannot run indefinitely. D. Switch to the Agent SDK, where ResultMessage.subtype reports termination and the loop is not yours to write. E. Raise max_tokens, so the model has room to reach end_turn on every turn.

Correct: A and B. Both bugs are one mistake: a two-way branch over a seven-member field. StopReason carries end_turn, tool_use, max_tokens, stop_sequence, pause_turn, refusal and model_context_window_exceeded, and an else that returns treats five of those as success. max_tokens handed a truncated answer to the caller. pause_turn ended a turn the model intended to continue.

Why C is good practice and not the fix here. A turn cap is a sound guard, and you should have one. Neither symptom is an infinite loop, though — a cap bounds damage without touching either cause. Why D changes tooling to avoid a bug. It is true that the SDK runs the loop and reports termination through ResultMessage.subtype, and for many teams that is the right choice. It is not a fix for a loop already built and still to be reasoned about, and the same team meets the same distinction the next time they read a stop_reason. Why E treats a symptom as a budget. More headroom makes truncation rarer without making it handled, and the failure it leaves is the quiet one: a plausible, incomplete answer returned as though it were whole.

The transferable rule: branch on the field, not on the one value you expected. Every value that is neither end_turn nor tool_use is asking a question, and a default branch answers all of them the same way.

Item 33 — Two experiments from one expensive setup

Domain 1. Scenario 3.

An agent spends roughly forty tool calls establishing context for a migration: reading the schema, mapping call sites, confirming which services are affected. The team now wants to try two migration strategies from that same established point, compare them, and keep the original context intact for a third attempt if both fail. Which two statements are correct? (Select two.)

A. Forking the session gives each attempt a new session id while carrying the accumulated context forward, so the original remains available. B. Resuming the original session continues it under the same session id, so two resumed attempts write into one history rather than two. C. Forking and resuming both produce a new session id, and the difference between them is only which messages are replayed. D. Re-running the forty setup calls per attempt is the only way to guarantee the attempts do not interfere. E. A subagent per strategy is equivalent, because a subagent inherits the parent’s conversation history.

Correct: A and B. This is the distinction the two functions exist to draw. A fork branches: new id, same recall, original untouched — which is exactly a compare-two-strategies experiment. A resume continues: same id, same recall, one timeline. Both were run against the pinned SDK, and the observable difference is the session id.

Why C collapses the two. If forking and resuming both minted a new id, resume could not do the one thing it is for, which is to pick a conversation back up as itself. Why D is expensive and still wrong. Forty setup calls repeated per attempt costs real money to reproduce a state fork reproduces exactly — and “exactly” is load-bearing, because a re-run may read a schema that has changed underneath it. Why E confuses two kinds of inheritance. A subagent inherits its own prompt, the project’s CLAUDE.md and its tool grant. It does not inherit the parent’s conversation history, so all forty calls would be invisible to it. That is the most consequential fact about subagents in this book, and it is why delegation and forking are not substitutes.

Note what makes this Domain 1 rather than context management. Nothing here is about fitting material into a window. It is about which control surface owns the branch.

Scoring, and what to reread

Use the domain table to choose what to reread. With so few items per domain, inspect each mistake and slow answer rather than treating a percentage as a reliable estimate of exam performance.

Domain	Items here	If you missed them
1 · Agentic Architecture & Orchestration (27%)	1, 3, 7, 8, 9, 10, 11, 32, 33	the agentic loop, multi-agent orchestration, workflows, hooks and sessions
2 · Tool Design & MCP Integration (18%)	12, 13, 14, 15	tool interfaces and errors, tool distribution and MCP
3 · Claude Code Configuration & Workflows (20%)	16, 17, 18, 19, 20	CLAUDE.md and rules, commands and skills, plan mode and CI/CD
4 · Prompt Engineering & Structured Output (20%)	2, 5, 21, 22, 23, 30, 31	precision and few-shot, structured output and validation, batch and review
5 · Context Management & Reliability (15%)	4, 6, 24, 25, 26, 27, 28, 29	context management, escalation and errors, review and provenance

For each missed or uncertain item, write down the deciding constraint and why the competing option fails. Revisit the linked chapter, then explain how changing that constraint would change your answer.

Final thoughts

What to carry forward.

• Across all six scenarios the winning instinct is the same: structure over heuristics, honesty over false certainty, isolation over entanglement, tight scope over catch-alls.
• Work items until you can name why each distractor fails. Recognising the right answer is easy once you can say what is wrong with the other four.
• Then build a real agent: five tools with descriptions that differentiate, structured errors with a retryable flag, a case-facts block below the cache breakpoint, an idempotency key on the one tool that moves money, a gate in code rather than in a prompt, and an audit record for every decision made without a human.

Choose one scenario and test the decisions you found hardest in the bank. For the support agent, that might mean confirming an order before refunding it, preserving the amount through compaction, denying a refund above the approval limit or recovering after a timeout. Record the expected action before running the case, then compare it with the tool trace and final outcome.

Return to the relevant chapter when the result differs. The useful endpoint is a design you can explain and inspect: which evidence authorized an action, which control enforced the limit, and what state lets the next attempt recover safely.

Back to the exam overview.