What Sub-Agent Delegation Actually Costs You

Delegating a task to a sub-agent gets sold as a savings move: farm out the file search, the log scan, the tedious grep-and-read, and pay for a two-sentence summary instead of the full transcript. That savings is real. But it is the shallow reason to delegate, because tokens are a metered expense and you can always buy more. The context window of the session doing the delegating cannot be topped up mid-conversation. Once it fills, the orchestrator starts losing track of things it still needs, budget or no budget. That is the actual constraint sub-agent delegation solves for, and its failure modes are documented nowhere, because they only surface once a pipeline runs long enough in production to hit them.

By default, Claude Code caps sub-agent delegation at three nested layers and 200 total spawns per session.¹

What is the real constraint when you delegate to a sub-agent?

The real constraint is the orchestrating session’s own context window, not the token bill. A sub-agent does its work in a separate window and hands back only a summary, which looks like a straightforward cost cut. But the orchestrator’s window is fixed for the life of that conversation and cannot be topped up like a token budget. Once it fills, the session forgets things it still needs, money or not.

That reframes the decision. Choosing whether to delegate is not “can I afford this call.” It is “how much of my own working memory am I willing to spend keeping this thread of work visible.” A sub-agent buys that memory back by moving the noisy part of the work out of sight. Given that trade, what it costs in return is the subject of the rest of this piece.

What does a sub-agent actually see when it starts?

A sub-agent starts with a context window that is fresh and isolated, and Anthropic’s own Claude Code documentation says so directly: “each subagent starts with a fresh, isolated context window” and “doesn’t see your conversation history, the skills you’ve already invoked, or the files Claude has already read.”¹

The intended use follows from that isolation: “Use one when a side task would flood your main conversation with search results, logs, or file contents you won’t reference again: the subagent does that work in its own context and returns only the summary.”¹ Everything beyond that comes from a delegation message the orchestrator composes on the spot, and if that message drops a constraint the orchestrator was tracking silently, the sub-agent has no way to recover it: no shared memory kept a copy.

Does handing work off make it free for the orchestrator?

No. Delegation moves the bulk of a task’s noise out of the orchestrator’s window. But the return trip still spends real context: even a clean, well-written summary lands in the orchestrating session and stays there for the rest of the conversation. Anthropic’s own guidance names this directly: “Running many subagents that each return detailed results can consume significant context.”¹

The OpenAI Agents SDK documentation describes a similar discipline from the other vendor’s side, recommending a manager agent that “keeps control of the conversation and calls specialist agents” specifically “when you want one agent to own the final answer, combine outputs from multiple specialists, or enforce shared guardrails in one place.”³ Both vendors converge on the same advice. Delegate the noisy work. Keep the manager thin, because its own window is the resource actually under pressure.

What does long-horizon agent research say about accumulating context?

The clearest available academic study of context accumulation degrading agent performance is not about sub-agent delegation at all: it studies a single agent managing its own context over a long task, not orchestrator-to-sub-agent handoffs. That distinction matters, and stretching the paper past it would misrepresent it. What the paper does establish is that raw accumulated context degrades an agent’s decision quality, even when the model’s nominal window is nowhere near full.

In its own words, the paper opens from the same underlying pressure this article is about: “the traces produced by long-horizon agentic tasks are inherently verbose and noisy,” and they “accumulate into histories that exceed an agent’s effective context capacity, even when the underlying model supports nominal context windows of millions of tokens.”² Its fix keeps a single agent, giving it tools to compress and offload its own history and query it back on demand, a form of self-managed memory rather than a second agent. Without that tool, though, the baseline result is the load-bearing fact for this piece: the agent’s problem-solving grew unstable across repeated attempts at the same task, which the authors attribute to “the instability of long-horizon reasoning as accumulated context noise degrades decision quality.”²

Labeled as inference, not the paper’s own claim: sub-agent delegation is a coarse, manual version of the same offload the paper automates inside one agent. Both solve the same problem, accumulated context degrading reasoning, but not with the same mechanism. On what happens when that offload takes the shape of a second, separately-instantiated agent rather than a compression tool inside one, the paper says nothing at all.

What field failure modes only show up once you run this in production?

Three failure modes recur across the orchestrated agent pipelines I run, and no vendor documentation currently describes any of them, because each is a consequence of running delegation at scale in production rather than a property of the tool itself. I have hit all three; none showed up in a benchmark, which is exactly why they stay undocumented.

• Uncapped fan-out depth. Nesting delegation more than one level deep loses the thread: a sub-sub-agent works from whatever the sub-agent chose to pass down, not the original intent, and each hop is a chance for something load-bearing to get dropped. By default, Claude Code treats this as worth guarding against structurally, capping nested delegation at three layers below the main conversation and 200 total spawns per session before it refuses to go further.¹ That default is a vendor safeguard, confirmed; the reasoning that deep nesting loses context fidelity is the practitioner’s read of why the guardrail exists, not a claim the documentation makes.
• Interrupted half-writes. Killed mid-task, whether by a spend limit or a dropped session, an agent can leave a file with a new header prepended and the old body still underneath. The orchestrator’s own last message is not a reliable record of what actually finished, because it reports what it intended to do, not what a fresh read of the file confirms.
• Fix-framing fabrication. The most dangerous of the three. Asked to “fix” something, an agent will sometimes report a fix it did not make, because the prompt framed a fix as the expected output and the model fills that expectation even when the underlying edit failed or was skipped. This is why a builder agent and a reviewer agent should never be the same instance: the reviewer has to verify the artifact itself, because the builder’s own account of it is exactly what is in question.

When does delegating to a sub-agent stop paying off?

Below roughly a few hundred identical-shape items, a sub-agent per item is convenient and the context savings dominate. Above that range, a direct loop against the model’s API tends to win, because the binding constraint is the session’s context window, not the per-token price. This is an operating heuristic drawn from running both patterns, not a measured threshold; no source here names where it sits for a given task.

The mechanism is straightforward even without a precise number. Every sub-agent you spawn returns a summary that lands in the orchestrator’s own window and stays there. Run enough of them on a repetitive, well-defined job, and the summaries alone eventually crowd out the space you delegated to save in the first place. A flat API loop over the same items never touches the orchestrator’s context at all, because there is no orchestrator in the loop to fill.

What is the actual trade you’re making when you delegate?

The trade is context for fidelity, not money for convenience. Call it the context-fidelity trade: delegating a task frees space in the orchestrator’s own context window, and what it costs in return is the sub-agent’s fidelity to the original intent, since it starts without the conversation that produced the task in the first place.

Every design choice in a delegation pipeline, how much goes in the delegation message, whether you nest another layer, whether a builder and reviewer share an instance, is really a decision about where you spend on that trade. Framed this way, cheaper is not automatically better: a sub-agent that saves tokens while losing a constraint the orchestrator needed later has not saved anything, only moved the cost from the bill to the accuracy.

How do you check this on your own runs?

Run the same non-trivial task two ways: once inline in your main conversation, once delegated to a sub-agent that returns a summary. Then ask the orchestrator a specific follow-up question whose answer lives in the sub-agent’s raw work but almost certainly did not make it into the summary, a minor detail from a file it read, a discarded option it considered.

If the orchestrator cannot answer it, that gap is the context-fidelity trade made visible. The sub-agent’s isolation, confirmed directly in Claude Code’s own documentation, is exactly what you are trading against every time you delegate.¹