Context Compaction and Sub-Agent Handoff for Long-Horizon Tasks#

TL;DR#

When a long-running agent task threatens to exceed its usable context budget, you have two structurally different escape hatches: compaction (summarize the current context and continue in the same "thread" with a compressed history) and handoff (stop, and hand the remaining work to a fresh context - a sub-agent or a new session - carrying forward only a deliberately chosen summary). They are not interchangeable defaults; each is the right call for a different shape of failure, and choosing wrong quietly caps how far a long-horizon task can actually go before it degrades.

The idea#

Everything in this subject up to this lesson has been about managing the context budget within a single continuous window - what to put in it (lessons 01-07), and how it fails when mismanaged (lesson 08), and how to extend effective reach through retrieval and memory (lesson 09). This lesson is about the harder, higher-stakes decision that shows up specifically in long-horizon agentic work: at some point, staying in the same context stops being viable, or stops being optimal, and you have to decide what to do about it - and that decision has real, sometimes irreversible, costs no matter which option you pick.

This is a staff-level judgment call, not a mechanical procedure, for a specific reason: there is no universally correct answer. Compact too aggressively and you silently discard the one detail that mattered three steps later. Compact too conservatively and you eat the distraction/confusion costs from lesson 08 anyway, just later. Hand off too eagerly and you pay a coordination and re-grounding tax on every subtask, plus you lose the parent's ability to reason continuously about accumulated nuance. Hand off too rarely and one context accumulates so much unrelated work that every subtask after the first is operating in a polluted environment. The job of a staff engineer designing a long-horizon agent isn't to pick "compaction" or "handoff" as a policy once - it's to build the judgment (and, often, the tooling) to make that call correctly, repeatedly, task by task.

How it works#

Compaction: same thread, compressed history#

Compaction means taking a conversation or agent trajectory that is approaching its usable context limit, summarizing its contents, and continuing execution in a new context window seeded with that summary instead of the full raw history. Critically, this is not the same as truncation (dropping the oldest turns) - a good compaction step is a deliberate rewrite that tries to preserve everything still load-bearing while discarding everything that isn't.

What a compaction pass should keep versus discard. The general pattern - documented directly in how Anthropic's own coding agent implements this - is: preserve architectural decisions, unresolved bugs, and specific implementation details; discard redundant tool outputs and messages that have already served their purpose and are unlikely to be needed verbatim again. A lower-risk, narrower version of the same idea is "tool result clearing" - once a tool's raw output has been read and acted on, replace it with a short note of what it said, since the agent rarely needs to re-read a full raw output it already processed.

