Multi-agent systems

The big idea

A single agent is one model in one loop with one context window. A multi-agent systemA system in which several model instances, each running its own loop with its own prompt, tools and context, work on parts of one task and pass results between them. runs several of them: typically a lead that plans and several sub-agents that each take a piece of the work, or a chain of specialists that pass a conversation along.

Think of a newsroom. An editor takes a big story, splits it into angles and sends three reporters out at once. Each reporter reads dozens of sources but files only a few hundred words. The editor never sees the reporters' notebooks, just the filed copy, and writes the final piece. That is faster and covers more ground than one reporter working alone. It also costs three salaries, and if two reporters interview the same person or make different assumptions, the editor has to sort it out.

That is the whole trade. Multi-agent systems buy breadth, parallel speed and small, focused contexts. They pay in tokens, coordination and new ways to fail. They win on broad tasks that split into independent parts, and lose on tasks where every part depends on decisions made in the others.

How it works

Orchestrator with sub-agents

The most common shape is the orchestrator-workers pattern from Workflows vs agents: the patterns , where every worker is itself an agent. The lead decides at run time how to split the task, starts sub-agents (usually through a tool, so "spawn a sub-agent" is just another function call from Function calling and tool use ), waits for their results and merges them.

Two things make this work. First, each sub-agent has a fresh contextA sub-agent starts with an empty context holding only its own system prompt, tools and brief, not the lead's history., so it can read a lot without filling the lead's window, and returns only what matters. This is the context benefit from Context engineering : the lead sees ten summaries, not a thousand pages. Second, independent sub-agents can run at the same time, so wall-clock time is set by the slowest one, not the sum.

The brief is the whole interface. A sub-agent knows nothing except what the lead writes, so a good brief states the objective, the output format, which tools and sources to use, and clear task boundaries. "Research the chip shortage" sent to three sub-agents gets you three overlapping searches.

Handoffs between specialists

The second shape is a handoffTransferring control of a conversation from one agent to another, which then talks to the user directly with its own instructions and tools.. Instead of a lead that stays in charge, control moves: a triage agent reads the request and transfers the whole conversation to a billing agent or a technical-support agent, which then owns it.

Handoffs are usually exposed to the model as tools, so routing is again just a function call. Each specialist gets a short prompt and only the tools it needs, which keeps prompts focused and makes permissions easy to scope. The question you must answer for every handoff is what the next agent sees: the full history, a filtered version, or a summary.

Costs multiply

Every agent pays for its own loop. Each sub-agent re-sends its system prompt, tool definitions and brief on every call, spends a few calls orienting itself, and accumulates its own history. The lead adds a planning call and a merging call. And the reason teams build multi-agent systems is usually to do more work, so each sub-agent gets a budget of its own.

Anthropic reports that in its data, agents use about 4 times more tokens than chat interactions, and multi-agent systems about 15 times more. So if a chat answer costs 5,000 tokens, an agent run on the same scale costs about 20,000 and a multi-agent run about 75,000. That is fine for a research report someone would otherwise spend hours on, and wasteful for a question one search can answer.

How teams of agents fail

All the single-agent failure modes from The agent loop (ReAct) still apply, once per agent, plus new ones that only exist between agents:

• Bad decomposition: duplicated work, gaps nobody covers, or many sub-agents spawned for a question that needed none.
• Lost context: a sub-agent misreads a vague brief, because it never saw the conversation that explains it.
• Conflicting decisions: two sub-agents make incompatible assumptions, such as different data formats or visual styles, and the merge step inherits both.
• The telephone game: facts are distorted as they pass through summaries, then a summary of summaries.
• Compounding errors: if the answer needs all five parts right and each part is right 90 percent of the time, all five are right only about 59 percent of the time.
• Nobody checks: each agent assumes another verified the result.

Try it

1. Start with 0 sub-agents, then try 1, 2, 4 and 8 on the research task. Why is 1 sub-agent worse than none, and what happens to the wall time and the largest context as you add more?
2. Set 8 sub-agents and switch the briefs to "vague". How many tool calls are wasted, and how does the token ratio change?
3. Switch to "build 8 parts of one app". With detailed briefs, how many dependencies cross between sub-agents at 2, 4 and 8? Now make the briefs vague.

The same cost model in code, including the case the lab leaves out: each sub-agent given its own budget of 15 tool calls.

# Token and time cost of one agent vs an orchestrator with k sub-agents.
# Illustrative numbers: 8 subtasks x 3 tool calls; each result adds 2,000 tokens to the context.
B, R, ORIENT, PER, SUM, SEC = 4000, 2000, 2, 3, 500, 10   # prompt, result, calls, summary, seconds

def agent(calls):
    """Tokens sent by one agent loop: the whole growing history is re-sent on every call."""
    return calls * B + R * calls * (calls - 1) // 2

