How Subagents and Multi-Agent Systems Split Work and Cost Tokens

Why a lone agent hits a ceiling

Anyone who has watched Claude Code, LangGraph or Claude's Research feature work has seen the moment when the assistant stops answering by itself and goes off to get help. A file-hunting helper appears, digs around, and comes back with findings. A research question quietly consults a dozen sources in the time it takes a person to open two tabs. The model hasn't suddenly gotten smarter. A small team is doing the work.

Below is a straightforward look at how that teamwork gets assembled, covering subagents, multi-agent systems, their underlying architecture and what they cost.

A single agent, meaning one model running in a loop with tools, is capable. It reads files, browses, writes code and reasons across many steps. Three limits are built into the design, though:

• One context window. Everything the agent reads, thinks and does piles into the same space. On a long exploratory task, tool output eventually pushes the original question out of focus.
• One line of execution. Work happens in sequence. Fifty searches at two seconds apiece eat more than ninety seconds before any writing starts.
• One perspective. A single prompt shapes every decision, so the agent has a hard time holding two rival approaches at once or spotting its own blind spots.

Subagents and multi-agent systems are two answers to this, often combined. The rest covers what each is, how it's put together, and when it pays for itself.

What a subagent is

A subagent is a narrowly scoped helper launched inside one session. It handles a single focused job in a context window of its own and then reports back.

Claude Code is a good illustration. If the main coding session must understand some unfamiliar part of a codebase, it can pass the exploration to a subagent and spare the main conversation. The subagent:

• starts with a fresh, clean context window
• usually carries a smaller, restricted set of tools
• runs its own tight loop of reading, searching and reasoning
• sends a summary to the parent session and keeps the transcript to itself

The value here is isolation, not extra intelligence. The main conversation never sees the fifty files the helper opened, only the three sentences that mattered, so the primary thread stays sharp across a long session and doesn't fill with noise.

A few traits define the pattern as tools like Claude Code implement it:

• Subagents live inside one session. They're a way of delegating, not separate running processes.
• They generally can't launch subagents of their own, which keeps the hierarchy flat and easy to follow.
• A subagent definition is written once and reused. Give a reviewer subagent a fixed system prompt and a short tool list, and it acts identically on every invocation.
• They can run side by side on independent jobs, such as inspecting ten separate areas of a codebase at once.

What a multi-agent system is

A multi-agent system has a different shape. Several independent agents, each with its own context, its own tools and sometimes its own model, pursue a shared goal, usually in a longer or more complicated process than a single session's delegation.

Anthropic's Research feature is the best-known public case. A broad question doesn't get answered directly. Instead, a lead agent drafts an approach and spawns several subagents, each looking into a different angle at the same moment. Their results are merged, checked for citation accuracy and returned as a single answer.

Put together, a lead agent, parallel specialists and a final synthesis step form the pattern most production multi-agent systems use today, and it's the design examined in the rest of this piece.

Where the two ideas differ

The terms are used interchangeably online, which breeds confusion. The actual distinction is shown here.

The shortest way to remember it: a subagent is a technique used inside an agent, while a multi-agent system is an architecture designed around several agents. In practice, many multi-agent systems are built from the subagent pattern. A lead agent that employs subagents is both things at the same time.

The orchestrator and worker architecture

Almost every production multi-agent system, including Anthropic's Research feature, LangGraph's supervisor pattern and Claude Code's subagent model, is some variant of one design: orchestrator and worker.

Each component has a specific responsibility:

• Lead agent (orchestrator). It reads the query, works out a strategy and judges how much effort the job warrants. That judgment counts for more than it seems. Early versions of these systems sometimes launched fifty subagents for a question that needed one.
• Memory or scratchpad. The plan is written down outside the conversation. Long agent runs can overrun the model's context window, and if that happens midway, the plan has to outlive the truncation and not vanish along with it.
• Subagents. Each gets an explicit goal, a defined output format, advice on which tools and sources to use, and firm boundaries so two of them don't silently repeat each other's work. Every one runs its own loop of searching, judging and refining.
• Citation agent (or a synthesis and validation step). A separate pass compares the draft against the source material and ties each claim to where it came from. Splitting this from the lead agent's writing measurably improves factual accuracy, since the checker isn't the one who produced the claims.

