Context Management: Keeping the Critical Facts Alive
Domain 5.1 and 5.4: the summarization and position risks that lose critical facts, the case-facts block and trimmed tool outputs that preserve them, and managing a long codebase exploration with scratchpads, subagents, /compact, and crash-recovery manifests.
Domain 5 — Context Management & Reliability — is 15% of the exam by weight, but it’s reinforced across nearly every scenario, so you’ll meet it everywhere. It opens with the discipline that keeps an agent coherent over a long interaction: managing context so the facts that matter survive. Tasks 5.1 (conversation context) and 5.4 (large-codebase exploration). These are architectural patterns, verifiable by reasoning; where a claim is about model behavior it’s noted, and /compact and the context-usage APIs are confirmable in the tooling.
Three ways context goes wrong
A long conversation degrades in specific, testable ways, and the exam wants you to recognize them:
- Progressive summarization loses precision. When you condense history to save tokens, the numbers go first: amounts, percentages, dates, and customer-stated expectations get compressed into vague prose. “The customer wants a refund of $47.50 on order A17, promised by Friday” becomes “the customer has a refund concern” — and now the agent can’t act on the specifics because they’re gone. Summarization is lossy exactly where it hurts most.
- Lost in the middle. Models process the beginning and end of a long input reliably, but may omit findings buried in the middle. A critical fact in the center of a large context is the one most likely to be dropped.
- Tool results accumulate disproportionately. An order lookup returns 40+ fields when 5 are relevant; every such result piles into context, consuming tokens far out of proportion to its usefulness and crowding out what matters.
Each has a fix, and the fixes are the exam’s skills.
Preserving what matters
The central technique against summarization loss is a case-facts block: extract the transactional facts — amounts, dates, order numbers, statuses — into a persistent structured block that you include in every prompt, outside the summarized history. The conversation can be summarized freely, because the precise facts live in a separate layer that’s never compressed:
CASE FACTS (verbatim, never summarized):
- order: A17 amount: $47.50 status: delivered 2026-06-01
- customer expectation: refund by Friday 2026-06-06
- policy: 30-day returns; delivered 45 days ago → outside window
For multi-issue sessions, keep the same idea per issue — structured issue data (order IDs, amounts, statuses) in a separate context layer, so a session juggling three tickets doesn’t blur their facts together.
Against tool-result bloat: trim verbose tool outputs to the relevant fields before they accumulate. If a return only needs five fields from a 40-field order lookup, keep those five — the trimming happens before the result enters context, so the noise never piles up. (This is the Grep-then-Read incremental discipline again: pull what the task needs, not everything available.)
Against lost-in-the-middle: place key findings at the beginning of an aggregated input and organize the rest under explicit section headers. You’re deliberately positioning the important material where the model reads reliably, and structuring the detail so nothing critical hides in an unmarked middle. And when agents feed other agents, have upstream ones return structured data (key facts, citations, relevance scores) rather than verbose reasoning chains — the downstream agent has a limited context budget, and structured input respects it.
Managing a long codebase exploration
Task 5.4 is the same problem at a larger scale: exploring a big codebase over an extended session. The failure mode is context degradation — as the session runs long, the model starts giving inconsistent answers and referencing “typical patterns” instead of the specific classes it discovered earlier. It’s forgetting its own findings. Four techniques counter it:
- Scratchpad files. Have the agent record key findings to a file and reference that file for later questions, so a discovered fact survives beyond the context window — external memory that context degradation can’t erase.
- Subagent delegation. Spawn a subagent to investigate a specific question (“find all test files,” “trace the refund-flow dependencies”) while the main agent keeps only the high-level coordination. The verbose exploration happens in the subagent’s isolated context; the main agent stays clean.
- Summarize before spawning. Before launching subagents for the next phase, summarize the current phase’s key findings and inject that summary into their initial context, so each phase builds on the last without carrying the raw detail forward.
/compact. Use the/compactcommand to reduce context usage during a long session when the window fills with verbose discovery output — a deliberate compaction when you’ve accumulated more than you need. (The SDK also exposes context-usage inspection and aPreCompacthook, verified inclaude-agent-sdk 0.2.128, so compaction is observable and hookable.)
Crash recovery, structurally
The reliability half of 5.4 is surviving a crash mid-exploration. The pattern: each agent exports its state to a known location, and the coordinator loads a manifest on resume and injects the recovered state into the agents’ prompts. Instead of restarting a multi-hour exploration from zero, the coordinator reads the manifest of what each agent had found and continues. This is the session/durable-execution idea expressed as explicit state files — the same guarantee (pick up where you stopped) built from structured exports rather than an automatic checkpointer. The exam-ready point: crash recovery is a design, not an accident — you get it by having agents persist structured state that a coordinator can reload, not by hoping the session survives.
Final thoughts
Context management is preservation against three losses: summarization that drops precise facts (fixed by a case-facts block kept outside the summary), the lost-in-the-middle effect (fixed by front-loading key findings and using section headers), and tool-result bloat (fixed by trimming to relevant fields before accumulation). At codebase scale, scratchpad files, subagent delegation, phase summaries, and /compact counter context degradation, and crash recovery comes from agents exporting structured state a coordinator reloads. The through-line for the whole domain: decide deliberately what stays in context and what gets externalized — the facts you can’t afford to lose belong in a layer that summarization can’t touch.
Next: escalation and error propagation — when an agent should hand off to a human, and how errors should travel through a multi-agent system.
Comments