Subagent

What is a subagent?

A subagent is a second AI agent that a main agent starts to handle one scoped piece of work. It runs in its own fresh context window, does the job, and hands back a result. The main agent never sees the work in between.

Think of it as briefing a colleague to read forty reports and come back with one page. You get the page. You do not get the forty reports on your desk.

Anthropic's engineering write-up on its Research system describes exactly this shape: subagents "facilitate compression by operating in parallel with their own context windows, exploring different aspects of the question simultaneously before condensing the most important tokens for the lead research agent".

The Claude Code documentation puts the practical trigger plainly: reach for a subagent when a side task would flood the main conversation with search results, logs, or file contents you will never reference again.

Context isolation is the point, not parallelism

Most explanations of subagents open with speed. Run five at once, finish five times faster. That is a side effect, and on many tasks not even a real one.

What a subagent actually buys you is a clean context window. An agent that reads a hundred files fills its own window with a hundred files worth of tokens. Every instruction after that competes with the clutter for the model's attention, and a detail buried three quarters of the way back gets used less reliably than one near the front.

Give the reading to a subagent and the main agent's window grows by one paragraph instead of a hundred files. It stays sharp on the actual question because it was never handed the raw material.

A quick test before you split anything: if the subagent would return almost everything it read, you have isolated nothing and added a hop. Subagents pay off when the ratio between what gets read and what comes back is heavily lopsided.

The orchestrator-worker pattern

The standard wiring has a name. Anthropic describes its Research system as "a multi-agent architecture with an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel".

The lead agent holds the goal and the plan. It decides what to farm out, writes a brief for each subagent, collects the returned results, and does the synthesis itself. The workers know their slice and nothing else.

Microsoft's Agent Framework ships this as a set of named orchestration patterns rather than one design: sequential (agents run one after another), concurrent (agents run in parallel), handoff (agents transfer control based on context), group chat (agents share one conversation) and Magentic (a manager agent picks who acts next as the task unfolds). Most real systems mix two of these rather than committing to one.

Subagent versus handoff

These two get conflated and behave very differently.

With a subagent, control comes back. The main agent stays in charge, the worker returns a result, and the conversation continues where it left off.

With a handoff, control transfers. The OpenAI Agents SDK documentation is explicit about the consequence: when a handoff occurs "it's as though the new agent takes over the conversation, and gets to see the entire previous conversation history". That is the opposite of context isolation. A handoff is for routing a customer to the refunds specialist. A subagent is for keeping forty reports out of your window. Pick by asking whether the second agent should inherit the conversation or be spared it.

What running many agents costs

Every agent pays for its own instructions, its own reasoning and its own tool results. Those bills add up faster than most teams budget for.

Anthropic published the multiple from its own production data: "agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats". The same post draws the obvious conclusion, that multi-agent systems need tasks valuable enough to pay for the extra performance.

Microsoft's guidance on agent orchestration patterns makes the same point about pattern choice: sequential and handoff patterns invoke agents one at a time and accumulate cost across each step, concurrent patterns raise throughput but can spike consumption when several agents call models at once, and manager-driven orchestrations are hardest to predict because the manager keeps iterating until it has a workable plan.

Two habits keep the bill sane: match the model to the job, since an agent that classifies or reformats rarely needs your most capable one, and measure tokens per agent rather than per run, because the expensive worker is usually not the one you suspected.

When a subagent helps and when it makes things worse

The split falls along how broad the task is.

Broad research-style work is where the pattern earns its money. Anthropic reports that "a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval". The same post names the conditions: heavy parallelisation, information that exceeds a single context window, and many complex tools.

A concrete version for a data team. You want to know which of forty Power BI reports still point at a decommissioned source. Forty subagents each open one report, check the connections, and return one line. The lead agent reads forty lines and writes the migration list. No single window ever held forty report definitions.

Narrow work is where it goes wrong. Writing one measure, fixing one broken refresh, answering one question about one table: there is no reading volume to isolate and nothing to run in parallel, so you have bought a second model call, a briefing you had to write, and a slower answer. Anthropic is blunt that "most coding tasks involve fewer truly parallelizable tasks than research".

The rule of thumb we use: split when the work is wide and shallow, keep it in one agent when it is narrow and deep.

What to watch out for with subagents

The failure modes are all about the thing that makes subagents work. Isolation cuts both ways.

Subagents cannot easily share intermediate state. Two workers exploring related ground each rediscover the same facts, and neither can tell the other what it found. Anthropic names the domains this rules out: those "that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today".

You cannot steer a worker mid-run. Once a subagent is briefed and running, the lead agent waits. A worker that misread its brief burns its full budget on the wrong thing before anyone finds out, and the whole system can sit blocked behind one slow searcher.

The brief is the whole job. A subagent has no access to what the main agent already knows, so anything left out of the instruction is gone. Vague briefs produce overlapping work and results that do not fit together. This is ordinary prompt engineering, just with a much shorter feedback loop before the cost lands.

Debugging gets harder. When the answer is wrong you cannot see the reasoning that produced it, because that context was thrown away with the worker. Log what each subagent was asked and what it returned, or you are guessing.

For anything that acts rather than reads, keep a human-in-the-loop at the point where results get applied. A lead agent synthesising forty summaries it cannot verify is a confident answer with no audit trail underneath it.