Context Management: Keeping the Critical Facts Alive

What an agent’s context actually is

Every turn an agent takes, the model sees exactly one thing: a block of text. It is assembled from the system prompt, the conversation so far, the tool results gathered along the way, and the current request. The model has no memory between calls. The agentic loop resends the entire history every turn, because the model is stateless and that text is the only thing it knows. That block is the agent’s context, and it is the agent’s whole working memory.

Two facts about context drive this chapter. First, it is finite: the window has a fixed size, and any long task will fill it. Second, and less obvious, it is not uniformly reliable — the model does not attend to every token in a large context equally well. Context management is the discipline of deciding what goes into that limited, imperfectly-read space so the facts that matter survive the whole interaction. It is 15% of the exam by weight. But it is reinforced across nearly every scenario, so you will meet it everywhere.

Why it matters — and why a bigger window won’t save you

The tempting response to a full context window is to reach for a bigger one. It won’t save you. Capacity is only half the problem; attention is the other half. Even when everything fits, a model reads a long context unevenly, so stuffing more in tends to degrade quality rather than improve it. Cost and latency scale with every token too. A bloated context is slower and more expensive for answers that are often worse.

There is a real tension here, and the exam lives inside it. The opposite reflex is aggressive summarizing and trimming to keep context small. That has its own failure: you throw away the one fact you needed. Context management is not “keep less.” It is keep the right things, in the right place, and externalize the rest. Get it wrong in either direction and the agent starts acting on a picture that is missing its critical details.

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.” 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. You 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 position the important material where the model reads reliably, and structure 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

The same problem shows up 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. A discovered fact then 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. Each phase then builds on the last without carrying the raw detail forward.
• /compact. Use the /compact command to reduce context usage during a long session, when the window fills with verbose discovery output. It’s a deliberate compaction for when you’ve accumulated more than you need. The SDK also exposes context-usage inspection and a PreCompact hook in claude-agent-sdk 0.2.128, so compaction is observable and hookable.

Notice that three of the four are the same move as the case-facts block. They get the durable facts out of the accumulating conversation and into a place — a file, an isolated subagent, a phase summary — that degradation can’t reach.

Crash recovery, structurally

The reliability half of a long exploration is surviving a crash mid-way through. 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. It’s the same guarantee — pick up where you stopped — built from structured exports rather than an automatic checkpointer. 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 is the agent’s working memory, and it is both finite and unevenly read. That is why a bigger window is not the answer, and neither is trimming everything to the bone. Preservation runs 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.