A word doing too much work
“Subagent” gets used loosely across the current wave of coding tools — sometimes for a prompt template, sometimes for a personality the model adopts mid-conversation, sometimes for nothing more precise than “the AI did several things.” Inside Claude Code the word names something exact, and the precision is the point. A subagent is a delegated task that runs in its own separately provisioned context window, under its own system prompt, with its own explicit grant of tools, and it returns a bounded result across a narrow channel to the conversation that launched it. Anthropic’s own documentation states the mechanism plainly: “each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions” [1]. Everything else in this article follows from taking that sentence literally rather than as marketing description.
That literalism matters because the interesting questions about subagents are not rhetorical. They are engineering questions with documented, sometimes numeric, answers: what exactly does a subagent see when it starts, what exactly does the parent conversation see when it finishes, why does separating the two help rather than merely relocate the same problem, and under what conditions is the separation worth its cost. This piece works through those questions in order, drawing on Anthropic’s own subagent and context-engineering documentation, its published account of the multi-agent research system built on top of this mechanism, and independent multi-agent-systems research that predates and generalizes the specific implementation. It closes with dated predictions, kept separate from the sourced analysis, about where the architecture is likely to go next.
What a subagent actually is, mechanically
Strip away the framing and a subagent is a new inference session, not a new persona inside an old one. It is defined, in the simplest case, by two required fields in a YAML header — a name and a description Claude uses to decide when to delegate — and optionally by a tools list restricting what it can touch, a model field choosing which model runs it, a system prompt written as the body of the file, and a handful of further fields governing permission mode, hooks, persistent memory, and MCP server access [1]. When Claude Code delegates to one, it writes a short task message describing what needs doing and hands that message, and nothing else, to a fresh process. The documentation is explicit about what does not travel with it: “Subagents receive only this system prompt plus basic environment details like the working directory, not the full Claude Code system prompt” [1]. No conversation history. No memory of files already read. No record of skills already invoked earlier in the session. The subagent’s context window starts close to empty and fills only with what its own task requires.
Three of Claude Code’s own built-in subagents make the abstraction concrete rather than theoretical. Explore is a fast, read-only agent for searching and understanding a codebase; Write and Edit are denied to it outright, and it is invoked with an explicit thoroughness level — quick, medium, or very thorough — set by the delegating conversation. Plan is a similarly read-only research agent used specifically during plan mode, so that a session that is deliberately not allowed to touch files can still gather the context it needs to propose a plan. General-purpose is the unrestricted counterpart, carrying every tool available to subagents, used when a task needs both exploration and modification or several dependent steps in sequence [1]. The three are not different prompting styles laid over one underlying agent; they are three distinct tool grants, and the grant is enforced mechanically rather than requested politely — a subagent whose tools field omits Write cannot write a file no matter what its own reasoning concludes it should do.
That enforcement is the second half of what makes a subagent a mechanism rather than a convention. A custom subagent definition can allow specific tools, deny specific tools on top of an inherited list, restrict which MCP servers it can see, and even gate individual tool calls with a PreToolUse hook that inspects the command before it runs and can block it outright — the documentation gives the worked example of a database-reading subagent whose hook greps every Bash command for INSERT, UPDATE, DELETE, and related statements and exits with a blocking code if it finds one [1]. None of this is enforced by asking the model nicely to stay in its lane. It is enforced by the harness, at the level of which tool calls are even offered or permitted to execute, which is why “specific tool access” belongs in the same sentence as “own context window” when describing what a subagent is.
Why context isolation matters for long-horizon work
A context window is a shared, finite resource, and everything a session does — reading files, running commands, holding earlier turns of conversation — draws down the same budget that the model needs free in order to keep reasoning coherently about the task in front of it. Anthropic’s own framing of this, in its guidance on context engineering, is that the discipline consists of finding “the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome,” precisely because the alternative — simply filling the window with everything that might be relevant — degrades performance rather than improving it [4]. The documented mechanism behind that degradation, sometimes called context rot, is partly architectural: a transformer’s attention computation scales quadratically with the number of tokens it has to relate to one another, and models are trained on comparatively less data at very long sequence lengths, so precision at long range is measurably worse than precision at short range [4].
Independent, peer-reviewed evidence supports the same conclusion from a different angle. Liu and colleagues tested how language models actually use long input contexts on multi-document question answering and key-value retrieval tasks, and found a distinctive positional pattern: performance is highest when the information a model needs sits at the very start or the very end of its context, and “significantly degrades when models must access and use information in the middle of long contexts, even for explicitly long-context models” — and performance falls further, independent of position, simply as the context grows longer [7]. The practical upshot for an agent doing a long-horizon task is unforgiving: a bigger context window does not fix this on its own, because the problem is not capacity, it is what happens to retrieval and reasoning once a great deal of that capacity is occupied by material the current decision does not need.
This is the specific problem a subagent is built to solve, and Claude Code’s own documentation gives a concrete, numeric illustration of the effect rather than an abstract claim about it. In a worked session example, a subagent delegated to research a piece of session-timeout handling reads three files totalling 6,100 tokens of raw source, entirely inside its own isolated window — “None of this touches your main context,” the documentation notes of the reads — and returns a single 420-token summary to the parent conversation, which the documentation flags directly: “That’s the context savings” [2]. The parent’s window absorbs an addition roughly a fourteenth the size of what was actually read. Put as a simple accounting identity, isolation does not shrink the total amount of computation a system performs; it relocates where that computation’s output lands:
The parent conversation’s occupied share of its own window,
The bill this isolation does not eliminate
Isolation is not free, and Anthropic’s own published accounts are candid about the multiplier. Its account of the multi-agent research system built from this same delegation mechanism reports that “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats,” while noting separately that in its BrowseComp evaluation, token usage by itself explained roughly 80 percent of the variance in how well a configuration performed [3]. A later Anthropic account of when to reach for multi-agent architectures at all gives a related but not identical figure — “multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks” — measuring against a single agent’s own budget rather than against a plain chat turn [6]. The two numbers are not in tension so much as answering slightly different questions: one compares a multi-agent system to an ordinary conversational exchange, the other compares it to a single agent already doing the task with tools. Read together, both describe the same underlying trade — more total inference spend, purchased specifically to keep any one window from having to hold everything at once.
Anthropic reports, as a vendor claim about its own internal evaluation rather than an independently reproduced result, that a lead agent on Claude Opus 4 coordinating Claude Sonnet 4 subagents “outperformed single-agent Claude Opus 4 by 90.2%” on its internal research evaluation [3]. That figure describes one system on one evaluation suite and should not be read as a general multiplier for what delegation buys on an arbitrary task; it is evidence that the trade can pay off substantially on the kind of breadth-first, parallelizable work the research system was built for, not a universal constant.
Documented patterns: when to delegate, when not to
Because the isolation is not free, Claude Code’s own documentation states an explicit choice rule rather than leaving practitioners to guess. Use the main conversation, it says, when a task needs frequent back-and-forth or iterative refinement, when several phases such as planning, implementation, and testing share significant context, when the change is quick and targeted, or when latency matters, since “subagents start fresh and may need time to gather context.” Use a subagent when the task produces verbose output the main conversation does not need to keep, when specific tool restrictions or permissions need enforcing, or when the work is genuinely self-contained and can return as a summary [1]. The same documentation adds a third option that is easy to miss: a Skill, for a reusable prompt or workflow meant to run inside the main conversation’s context rather than in an isolated one — the choice is not binary between “delegate” and “do nothing structured,” it is a three-way choice between the main conversation, a skill, and a subagent, matched to whether the work needs shared context, a repeatable procedure, or isolation [1].
Anthropic’s guidance on multi-agent systems specifically narrows this further into three scenarios where the pattern earns its overhead: context protection, when unrelated history would otherwise pollute an agent’s ability to reason about the current problem; parallelization, when genuinely independent subtasks can proceed at once rather than sequentially; and specialization, when a focused toolset and a narrow system prompt produce better decisions than one generalist agent juggling everything [6]. The same source states the rule of thumb plainly: adopt a multi-agent architecture only when “genuine constraints exist that single-agent approaches cannot overcome,” and warns that teams routinely build elaborate multi-agent systems only to find that better prompting on a single agent would have matched the result [6]. Anthropic’s earlier, more general guidance on agent design frames the same discipline as a starting posture: “start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short,” treating added latency and cost as a deliberate trade for capability rather than a free upgrade [5].
That same source names the orchestrator-workers pattern — a central agent that dynamically decomposes a task and delegates the pieces to workers, useful precisely because the subtasks cannot be predicted in advance — and cites coding, where the number of files that need changing and the nature of each change vary by task, as an ideal use case [5]. It is worth being precise about how that sits alongside the multi-agent research system’s separate finding that coding is a comparatively poor fit for heavy parallel delegation, because domains “that require all agents to share the same context or involve many dependencies between agents are not a good fit,” and coding specifically has “fewer truly parallelizable tasks than research” [3]. These are not contradictory claims once the grain size is made explicit: one describes a single orchestrator making sequential delegation decisions against one shared, mutable codebase, which is exactly the workflow Claude Code’s own built-in Explore, Plan, and general-purpose subagents implement. The other describes fully independent, fully parallel agents each holding their own context and potentially editing the same shared state at once, which is where a merge conflict between two subagents’ edits is not a hypothetical — it is the specific dependency problem parallel research subagents do not have, because independent web searches do not collide the way two edits to the same function do.
Coordination and handoff: how a result actually gets back
The mechanics of the return trip are as deliberately narrow as the mechanics of the dispatch. When a subagent finishes, what reaches the parent conversation is its final text response plus a small metadata trailer recording token counts and duration — not its tool call history, not the files it read, not its intermediate reasoning [1]. As of the current default, subagents run in the background rather than blocking the parent conversation, and “a background subagent’s results reach Claude as a completion notification in a later turn,” with the parent conversation explicitly reporting that a subagent is “still running” if asked about progress before that notification arrives [1]. This is not a stylistic choice; it is the same isolation principle applied to timing as well as content — the parent does not narrate the subagent’s work in progress because it genuinely does not have access to it until the subagent hands back a finished result.
That narrow channel is also a security boundary, and Claude Code’s documentation is specific about where it is enforced. Every subagent’s final report passes through an output scan before the parent reads it, because a subagent may have read files, web pages, or command output that were never reviewed by anyone, and text drawn from those sources can carry instructions aimed at hijacking the conversation that receives it. The scan does not judge whether content is malicious and does not remove anything; it inserts a backslash into text that imitates the harness’s own formatting, such as a fabricated system-reminder tag, and prepends a marker line when a report imitates such a tag or references permission-bypass settings, so that an injected instruction reads as inert text rather than as part of the conversation [1]. A returned result can still direct what the parent does next — that is the entire point of delegating a research task — but it cannot silently grant itself authority it was not already permitted to have: “no message from any agent counts as your approval for a pending permission prompt, and no agent message can change a subagent’s permission settings, CLAUDE.md, or configuration. Only the permission system or your own messages can grant approval” [1]. Coordination, in other words, is bounded on purpose: a subagent’s output is data the parent reasons over, not a command channel the parent obeys.
Two further governance limits shape how much delegation a session can run at once. By default, a subagent can itself spawn subagents up to three layers below the main conversation before the harness withholds the delegation tool entirely, so a deeply nested chain of delegation terminates rather than growing without bound [1]. Separately, a concurrency limit — 20 running subagents by default — blocks a session from spawning further parallel work until the running count drops, with no equivalent cap on the total number of subagents a session can spawn over its lifetime [1]. And there is a documented, deliberate exception to isolation itself: a fork inherits the entire parent conversation rather than starting fresh, trading the isolation the rest of this architecture is built around for a case where “a named subagent would need too much background to be useful” and the cheaper option is to hand off a side task with full shared context intact [1]. The existence of that exception, documented as an exception rather than the default, is itself evidence that isolation is understood internally as the considered choice, not an accident of implementation.
What independent multi-agent research adds
None of this is specific to one vendor’s product, and treating it as though it were would understate how much of the reasoning generalizes. Sumers and colleagues’ Cognitive Architectures for Language Agents proposes a vocabulary for language agents built from modular memory, a structured action space spanning both internal reasoning and external tool use, and an explicit decision procedure for selecting among actions — a framework meant to organize existing agent designs and anticipate future ones rather than describe any single implementation [9]. Read against Claude Code’s subagents, the correspondence is close: a subagent’s tool grant is exactly a structured, bounded action space; its system prompt and task message are exactly a procedural specification of what it is meant to decide; and the isolation of its context window is exactly the boundary a modular memory architecture requires between one agent’s working state and another’s.
Wu and colleagues’ AutoGen frames the same idea from the angle of building systems out of it rather than classifying them: agents that are “conversable” and “customizable,” combining language models, tool use, and optionally human input, with interaction patterns defined flexibly in natural language or code rather than fixed in advance [8]. That is the general academic articulation of what Claude Code’s description field and task-message construction do concretely — deciding, per delegation, what a given exchange between agents is even for.
Hong and colleagues’ MetaGPT supplies the cautionary half of the same literature. Its starting observation is that naively chaining large language models into a multi-agent pipeline compounds errors — “logic inconsistencies due to cascading hallucinations” is how the paper frames the failure mode — and its proposed fix is to encode standardized procedures into role-specific prompts, assigning agents roles such as product manager, architect, and engineer along an assembly-line division of labor rather than letting one undifferentiated agent hand work to another undifferentiated agent [10]. That is precisely the argument for Claude Code shipping Explore, Plan, and general-purpose as separately defined, separately tool-restricted subagent types instead of one generic delegate: specialization is not a convenience feature layered on top of isolation, in this literature’s account, it is part of what keeps errors from compounding across a chain of delegated steps.
Predictions, kept separate from what is sourced above
These are forecasts about where the architecture is likely headed, not descriptions of what is already documented. Horizon: 12 August 2028.
One. The vocabulary of bounded, isolated delegation — a separate context window, an explicit tool grant, a narrow return channel — will converge across the major agentic coding tools as a named primitive, not stay a Claude Code idiosyncrasy, because the token-cost and context-rot evidence behind it does not depend on which vendor’s model is running inside the sled. Disconfirmed if, by the horizon date, at least two other widely used agentic coding tools still have no documented equivalent to a context-isolated delegated subtask with a bounded, summarized return.
Two. Delegation’s token multiplier — documented today at roughly 4 to 15 times a plain chat exchange, depending on the comparison baseline — will become a cost users are shown per delegation rather than an implementation detail folded into an aggregate bill, because a multiplier that large is too consequential to leave unpriced once delegation is routine rather than occasional. Disconfirmed if mainstream agentic tools in 2028 still report only wall-clock latency for a delegated task, with no token or cost accounting exposed per subagent call.
Three. The trust boundary that currently prevents a subagent’s returned text from granting itself permissions or altering the parent’s configuration will hold as the default architecture rather than loosen, because loosening it reopens exactly the injection vector the output-scanning mechanism exists to close. Disconfirmed if a major agent framework ships a default configuration in which a subagent’s returned report can silently approve a pending permission prompt or rewrite the parent’s permission settings without a separate human or policy check in between.
What the mechanism actually buys
Set the specifics down together and the shape is a single trade, stated honestly rather than sold as a strict improvement. A subagent buys back attention in the one window that has to keep reasoning about the whole task, by moving the tokens that do not need to live there into a separate, disposable context that reports back a summary instead of a transcript. It buys enforced tool restriction, not requested restraint. It buys a documented, narrow channel for that summary to return through, with a scanning step and a permission boundary standing between what a subagent says and what the parent conversation is willing to do about it. None of that is free — Anthropic’s own accounting puts the price at several times the token cost of doing the same work in a single conversation — which is exactly why the documentation states a choice rule instead of a default: delegate when the isolation is worth more than the tokens it costs, and not simply because a subagent is available to ask.