The central engineering problem: recall versus precision. Tuning a compaction prompt is a genuine trade-off, not a solved problem. If you optimize purely for recall - capture every possibly-relevant detail - you end up with a summary that's still bloated, undermining the entire point of compacting. If you optimize purely for precision - keep only what's obviously essential - you risk silently dropping something that turns out to matter five steps later, and by the time you notice, the raw detail is already gone and unrecoverable. The recommended practice is to tune iteratively against real, complex agent traces: start by maximizing recall (does the compacted summary, in practice, actually contain what turned out to matter later?), then iterate to improve precision (what's still in there that never got used?).

Worked example: a compaction trace. Consider a coding agent working a multi-hour task: migrate a service's database layer to a new ORM. Over 150 tool calls, it has read dozens of files, run failing tests, fixed three unrelated bugs it stumbled into along the way, and made several judgment calls about naming conventions the user corrected once. The raw trajectory is now 180,000 tokens and the agent is starting to show distraction symptoms (lesson 08) - repeating file reads it already did, forgetting the user's naming correction from 40 turns back. A compaction pass runs: it discards the raw stdout of the 40 test runs that eventually passed (keeping only "tests pass as of step 112"), discards the full diffs of the three unrelated bug fixes already merged (keeping "fixed off-by-one in pagination, unrelated to this migration, already committed"), but preserves, verbatim or near-verbatim: the user's naming correction ("use snake_case_ids not camelCaseIds, corrected at step 38"), the current state of the migration plan, and the one still-open bug the agent hasn't resolved yet. The compacted context re-starts at perhaps 8,000 tokens instead of 180,000, with the agent able to continue the same logical task without re-discovering any of that.

What compaction structurally cannot fix. Compaction reduces volume, which helps with distraction and confusion (lesson 08). It does not help with poisoning - if a false claim was in the context, a naive compaction pass will often summarize the false claim right along with everything true, faithfully preserving the error in more compressed form. A compaction step that isn't also doing some validation is not a poisoning fix, and treating it as one is a common mistake. Compaction also does nothing to resolve clash - if two contradictory claims are both "load-bearing" by the compaction prompt's judgment, both may survive into the summary, contradiction intact, just more concisely stated.

Handoff: fresh thread, deliberately scoped inheritance#

Handoff means stopping work in the current context and starting a new context - a sub-agent, or a new top-level session - that inherits only what you deliberately choose to pass it, not the accumulated history. The parent (if there is one) typically receives back only a condensed result, not the sub-agent's full working trace.

Why fresh context beats compaction for some tasks. A sub-agent that gets a clean, unpolluted context to do focused, deep work (say, an extensive multi-step investigation) can explore as aggressively as it needs to - using tens of thousands of tokens of scratch work - without that exploration ever polluting the parent's context, because only a distilled summary (commonly on the order of 1,000-2,000 tokens) crosses back. This is qualitatively different from compaction: compaction still carries the shape and residue of everything that happened forward, even compressed; handoff draws a hard boundary and only what's explicitly returned crosses it. For work that is naturally decomposable into a self-contained subtask (research a specific question, implement a specific isolated component, verify a specific claim), handoff gets you separation of concerns that compaction structurally cannot: the parent's context stays clean of the sub-agent's intermediate false starts, dead ends, and scratch reasoning, not just compressed versions of them.

What handoff costs. Fresh context means genuinely losing continuity, not just compressing it. A sub-agent starting fresh does not have the parent's accumulated situational judgment - it has to be told, explicitly, whatever context it needs, and anything the briefing omits is simply unavailable to it, with no "let me recall an earlier turn" fallback the way a compacted-but-continuous context has. There's also a real coordination tax: someone (the parent agent, or the human) has to decide what to put in the handoff briefing, and a briefing that's too thin produces a sub-agent that re-derives things the parent already knew, wasting the very budget you were trying to save. And the summary returned by the sub-agent is itself a compaction-like artifact with the same recall/precision trade-off - a sub-agent that returns too terse a summary can silently drop something the parent needed.

The judgment call: which one, and when#

This is where the staff-level reasoning actually lives - there is no formula, but there are load-bearing questions to ask:

Is the task decomposable into a bounded, self-contained subtask, or is it fundamentally one continuous line of reasoning? A large-scale investigation with several genuinely independent sub-questions (e.g., "check whether library A, B, and C each support feature X") decomposes cleanly - each check is independent and doesn't need the others' intermediate work. A task with one continuous thread of accumulating decisions (e.g., an extended debugging session where each hypothesis depends on ruling out the previous one) does not decompose cleanly - handing off mid-investigation forces you to re-explain the entire chain of ruled-out hypotheses in the briefing, which is close to as expensive as just compacting in place.

How much of the accumulated context is still load-bearing versus dead weight? If most of what's accumulated is still relevant and the problem is really about volume relative to the model's effective attention (distraction, lesson 08), compaction is proportionate - you're not trying to isolate anything, you're trying to shrink something that's still one coherent piece of work. If a large fraction of the context is dead weight and the remaining useful work is separable, handoff lets you leave the dead weight behind entirely rather than compress it.

What's the cost of a bad summary, in each direction? A bad compaction summary degrades the same task continuing in the same thread - the failure is visible in-context and often recoverable by asking the agent to re-check something. A bad handoff briefing produces a sub-agent operating on a wrong or incomplete premise from the start, structurally similar to context poisoning but injected deliberately at the boundary - and because the sub-agent has no access to the parent's full history, it often cannot self-correct the way an in-thread agent sometimes can by re-reading earlier turns.

Is this a one-time long task, or a recurring pattern? If a certain shape of subtask recurs constantly (e.g., every task in this agent's domain involves an isolated "search and summarize" phase), it's worth building a standing sub-agent pattern with a well-tuned handoff briefing template, amortizing the cost of getting the boundary right over many uses. A one-off long task rarely justifies that investment - compaction, tuned once for this trajectory, is often cheaper to get right than designing a reusable handoff boundary for a task shape you'll never repeat.

Worked example: choosing between them mid-task. An agent is doing a large refactor across a codebase with 40 call sites that need a signature change. Partway through, at call site 15, the context is getting heavy with the diffs and reasoning from the first 14. Two options: (a) compact - summarize "call sites 1-14 done, pattern is X, one exception at site 7 needed special handling because of Y" and continue in the same thread for sites 15-40; or (b) hand off - spin up a fresh sub-agent per remaining batch of call sites, each briefed with just the pattern and the one exception, returning only "done" or "needs review" per site. Option (a) is usually right here: the work is genuinely one continuous pattern-application task, the sites aren't independent in any meaningful sense (spotting a second exception at site 22 should change how sites 23-40 get handled), and there's no benefit to isolating them from each other's context - in fact isolating them risks losing the accumulated pattern knowledge that makes later sites faster to fix. Option (b) becomes the better call only if the call sites turn out to be genuinely independent in a way that makes cross-site learning unlikely to matter (e.g., each site requires an unrelated, bespoke investigation, not application of one shared pattern) - which is a different task shape than the one described.

Failure modes specific to compaction and handoff themselves#

Both mechanisms can fail in ways that mirror lesson 08's taxonomy, one level up: - Over-compaction as self-inflicted poisoning: a compaction prompt tuned too aggressively for precision drops something later needed, and worse, sometimes replaces a nuanced fact with an oversimplified restatement that is subtly wrong rather than merely incomplete - a compaction-induced hallucination. - Handoff briefing as clash: if a sub-agent's briefing summarizes the parent's state slightly differently than the parent's own actual current state (drift between what was written into the briefing and what's still true), the sub-agent's returned summary can clash with the parent's context when it returns - and because the two developed independently, this clash is not always obvious to catch. - Compaction cascades: an agent that compacts repeatedly over a very long session is running its history through summarization multiple times, and each pass has its own recall/precision loss - errors and omissions can compound across compaction passes the same way poisoning compounds across turns, which is a reason to periodically checkpoint against ground truth (the actual code state, the actual tool outputs) rather than trusting an N-times-compacted summary indefinitely.

Pros#

• Compaction: preserves full continuity of reasoning in one logical thread; lower coordination overhead than spinning up and briefing separate sub-agents; well-suited to tasks that are one continuous line of work.
• Handoff: gives genuinely clean, unpolluted context to isolated subtasks; enables parallelism (multiple sub-agents can work simultaneously in ways a single compacted thread cannot); keeps the parent's context small regardless of how much exploratory work a subtask required.

Cons#

• Compaction: still a single, ever-growing thread even if compressed - cascading compaction passes accumulate their own loss; cannot fix poisoning or clash, only distraction/confusion; tuning the compaction prompt correctly is genuinely hard and traces-specific.
• Handoff: loses continuity by design - anything not in the briefing is simply gone from the sub-agent's view; adds real coordination overhead (writing the briefing, parsing the returned summary); introduces a new clash surface at the parent/sub-agent boundary; poor fit for tasks that are one continuous thread of dependent reasoning.

Alternatives#

• Do nothing and let the context grow until it fails or hits a hard limit. Never actually preferable, but worth naming as the default a team gets by not deciding - it's the baseline these two techniques exist to avoid, and it reliably reproduces every failure mode from lesson 08 with no mitigation in place.
• Persistent memory (lesson 09) as a substitute for both. Writing durable facts to an external memory store and retrieving them as needed can reduce how often compaction or handoff is even necessary, by keeping the working context leaner in the first place. It's a complementary discipline, not a replacement - memory answers "what should be durably remembered," while compaction and handoff answer "what do we do about the context we're actively working in right now."
• Hard truncation (drop oldest N turns, no summarization). Cheaper than compaction to implement, but strictly worse in expected quality - it drops old-but-still-relevant detail indiscriminately instead of making a judgment call about what to keep, and is essentially guaranteed to eventually drop something load-bearing on a long enough task.

When to use it#

Use compaction when a task is one continuous logical thread approaching its effective context budget, and the accumulated history is still mostly relevant - just too voluminous. Use handoff when a task decomposes into genuinely independent subtasks that don't need each other's intermediate reasoning, especially when parallelism is valuable or when a subtask needs to explore aggressively without polluting a longer-running parent session. Use both together on tasks long and complex enough to need periodic compaction of the parent thread and delegation of self-contained sub-investigations - these are not mutually exclusive within a single long-horizon task.

When NOT to use it#

Don't reach for handoff on tasks with genuinely dependent, continuous reasoning, where the cost of re-briefing a fresh context approaches the cost of the work itself - you'll pay the coordination tax without getting the isolation benefit, since the sub-agent will just need to reconstruct most of what the briefing left out. Don't reach for compaction as a fix for poisoning or clash (lesson 08) - it will often faithfully preserve the underlying error in a smaller package rather than resolve it; those need validation and explicit contradiction-resolution, not summarization. Don't compact or hand off prophylactically on short tasks that never approach their effective context budget in the first place - both techniques have real overhead (compaction prompt cost and risk, handoff briefing cost and risk) that isn't justified until the task is actually long-horizon enough to need it.

Key takeaways / mental model#

Compaction and handoff solve the same underlying problem - a long-horizon task outgrowing its usable context - with structurally different trade-offs: compaction trades completeness for continuity (same thread, less of it, but still fundamentally one accumulating summary with its own compounding loss); handoff trades continuity for isolation (fresh thread, nothing carries over except what's deliberately briefed, but genuinely clean). The staff-level skill is not memorizing "use handoff for research, compaction for coding" as a rule of thumb - it's asking, for the specific task in front of you: is this one continuous thread of dependent reasoning, or does it decompose into bounded, independent subtasks? What's actually still load-bearing in the accumulated context, and what's dead weight? And what does a bad summary cost me in each direction, given how this specific task would need to recover from it? Neither technique is free, and both can silently degrade the very quality they're meant to protect if applied carelessly.

Self-check questions#

1. An agent is three hours into an extended debugging session where each new hypothesis depends on having ruled out the previous ones. Context is getting large. Would you compact or hand off, and what specifically about this task's shape drives that answer?
2. An agent needs to research five unrelated competitor products and summarize each. Would you compact or hand off, and why does this task's shape point the opposite direction from question 1?
3. Explain why compaction is not a valid fix for context poisoning, using the mechanism of how a compaction prompt actually operates (what does it look at, and what does it have no way of checking?).
4. Design a compaction prompt's keep/discard policy for a long-running customer-support agent handling one escalated ticket over many hours of back-and-forth. What specifically must survive compaction, and what's safe to discard? Justify each choice against the cost of getting it wrong later in the same ticket.
5. A sub-agent returns a 1,500-token summary from a 60,000-token investigation, and the parent later discovers the summary omitted a caveat that turns out to matter. Whose failure is this - the sub-agent's summarization, the parent's briefing, or neither - and what would you change to prevent a recurrence?
6. Why might a task that starts out looking like a clean handoff candidate (five independent-seeming subtasks) turn out, partway through, to actually need compaction-style continuity instead? What would be the observable signal that your original decomposition was wrong?

References#

• Anthropic, "Effective context engineering for AI agents" (September 2025) - https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic Claude Cookbook, "Context engineering: memory, compaction, and tool clearing" (2025) - https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools
• Drew Breunig, "How Long Contexts Fail and How to Fix Them" (June 2025) - https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html
• Packer et al., "MemGPT: Towards LLMs as Operating Systems," arXiv:2310.08560 - https://arxiv.org/abs/2310.08560