If your agent dies forty tool calls in, the model didn't get dumber — its one shared context window filled with stale search results and file dumps until it could no longer see the fact that mattered. We laid out the two in-place fixes for that — evict re-fetchable tool results, or summarize the transcript. This is the move we flagged at the end of that piece and left for later: the third response, the one that doesn't edit the window at all.

The short answer: context editing and compaction both act on a window that has already filled — they repair the damage. A subagent gets its own fresh window, does the bulky work there, and returns only a short final result to the parent. The orchestrator's window never accumulates the intermediate mess in the first place. Anthropic files all three side by side as the long-horizon strategies for context: compaction, note-taking to memory, and sub-agent architectures. The skill is knowing which problem each one solves.

Two families: edit the window, or don't fill it#

Context editing and compaction are the edit-in-place family. Context editing (strategy clear_tool_uses_20250919, default trigger 100,000 input tokens, keeping the last 3 tool uses) walks the message list and replaces old tool_result blocks with a placeholder — cheap, because tool results are re-fetchable, but it invalidates your prompt cache prefix. Compaction (compact_20260112, default trigger 150,000 tokens, minimum 50,000) is heavier: it summarizes the whole transcript into a compaction block and drops the verbatim history. It buys the most room and is the only lever that compresses the agent's own reasoning — but a detail dropped from a summary is gone for good.

Both share one property worth staring at: they only run after the window is nearly full. They are damage control.

The subagent doesn't do damage control — it avoids the damage#

A subagent is a different shape of answer. In the Claude Agent SDK you define one by passing an agents map in your query() options, and the key line from the docs is this: "Each subagent runs in its own fresh conversation. Intermediate tool calls and results stay inside the subagent; only its final message returns to the parent."

from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition

async for msg in query(
    prompt="Review the auth module for security issues, then summarize.",
    options=ClaudeAgentOptions(
        allowed_tools=["Read", "Grep", "Glob", "Agent"],  # "Agent" is required to delegate
        agents={
            "code-reviewer": AgentDefinition(
                description="Expert security reviewer. Delegate code audits here.",
                prompt="You are a security reviewer. Return only findings.",
                tools=["Read", "Grep", "Glob"],  # its own clean, read-only window
                model="sonnet",
            ),
        },
    ),
): ...

The code-reviewer can read fifty files and burn a hundred thousand tokens of its own — and the parent never sees any of it. All that comes back across the boundary is the subagent's final message. The orchestrator stays lean not by cleaning its window but by never letting the file dumps enter it. (One naming trap: the invocation tool was renamed from Task to Agent in Claude Code v2.1.63, so if you detect delegation programmatically, match both.)

Context editing and compaction ask "what can I afford to lose from this window?" A subagent asks a better question: "does this work need to be in this window at all?"

The rule: separable and summarizable → isolate#

Here is the line. Spawn a subagent when the subtask is separable and produces a summarizable result — a research sweep, a file exploration, a parallel review, a bulk transform. That's exactly the shape where isolation pays: Anthropic's multi-agent research system, an orchestrator delegating to fresh-window subagents, beat a single-agent baseline by 90.2% on its internal research eval, precisely because "the detailed search context remains isolated within sub-agents while the lead agent focuses on synthesizing."

Keep the work in one window — and reach for context editing or compaction — when it's a single continuous reasoning thread the main loop keeps referring back to. Isolation isn't free. A subagent inherits no parent conversation; you hand-pass every scrap of context through the prompt string, and that string is the only bridge. And the token bill is real: the same multi-agent system used roughly 15x the tokens of an ordinary chat. Fan out a thread that wasn't actually separable and you pay 15x to reconstruct context you already had.

They compose — that's the whole point#

This isn't a bracket you have to win once. The docs note that when the main conversation compacts, subagent transcripts are unaffected because they live in separate files — so the two families stack cleanly. In a real long-running system you use both: subagents keep the orchestrator's window lean by isolating the bulky, separable work, and context editing keeps each individual long-lived loop — the orchestrator and every subagent alike — under its own token cap. Add a memory file for the handful of facts that must outlive any reset, and you have the full stack.

The mental shift is the same one context engineering keeps pushing toward, taken one step further. Once you stop treating the window as a bucket to fill and start treating it as a working set to curate, the next realization is that the cheapest edit is the one you never have to make — because the work happened somewhere else. If you're choosing an orchestration shape to build this on, supervisor vs swarm vs handoffs is the next decision; the SDK-level tradeoff sits in Claude Agent SDK vs LangGraph.