The diagram uses two kinds of arrows. Solid ones carry tasks downward, and dashed ones carry condensed findings upward. The asymmetry is intentional: subagents return a distilled result and not their whole working history, which keeps the lead agent's context from swelling.

The workflow from question to answer

Stepping back from the components, here's the order of events from a user's typed question to the finished answer.

A few steps deserve attention:

• Step 2 (thinking before planning) carries more weight than it seems. The system settles how much effort the query deserves here: a quick fact-check could need one agent and a few tool calls, while a wide-ranging question may call for ten or more subagents with clearly divided duties.
• Step 7 (looping back) separates an agentic system from a fixed pipeline. Nothing is scripted, because the lead agent examines the results and chooses between answering and searching further. The choice is also where things most often break. An agent too reluctant to loop gives thin answers, and one too keen to loop wastes time and tokens hunting for sources that aren't there.
• Steps 8 and 9, citation as its own stage, exist because an agent asked to write an answer and also grade its own sourcing tends to produce confident claims that don't hold up. An independent second pass catches that.

Four ways to arrange multiple agents

Orchestrator and worker is the usual shape but not the only one. Depending on how a task actually breaks apart, one of four general topologies will suit better than the rest.

When it's unclear which to choose, production teams commonly follow a rule of thumb: default to a hierarchy with a supervisor for anything headed to production, and keep network or mesh layouts for exploratory or research work where the flow can't be pinned down beforehand. Mesh designs look elegant on a diagram and are consistently the hardest to debug.

Why it works: token economics

It helps to be exact about why multi-agent systems beat single agents on the tasks they win, because the answer isn't "more agents means more intelligence."

In Anthropic's internal evaluations, a setup with Claude Opus 4 leading and Claude Sonnet 4 subagents beat a single Claude Opus 4 agent by 90.2% on an internal research benchmark. When the analysis looked at the reasons, capacity explained most of it. On a hard search benchmark, token usage alone accounted for about 80% of the variance in performance, and tool-call count and model choice covered most of what remained.

In short, the advantage on breadth-first, information-heavy tasks comes mostly from capacity. Spreading the job over separate context windows gives the system far more total reasoning room than a single window offers, and each subagent compresses what it reads into a short report.

The capacity isn't free. Production data suggests agentic workflows consume roughly four times the tokens of an ordinary chat exchange, and multi-agent workflows about fifteen times. That multiplier should shape whether the architecture is worth using at all, which leads to the next point.

When a multi-agent system is the wrong tool

Most writing about agent architecture skips this part, and it's the one that protects both time and token budget.

The task must split into truly independent pieces. When subtasks lean heavily on one another, dividing them among agents adds coordination overhead and no real parallelism. Separate research questions split well, whereas writing one cohesive function usually doesn't.

Coding is the clearest counterexample. Anthropic's own write-up is blunt: most coding work has fewer parallelizable subtasks than research does, and today's agents aren't yet dependable at coordinating and passing work to each other in real time. Outside benchmarks agree. One academic evaluation found multi-agent coding setups consuming anywhere from 4x to more than 200x the tokens of a comparable single agent, and a separate industry analysis saw multi-agent systems do 39 to 70 percent worse than a single agent on strictly sequential tasks.

Mistakes spread. A wrong assumption in one agent stays a single error. Inside a coordinated system it can travel along handoffs and grow. One analysis estimated roughly 4x amplification with centralized orchestration, and much worse when agents operate independently without coordination.

The payoff has to cover the cost. With a multiplier near 15x, multi-agent designs suit high-value, high-complexity work such as deep research, multi-domain analysis and large refactors. For anything a well-prompted single agent with good tools can finish in one pass, they're overkill.

One quick test applies: when you can't state what each agent would own that the rest don't, the fix is likely a stronger single agent and not additional ones.

Lessons from building them