def run(k, vague=False, budget=None, n=8):
    if k == 0:
        c = ORIENT + n * PER                             # one agent does everything in sequence
        return agent(c), c * SEC, B + R * c
    sizes = [n // k + (i < n % k) for i in range(k)]     # split subtasks across sub-agents
    calls = [budget or ORIENT + s * PER + (PER if vague and i else 0) for i, s in enumerate(sizes)]
    tokens = sum(agent(c) for c in calls)
    tokens += (B + 500) + (B + k * SUM)                  # lead: plan call, then merge summaries
    return tokens, 20 + max(calls) * SEC + 30, B + R * max(calls)   # sub-agents run in parallel

base = run(0)[0]
print(f"{'setup':<30}{'tokens':>10}{'x one':>7}{'time':>7}{'max ctx':>9}")
for k, vague, budget in [(0, 0, None), (1, 0, None), (4, 0, None), (8, 0, None),
                         (8, 1, None), (4, 0, 15), (8, 0, 15)]:
    t, s, peak = run(k, vague, budget)
    name = "single agent" if k == 0 else f"{k} sub-agent{'s' * (k > 1)}"
    name += ", vague briefs" if vague else f", 15 calls each" if budget else ""
    print(f"{name:<30}{t:>10,}{t / base:>7.2f}{s:>6}s{peak:>9,}")

# Error compounding: the answer needs every sub-agent's part to be right
for k in (2, 3, 5, 8):
    print(f"{k} parts, each right 90% of the time -> all right {0.9 ** k:.0%}")

setup                             tokens  x one   time  max ctx
single agent                     754,000   1.00   260s   56,000
1 sub-agent                      763,000   1.01   310s   56,000
4 sub-agents                     362,500   0.48   130s   20,000
8 sub-agents                     332,500   0.44   100s   14,000
8 sub-agents, vague briefs       668,500   0.89   130s   20,000
4 sub-agents, 15 calls each    1,090,500   1.45   200s   34,000
8 sub-agents, 15 calls each    2,172,500   2.88   200s   34,000
2 parts, each right 90% of the time -> all right 81%
3 parts, each right 90% of the time -> all right 73%
5 parts, each right 90% of the time -> all right 59%
8 parts, each right 90% of the time -> all right 43%

Splitting fixed work can even save tokens, because short contexts mean less history re-sent on every call. But as soon as each sub-agent gets its own budget, cost scales with the number of agents: 8 sub-agents at 15 calls each cost almost 3 times the single agent. The last lines show why a merge step needs checking: with 8 parts each right 90 percent of the time, all 8 are right only 43 percent of the time.

Going deeper

When it pays off

Anthropic's research system is the clearest published case for multi-agent designs. On its internal research evaluation, a lead agent with sub-agents beat a single agent using the same lead model by 90.2 percent, mainly on breadth-first questions such as finding the board members of every company in a sector, where the single agent searched slowly and sequentially. On the BrowseComp browsing benchmark, three factors explained 95 percent of the variance in performance, and token usage alone explained 80 percent. Multi-agent systems work, in their words, mainly because they help spend enough tokens to solve the problem.

The same post is just as clear about where they do not fit: tasks where all agents need the same context or have many dependencies between them. It notes that most coding tasks have fewer truly parallel parts than research, and that agents were not yet good at coordinating and delegating to each other in real time.

The case for one agent

Cognition's "Don't Build Multi-Agents" argues the other side with two principles: share full context, meaning whole agent traces rather than single messages, and remember that actions carry implicit decisions, so agents that cannot see each other's work will make conflicting ones. Its example is a Flappy Bird clone split into "background" and "bird" subtasks that come back in two different visual styles. Its default is a single-threaded agent, with a model that compresses history for very long tasks. Both posts agree on the deciding factor: how much the parts depend on each other.

Making it work

• Scale effort to the task. Anthropic put explicit rules in the lead's prompt: simple fact-finding needs one agent with 3 to 10 tool calls, a direct comparison 2 to 4 sub-agents with 10 to 15 calls each, and complex research more than 10 sub-agents with clearly divided work. Early versions spawned 50 sub-agents for simple queries.
• Write briefs like task tickets. Objective, output format, tools and sources, boundaries.
• Pass references, not copies. Let sub-agents write large outputs to files or a store and return a pointer, which avoids the telephone game and keeps the lead's context small.
• Checkpoint and resume. A long multi-agent run should restart from where it failed, not from the beginning ( Making agents reliable ).
• Evaluate outcomes and the process. Agents take different valid paths to the same answer, so judge the end result against a rubric and trace each run to see why it failed ( LLM-as-judge ).

Research on failures backs this up. A study of more than 1,600 annotated traces from 7 multi-agent frameworks found that performance gains on popular benchmarks were often minimal, and sorted 14 failure modes into three groups: system design issues, misalignment between agents, and weak task verification.

Trade-offs

Common mistakes

• Reaching for multiple agents because the diagram looks impressive, before a single agent with good tools has been tried and measured.
• One-line briefs, so sub-agents duplicate each other or solve the wrong problem.
• Splitting tightly coupled work, such as parts of one codebase, across agents that cannot see each other's decisions.
• No budget per agent and no cap on how many sub-agents the lead may start.
• Trusting the merged answer without verification, or evaluating only the final answer and never reading the traces.

In the wild

Check yourself

Recap