What this domain tests
15% — roughly 9 of 60 questions, the lightest domain by weight and the most misread by name. Candidates see "Context Management" and study context windows. The official objectives are much broader: only two of the six task statements are about context budget at all. The other four are reliability in the loop — when to escalate to a human, how errors travel between agents, how to design human review and calibrate confidence, and how source attribution survives a summarization pipeline.
Read that sentence twice. It is the highest-leverage thing on this page, because a candidate who studies token budgeting for this domain will miss more than half of it.
Four of the six published exam scenarios name this domain as primary — more than any other domain:
- Customer Support Resolution Agent — escalation triggers, ambiguity resolution, multi-issue case facts.
- Code Generation with Claude Code — long-session degradation, scratchpads, /compact.
- Multi-Agent Research System — error propagation, coverage annotations, claim-source mappings.
- Structured Data Extraction — confidence calibration and human review routing.
The question mix leans judgment more than the tool and loop domains do, but the judgments are rule-shaped: the guide states which escalation triggers are legitimate and which are unreliable proxies, so options that sound reasonable ("escalate when sentiment turns negative") are wrong on a stated rule, not on taste.
Theory outline
1. Preserving critical information across long interactions (Task 5.1)
Three named failure modes, each with its named repair.
Progressive summarization loses the facts that matter. Each round of condensing conversation history turns "refund of $247.80 on order 4471, requested March 3, customer expects it within 5 business days" into "customer wants a refund." Numerical values, percentages, dates, and customer-stated expectations are exactly what summarization strips, and exactly what the resolution depends on.
The repair is a separate context layer: extract transactional facts — amounts, dates, order numbers, statuses — into a persistent "case facts" block that is included in every prompt and lives outside summarized history. History gets compressed; facts do not. For multi-issue sessions, the same technique carries structured issue data (order IDs, amounts, statuses) per issue so issue two does not evaporate while issue one is being handled.
Lost in the middle. Models reliably process information at the beginning and end of long inputs but may omit findings from middle sections. This is a positional effect, not a comprehension failure, so the repair is positional:
| Technique | Why it works |
|---|---|
| Put a key-findings summary at the beginning of aggregated input | Puts the load-bearing material in a reliably-attended position |
| Organize details under explicit section headers | Gives the model structural anchors instead of an undifferentiated wall |
Tool results consume tokens disproportionately to their relevance. The guide's example: an order lookup returns 40+ fields when 5 are relevant to a return. Multiply by a dozen lookups and verbose tool output has crowded out the conversation. Trim tool outputs to the relevant fields before they accumulate — filtering at the boundary, not summarizing after the damage.
Two more skills that read like plumbing and are graded like design:
- Complete conversation history must be passed in subsequent API requests. Dropping earlier turns to save tokens breaks conversational coherence; trimming tool output is the correct economy, trimming history is not.
- Subagents must include metadata — dates, source locations, methodological context — in structured outputs so downstream synthesis is accurate. And when a downstream agent has a limited context budget, modify the upstream agent to return structured data (key facts, citations, relevance scores) instead of verbose content and reasoning chains. Fix the producer, not the consumer.
2. Escalation and ambiguity resolution (Task 5.2)
The guide states the legitimate triggers, which makes this a recall item wearing a judgment costume.
| Legitimate escalation trigger | Not a trigger |
|---|---|
| The customer explicitly asks for a human | Negative sentiment / frustration on its own |
| A policy exception or gap — policy is ambiguous or silent on this request | "The case seems complex" |
| The agent cannot make meaningful progress | The model's self-reported confidence score |
Sentiment-based escalation and self-reported confidence are called out as unreliable proxies for actual case complexity. An angry customer with a simple problem gets escalated; a calm customer with an unresolvable one does not. That inverts the intended routing.
Two behavioral rules that get tested against each other:
- Explicit request → escalate immediately, without first attempting investigation. Making the customer wait through a diagnostic they didn't ask for is the wrong answer even when the agent could have solved it.
- Frustration without a request → acknowledge the frustration and offer resolution if the issue is within the agent's capability, escalating only if the customer reiterates their preference for a human.
Policy gaps specifically. The guide's example: policy addresses price adjustments on your own site, and the customer asks for a competitor price match. Policy is silent, not restrictive. Silence is an escalation trigger — inventing a decision or refusing on the basis of an unwritten rule are both wrong.
Ambiguity in tool results. When a lookup returns multiple customer matches, the agent asks for an additional identifier. Heuristic selection — most recent, closest name match — is the named anti-pattern, and it is the one that quietly refunds the wrong person.
How you implement the criteria: explicit escalation criteria in the system prompt, with few-shot examples demonstrating when to escalate versus resolve autonomously. A bare list of rules underperforms rules plus worked cases.
3. Error propagation across multi-agent systems (Task 5.3)
A subagent's failure report is an input to the coordinator's recovery decision. Structure determines whether recovery is possible.
Structured error context carries four things:
| Element | What it buys the coordinator |
|---|---|
| Failure type | Whether this is retryable at all |
| What was attempted (the query) | Whether a rephrased or narrowed attempt is worth making |
| Partial results | Salvage — the run may still be usable |
| Alternative approaches | A concrete next move instead of a guess |
Three anti-patterns, stated:
- Generic error statuses ("search unavailable") hide the context the coordinator needed.
- Silently suppressing errors — returning empty results as success — means the gap never gets noticed and lands in the final report as an absence of evidence.
- Terminating the entire workflow on a single failure — one subagent's timeout should not kill a five-subagent research run.
Where recovery lives: subagents implement local recovery for transient failures and propagate only what they cannot resolve, including what was attempted and any partial results. This is the same rule Domain 2 states from the tool side; the exam can ask it from either direction.
Access failure versus valid empty result appears here again: a timed-out search needs a retry decision, a clean search with zero matches is a successful query. Reporting both as "nothing found" corrupts the coordinator's model of what it knows.
Coverage annotations close the loop: structure the synthesis output to indicate which findings are well-supported versus which topic areas have gaps due to unavailable sources. A report that reads as complete when a source was down is worse than one that says where it is thin.
4. Managing context in large codebase exploration (Task 5.4)
The degradation symptom is a named recall fact. In extended sessions, the model starts giving inconsistent answers and referencing "typical patterns" rather than the specific classes it discovered earlier. That drift from specific to generic is the diagnostic — when a stem describes it, the answer is a context-management technique, not a model change or a temperature adjustment.
Four techniques, each matched to a situation:
| Technique | Use when |
|---|---|
| Scratchpad files recording key findings, referenced for later questions | Findings must survive a context boundary within the same line of work |
| Subagent delegation for specific investigations ("find all test files", "trace refund flow dependencies") | Exploration output is verbose and the main agent should keep only high-level coordination |
| Phase summaries injected into initial context — summarize findings from one exploration phase before spawning subagents for the next | Work is staged and each stage's conclusions must seed the next |
| /compact | An extended session has filled with verbose discovery output and needs reducing in place |
Crash recovery has a specific published shape: each agent exports state to a known location, and on resume the coordinator loads a manifest and injects it into agent prompts. Not a checkpointed conversation, not a replay — structured state exports plus a manifest.
The through-line with Domain 1: subagent delegation is a context strategy as much as an orchestration one. Each subagent burns its own window on raw material and returns condensed findings, so the coordinator's window holds conclusions instead of file dumps.
5. Human review workflows and confidence calibration (Task 5.5)
The scenario behind this task statement is structured data extraction, and its central warning is about a number that looks like success.
Aggregate accuracy masks segment failure. A pipeline reporting 97% overall accuracy can be at 99% on invoices and 70% on handwritten receipts, or excellent on every field except tax IDs. Before reducing human review, analyze accuracy by document type and by field to verify consistent performance across all segments. An option that automates on the strength of an aggregate figure is wrong on a stated rule.
Stratified random sampling of high-confidence extractions is the ongoing control: it measures the real error rate inside the population you stopped reviewing and detects novel error patterns as document mixes drift. Sampling only the low-confidence bucket tells you nothing about the extractions you are trusting blindly.
Field-level confidence, calibrated. Have the model output field-level confidence scores, then calibrate review thresholds using a labeled validation set. Raw model confidence is not a probability until you have mapped scores to observed accuracy — this is why the guide says calibrated, and why an uncalibrated threshold ("review anything below 0.8") is an unearned number.
Routing rule: send to human review the extractions with low model confidence or ambiguous/contradictory source documents, so limited reviewer capacity goes where error is likely. The goal is not less review — it is review aimed at the right documents.
Note the contrast with Task 5.2, which is easy to trip over: self-reported confidence is an unreliable basis for escalating a support case, but field-level confidence calibrated against labeled data is the correct basis for routing an extraction to review. The difference is calibration and the narrowness of the judgment.
6. Provenance and uncertainty in multi-source synthesis (Task 5.6)
Attribution dies during summarization. When findings are compressed without preserving claim-source mappings, the final report states facts it can no longer cite. The repair is upstream: require subagents to output structured claim-source mappings — source URLs, document names, relevant excerpts — that downstream agents preserve and merge through synthesis. Adding citations at the end is impossible; the mapping has to survive the pipeline.
Conflicting values from credible sources are handled by annotation, not resolution:
| Situation | Correct handling |
|---|---|
| Two credible sources report different statistics | Annotate the conflict with source attribution; do not arbitrarily select one value |
| A document-analysis agent finds contradictory values | Complete the analysis with both values included and explicitly annotated, letting the coordinator decide how to reconcile before synthesis |
| Figures differ because they were collected at different times | Require publication or data collection dates in structured outputs so temporal differences are not misread as contradictions |
That third row is the subtle one and a favorite: two "contradictory" market-size figures from 2024 and 2026 are not in conflict at all, and a pipeline without dates cannot tell.
Report structure: use explicit sections distinguishing well-established findings from contested ones, preserving the original source characterizations and methodological context. And render content types appropriately — financial data as tables, news as prose, technical findings as structured lists — rather than flattening everything into one uniform format.
Worked problems
Problem 1. A support agent handles long conversations by summarizing history every 10 turns. Customers report the agent "forgetting" the refund amount and the date they were promised a resolution, even though those were discussed. What is the fix?
A. Summarize every 20 turns instead of every 10 B. Extract transactional facts — amounts, dates, order numbers, statuses — into a persistent case-facts block included in each prompt, outside the summarized history C. Increase max_tokens on each response D. Instruct the model in the system prompt to remember important details
Approach: The stem describes progressive summarization condensing exactly what the guide says it condenses: numerical values, dates, and customer-stated expectations. The named repair is a separate persistent layer for transactional facts that summarization never touches.
Why the others fail: A slows the loss without stopping it — the same facts vanish, later. C is an output ceiling and has nothing to do with what survives in the input. D asks the model to protect facts that are no longer in its context to protect; the information is already gone by the time it reads the instruction.
Answer: B
Problem 2. A customer opens with "I've been on hold twice today, this is ridiculous. Just give me a person." The agent's system prompt says to attempt resolution before escalating, and the issue looks like a straightforward shipping delay it could resolve. What should the agent do?
A. Resolve the shipping issue first, then offer escalation if the customer is still unhappy B. Escalate to a human immediately, honoring the explicit request C. Escalate because the sentiment score is negative D. Ask three clarifying questions to assess complexity before deciding
Approach: The guide separates two situations that this stem deliberately blends. Frustration alone means acknowledge and offer resolution. An explicit request for a human means escalate immediately, without first attempting investigation — even when the agent could have solved it. "Just give me a person" is explicit.
Why the others fail: A is the correct behavior for the other case — frustration without a request. Here it overrides a stated customer preference. C reaches the right action through the wrong rule; sentiment is named as an unreliable proxy, and building the routing on it misfires on calm customers with unsolvable problems. D makes an explicit request wait through an interrogation.
Answer: B
Problem 3. In a multi-agent research system, the web-search subagent's search API times out. It returns { status: "no results" } and the coordinator proceeds. The final report presents the topic as having little available research. What should the subagent return?
A. Nothing — terminate the whole research workflow so a human can restart it B. Structured error context: failure type, the query attempted, any partial results, and alternative approaches — with the access failure clearly distinguished from a valid empty result C. status: "error" so the coordinator knows something went wrong D. Retry indefinitely until the search API responds
Approach: Two named anti-patterns collide in the stem. Reporting a timeout as "no results" is silent suppression — an error returned as success. And the report's conclusion is the predictable consequence: an access failure was recorded as evidence of absence. The guide's answer is structured error context with all four elements, plus the explicit access-failure-versus-empty-result distinction.
Why the others fail: A is the other named anti-pattern — terminating an entire workflow on a single subagent failure. C is the generic error status the guide rejects: it tells the coordinator something failed but not what was attempted, what partially succeeded, or what to try instead. D removes the coordinator's ability to decide and can hang the run.
Answer: B
Problem 4. Three hours into a Claude Code session exploring a large legacy codebase, the agent starts describing "typical patterns in repositories like this" instead of the actual service classes it identified earlier, and gives inconsistent answers to repeated questions. What is happening and what fixes it?
A. The model is hallucinating; switch to a larger model B. Context degradation in an extended session; have the agent maintain a scratchpad file of key findings to reference, delegate verbose investigations to subagents, and use /compact to reduce accumulated discovery output C. Temperature is too high; lower it to 0 D. The codebase is too large to analyze; sample a subset of files
Approach: The stem is the guide's own degradation symptom, almost verbatim in shape — inconsistent answers plus references to "typical patterns" rather than the specific classes discovered earlier. That description maps to one cause, and the remedies are the named context-management techniques.
Why the others fail: A misdiagnoses a context problem as a capability problem; a larger model in the same saturated session degrades the same way. C treats drift-to-generic as sampling randomness — the findings are gone from working context, and no temperature recovers them. D abandons coverage to avoid a problem that scratchpads, delegation, and compaction solve directly.
Answer: B
Problem 5. An extraction pipeline reports 97% accuracy on a labeled test set. The team proposes auto-approving all extractions the model marks high-confidence, and reviewing only the rest. What should happen before that change?
A. Ship it — 97% exceeds the human error rate B. Analyze accuracy by document type and by field to confirm consistent performance across segments, calibrate field-level confidence against a labeled validation set, and add ongoing stratified random sampling of high-confidence extractions C. Raise the confidence threshold to 0.95 and ship D. Keep reviewing everything; automation is unsafe for extraction
Approach: The guide's warning is that an aggregate figure can mask poor performance on specific document types or fields — 97% overall is consistent with 70% on one format. Three graded moves follow: segment the accuracy analysis, calibrate confidence with labeled data rather than trusting raw scores, and keep sampling the auto-approved population so novel error patterns surface.
Why the others fail: A automates on exactly the number the guide says can mislead. C picks a threshold with no calibration behind it — an uncalibrated 0.95 is a guess dressed as rigor, and it still ignores the segment question. D refuses the trade-off the task statement exists to manage; the goal is aiming limited reviewer capacity, not maximizing review.
Answer: B
Problem 6. A research report cites a market size of $4.2B. Two subagents found different figures from credible sources, and the synthesis agent picked the larger one. Nobody can trace either figure back to a source. What two changes address this?
A. Instruct the synthesis agent to always pick the most recent figure B. Require subagents to emit structured claim-source mappings (source URLs, document names, excerpts) plus publication or collection dates that survive synthesis, and have conflicts annotated with attribution rather than silently resolved C. Have the synthesis agent re-run the searches itself to verify D. Add a citations section generated at the end of the report
Approach: Two distinct failures, both named in Task 5.6. Attribution was lost because findings were compressed without preserving claim-source mappings, and a conflict between credible sources was resolved by arbitrary selection instead of annotation. Dates matter too: the two figures may be from different years and not in conflict at all.
Why the others fail: A replaces one arbitrary rule with another and still hides the conflict from the reader. C duplicates the search subagents' work, burns the synthesis agent's context on raw material, and does nothing about the pipeline that drops attribution. D cannot work — a citations section generated at the end has no mappings left to cite from; provenance must be preserved upstream, not reconstructed downstream.
Answer: B
Exam traps
- Reading this domain as "context windows." Four of six task statements are reliability: escalation, error propagation, human review and calibration, provenance. Budget your study accordingly.
- Summarizing away transactional facts. Amounts, dates, order numbers, statuses, and customer-stated expectations belong in a persistent case-facts block outside summarized history. "Summarize less often" is never the answer.
- Trimming history instead of tool output. Complete conversation history goes in every request; verbose tool results are what you trim to relevant fields. Distractors invert this.
- Ignoring position effects. Lost in the middle is positional — key findings go at the beginning, details under explicit section headers. Options that just add more content to the middle miss it.
- Sentiment or self-reported confidence as escalation triggers. Both are named unreliable proxies for complexity. Legitimate triggers: explicit request for a human, policy exception or gap, inability to make meaningful progress.
- Investigating before honoring an explicit request for a human. Explicit request → escalate immediately. Frustration without a request → acknowledge and offer resolution, escalate on reiteration. The exam tests both and will blend the cues in one stem.
- Heuristic disambiguation. Multiple customer matches means ask for another identifier — never pick the most recent or closest match.
- Policy silence read as policy prohibition. A gap in policy is an escalation trigger, not license to invent a rule or refuse.
- Generic error statuses and silent suppression. "Search unavailable" hides context; returning empty results as success turns an outage into fabricated evidence of absence. And one failure should not terminate the whole workflow.
- Access failure versus valid empty result. Tested in both Domain 2 and Domain 5 — a timeout and a zero-match query must never report identically.
- Missing the degradation symptom. "Referencing typical patterns rather than the specific classes discovered earlier" is the published tell for context degradation. Answers that switch models or adjust temperature are misdiagnoses.
- Crash recovery details. Structured state exports to a known location plus a coordinator-loaded manifest injected into agent prompts. Not conversation checkpoints, not replay.
- Trusting aggregate accuracy. 97% overall can hide a failing document type or field. Segment the analysis before reducing review; keep stratified random sampling on the high-confidence population.
- Uncalibrated confidence thresholds. Field-level confidence must be calibrated against a labeled validation set before it routes anything. A bare threshold number is an unearned answer.
- Reconstructing citations at the end. Provenance is preserved upstream through structured claim-source mappings, not appended downstream. Conflicting statistics are annotated with attribution, and publication or collection dates prevent temporal differences from being mistaken for contradictions.