Anthropic's retrospective on its Research system is among the most candid public accounts of what breaks when a working demo becomes a production multi-agent setup. The most transferable lessons, condensed:

• Prompting is the main lever. Because a prompt steers every agent, small wording changes in how the orchestrator hands out work had an outsized effect on whether subagents repeated each other or left gaps.
• Loose delegation duplicates effort. A brief such as "research the semiconductor shortage" reads as clear yet isn't. In early systems several subagents explored the same angle, since nobody had marked where one task stopped. A good brief gives the goal, the expected output format and the edge of each agent's scope.
• Match effort to the question. One agent and a few tool calls cover simple fact-finding. Comparing two things can use two to four subagents, and a truly open-ended investigation could justify ten or more. Encoding such rules in the orchestrator's prompt guards against overspending and underspending alike.
• Tool descriptions matter as much as tools. An agent choosing among a dozen vaguely described tools picks wrongly more often than expected, and clear, distinct descriptions measurably cut wasted calls.
• Parallel calls hold the real speedup. Running subagents one after another was among the biggest early bottlenecks. Parallelizing both subagent launches and each subagent's own tool calls shortened research time dramatically.
• Evaluate outcomes, not fixed steps. These systems rarely follow the same path twice, even on identical input, so grading against one correct sequence fails. Evaluation should ask whether the result was right and the process reasonable.
• Full production tracing is mandatory. When an agent fails silently midway, only detailed tracing across the run shows whether it chose poor search terms, a poor source or hit a tool failure. Debugging by guesswork doesn't survive past a handful of agents.

A minimal sketch of the pattern

What follows is a stripped-down, framework-neutral outline of orchestrator and worker. Retries, streaming and persistent memory are omitted so the logic's shape is easy to see, and it works as pseudocode for porting to LangGraph, the Claude Agent SDK or a bare API loop.

def run_research(query: str) -> str:
    # 1. Lead agent plans
    plan = lead_agent.think_and_plan(query)
    memory.save("plan", plan)  # survives context truncation

findings = []
    subtasks = plan.subtasks  # explicit objective + boundaries per subtask
    # 2. Spawn subagents in parallel, not sequentially
    results = run_in_parallel([
        subagent.execute(task=subtask, tools=subtask.allowed_tools)
        for subtask in subtasks
    ])
    findings.extend(results)
    # 3. Lead agent decides: enough evidence, or loop again?
    while not lead_agent.has_sufficient_evidence(findings):
        new_subtasks = lead_agent.refine_plan(findings)
        more_results = run_in_parallel([
            subagent.execute(task=t, tools=t.allowed_tools)
            for t in new_subtasks
        ])
        findings.extend(more_results)
    # 4. Synthesize, then verify citations in a separate pass
    draft = lead_agent.synthesize(findings)
    cited_answer = citation_agent.attach_citations(draft, findings)
    return cited_answer

Two details deserve the most attention, and neither tends to appear in toy examples. First is run_in_parallel: calling subagents one at a time quietly throws away most of the speedup. Second is the explicit while loop that re-plans, because one fixed round of subagents can't adapt when the first pass leaves more questions than answers.

Checks before shipping

Before releasing a subagent or multi-agent workflow, run through these points:

• Each subagent has an explicit goal, output format and task boundary, and not just a one-line instruction.
• Subagents run in parallel wherever they're really independent.
• The plan is saved to storage and not only held in the conversation, in case the context gets truncated.
• The research or refinement loop has a defined exit condition, and doesn't just continue until the agent feels satisfied.
• Citation or verification is a separate pass and isn't folded into writing.
• Token budgets are estimated early: about 4x a single chat for one agent and about 15x for a coordinated multi-agent run.
• Evaluation looks at final outcomes and reasonable process, not a single expected path.
• Tracing in production captures what agents decided and which tools they picked, not the raw conversation text, so failures can be diagnosed.
• Deployments allow for agents already mid-run, since not every in-flight agent will be on the new prompt version.
• Someone has asked whether the work genuinely splits into independent parts before multiple agents are used at all.