Appearance
12.10.7 — Multi-Agent Systems
Cartwise's logistics team wanted to review its twelve courier partners before renewing contracts: on-time delivery rates in each region, damage and loss complaints, price changes, and what customers say about each one. A product manager sketched the solution on a whiteboard as a team of agents: a Researcher that gathers data, an Analyst that compares, a Writer that drafts the report, a Critic that reviews it, and a Manager that coordinates them all, each with a job title, a personality and a chat channel to talk to the others.
It is an appealing picture, because it mirrors how a human team would do the work. It is also, in that form, usually a mistake. This page explains why, and then explains the specific situations where several agents genuinely do better than one, including this courier review, which ended up as a multi-agent system of a very different shape from the whiteboard.
1. What a multi-agent system is
A multi-agent system runs more than one agent loop, each with its own context, instructions and tools, and passes work between them. Three shapes cover almost everything you will meet.
In lead and subagents, a lead agent breaks a task into parts and hands each part to a subagent as a written brief. Each subagent works in its own fresh context, then sends back a short report, and the lead combines the reports. This is the orchestrator-workers pattern of 12.10.6, except that each worker is a full agent loop with its own tools rather than a single call.
In a hand-off, one agent passes the whole conversation to another, which takes over: a triage agent recognises a refund request and hands it to the refund specialist, which may later hand it to a delivery specialist. Only one agent is active at a time. This is close to the routing of 12.10.6, done mid-conversation instead of only at the start.
In peers, sometimes called a swarm, agents message each other freely, each deciding whom to talk to. It is the most flexible shape, and the hardest by far to make reliable.
2. What several agents cost
Every reason to be careful comes from one fact: agents can only share what they write down for each other. A single agent has one context, where everything it has seen and decided sits side by side. Split the work across agents and each has only its own context plus whatever messages were passed to it. Five costs follow.
Context is lost at every hand-over. The lead knows the customer said the parcel "went to the wrong building again"; the brief it writes for a subagent says "investigate order 4471's delivery". The word again, and everything it implies, is gone. Walden Yan of Cognition, whose company builds a coding agent, made this the first of two principles in a widely read June 2025 essay titled Don't Build Multi-Agents: agents need the whole context, not a summary of their piece.
Each agent makes decisions the others cannot see. His second principle is that every action carries hidden decisions. His example: split "build a Flappy Bird game" into "build the background with pipes" and "build the bird", and one subagent builds a background in the style of Super Mario while the other builds a bird that looks and moves nothing like Flappy Bird's. Each did its part well. The parts do not fit, because neither could see the choices the other made.
Errors multiply across agents too. The p^n arithmetic of 12.10.1 applies to agents chained together: two agents that each get their part right 95% of the time produce a correct whole about 0.95 \times 0.95 \approx 90\% of the time, before counting the errors introduced by passing work between them.
Tokens multiply. Each agent has its own instructions, tools and history, and each re-reads its own context on every step. Anthropic, describing its own multi-agent research system in June 2025, reported that agents typically use about 4 times the tokens of a chat, and its multi-agent system about 15 times.
Debugging gets much harder. One agent's trace is a single story to read. Five agents messaging each other produce five interleaved stories, and a bad final answer could have started in any of them. Peer agents add a failure of their own: two agents passing a task back and forth ("over to you", "no, this is yours") until a step limit stops them.
The whiteboard team pays all five costs for roles that one agent could play in turn. The "Researcher, Analyst, Writer, Critic" split mostly divides a single line of thought into pieces that then have to be stitched back together.
3. When several agents pay
Against those costs, three situations reliably come out ahead.
Wide reading in parallel
Some tasks are wide: many independent pieces that can each be researched without knowing about the others. The courier review is like this. What Courier A's on-time rate was in Chennai has nothing to do with Courier B's damage complaints in Pune. A single agent would research twelve couriers one after another, its context filling with all twelve sets of findings. A lead agent can instead send twelve subagents off at once, each with a fresh context devoted to one courier, and receive twelve short structured reports.
This is the shape where Anthropic's numbers come from. Its research system, with Claude Opus 4 as the lead and Claude Sonnet 4 subagents, scored 90.2% better than a single Claude Opus 4 agent on its internal research evaluation, and running subagents in parallel cut research time by up to 90% on complex questions. The same report found that how many tokens the system spent explained about 80% of the differences in its performance on a public web-research benchmark. Much of the benefit of several agents is simply that they let a task use more total reading than one context window could hold.
Keeping heavy reading out of the main context
A subagent is also a way to manage context, as 12.10.5 noted. "Read these 40 old tickets and tell me which mention the wrong building" might take 80,000 tokens to do and 200 tokens to answer. Done by a subagent, the 80,000 tokens never enter the main agent's context; only the answer does. Coding agents use this constantly: a subagent searches a large codebase and reports the three relevant files.
Separating untrusted reading from powerful action
The third reason is security. An agent that reads untrusted text, such as customer emails, supplier documents or web pages, can be manipulated by instructions hidden in that text, the prompt injection of Chapter 12.14.1. If the same agent can also issue refunds, a hidden instruction can turn into a refund. The defence is to split the work:
The reader agent has no tools at all, so whatever the email says, the worst it can do is write odd values into the fields. Code checks the fields: the order ID must exist and belong to this customer, and issue must be one of the allowed values. The actor agent, which holds the refund tools, never sees the email's text, only the checked structure, so an instruction hidden in the email has no route to a tool. This is a practical form of what is called the dual LLM pattern, from a 2023 proposal by the programmer and writer Simon Willison. His original is stricter still: the privileged model never sees even the extracted values, only placeholders such as $VAR1, which plain code fills in when an action runs. Either way, it is one of the few defences against prompt injection that works by design rather than by hoping the model notices.
4. Two views, one rule
The Cognition essay and Anthropic's research write-up were published a day apart in June 2025 and seem to disagree: one says don't build multi-agent systems, the other reports a 90% gain from one. They are describing different kinds of task, and together they give a clear rule.
Research is mostly reading. The pieces are independent, the subagents' outputs are reports rather than actions, and a mismatch between two reports is something the lead can notice and resolve. Building software is mostly writing. The pieces depend tightly on each other, every action embeds decisions the other pieces must match, and a mismatch is a broken program.
So: split work across agents when the parts are independent and mainly involve reading; keep work in one agent when the parts depend on each other and involve making things. The courier review is reading twelve independent things, so it splits. The refund agent decides and acts on one case, so it stays a single agent. A coding agent stays single for its edits, and may still send subagents to search the codebase, which is reading.
5. Building a lead and its subagents
When the shape does fit, a handful of practices decide whether it works. Cartwise's courier review shows them in code.
The lead agent gets one special tool, delegate, which starts a subagent with a written brief. The quality of that brief decides the quality of the subagent's work, so the tool's schema forces a complete one:
python
DELEGATE = tool(
"delegate",
"Hand one research question to a worker agent with its own tools and a fresh "
"context. Call this several times in the same turn to run workers in parallel. "
"Workers know nothing except what you write in the brief.",
objective={"type": "string", "description": "the one question to answer"},
output_format={"type": "string", "description": "exactly what to return, e.g. a table's columns"},
sources={"type": "string", "description": "where to look, and where not to"},
boundaries={"type": "string", "description": "what is out of scope, and who covers it"})Each of the four fields prevents a failure Anthropic described in its own system. Without a clear objective, subagents interpreted vague tasks differently and duplicated each other's work. Without an output format, the lead received twelve reports in twelve shapes that it could not compare. Without guidance on sources, subagents wasted effort on poor ones. Without boundaries, two subagents researched the same thing while a third topic went uncovered. Here is a brief for one courier:
- Objective: "Courier A's on-time delivery rate by region, January–September 2026."
- Output format: "A table: region, on-time %, shipments, source."
- Sources: "Our deliveries database first, then the courier's published reports. Not forums."
- Boundaries: "Only the on-time rate. Pricing and complaints are covered by other workers."
The subagent itself is an ordinary agent loop, like the one in 12.10.2, with its own context and limits:
python
import asyncio
from anthropic import AsyncAnthropic
aclient = AsyncAnthropic()
WORKER_SYSTEM = """You research one question for a lead analyst. Use your tools to find
evidence, then answer in exactly the format requested. Stay inside the boundaries you
are given. Say clearly what you could not find; never fill gaps with guesses."""
async def run_worker(brief: dict, max_steps: int = 15) -> str:
messages = [{"role": "user", "content": "\n".join(f"{k}: {v}" for k, v in brief.items())}] # (1)
for _ in range(max_steps): # (2)
r = await aclient.messages.create(
model="claude-sonnet-5-5", max_tokens=4096, # (3)
system=WORKER_SYSTEM, tools=WORKER_TOOLS, messages=messages)
messages.append({"role": "assistant", "content": r.content})
if r.stop_reason != "tool_use":
return "".join(b.text for b in r.content if b.type == "text") # (4)
calls = [b for b in r.content if b.type == "tool_use"]
messages.append({"role": "user", "content": list(
await asyncio.gather(*[run_worker_tool(c) for c in calls]))})
return "Stopped at the step limit; the findings above are incomplete." # (5)
async def run_lead_tools(calls) -> list:
async def one(call):
if call.name == "delegate":
out = await run_worker(call.input)
else:
out = await run_lead_tool(call)
return {"type": "tool_result", "tool_use_id": call.id, "content": out}
return list(await asyncio.gather(*[one(c) for c in calls])) # (6)Line (1) starts the worker's context with nothing but the brief: it knows only what the lead wrote, which is why the brief must be complete. Line (2) gives every worker its own step limit, so one stuck worker cannot consume the whole budget. Line (3) runs workers on a cheaper model than the lead, matching the system Anthropic described, where planning and combining need the strongest model and focused research does not. Line (4) returns only the worker's final answer, which is all that enters the lead's context; the worker's tool results, often tens of thousands of tokens, stay behind. Line (5) makes an incomplete result say so, so the lead does not treat a partial answer as a full one. Line (6) is where the parallelism happens: when the lead asks for twelve delegate calls in one turn, they all run at once, and their results return together in one message.
Four further rules complete the design. Scale the effort to the question: Anthropic's system was told that a simple fact needs one agent and a few searches, a comparison two to four subagents, and only broad research more than ten. Without such rules, models tend to over-delegate. Subagents do not start their own subagents, which keeps the depth fixed and the cost bounded. The lead checks what comes back, comparing reports for contradictions and gaps before writing anything, because a subagent's confident report is still one agent's unchecked work. And the whole system is traced as a tree, each subagent's run linked to the lead's step that started it, so a wrong number in the final report can be followed back to the subagent and the source it came from (12.10.9).
For the courier review, the lead planned twelve briefs plus three cross-cutting ones (pricing changes, complaint trends, contract terms), received fifteen structured reports, noticed that two couriers' on-time figures came from different date ranges, sent one follow-up brief to fix that, and wrote the comparison. The whole run used several times the tokens a single agent would have, which for a once-a-year review worth lakhs of rupees in contract terms was an easy trade.
6. Hand-offs between specialists
The second reliable shape, the hand-off, suits conversations that move between areas needing different tools and rules. In "Ask Cartwise", a triage step decides whether a message is about a refund, a delivery or an account, and the conversation passes to the specialist for that area, with its own prompt and its own small tool set. The main design rule is about context: the whole conversation goes with the hand-off, not a summary, so the specialist knows everything the customer has already said. When the conversation changes subject, the specialist hands it on, again with everything. A cap on hand-offs per conversation stops two specialists passing a customer back and forth, which customers notice and hate.
What the interviewer will push on
"When would you use multiple agents?" They are checking whether you reach for multi-agent designs by default. The strong answer names the three cases (wide independent reading in parallel, keeping heavy reading out of the main context, isolating untrusted input from powerful tools) and says that otherwise one agent with good tools is better.
"What goes wrong with multi-agent systems?" Context lost at hand-overs; hidden decisions that conflict (the Flappy Bird example); errors multiplying; token use several times higher; hard debugging; agents passing tasks back and forth. Citing the two June 2025 write-ups and reconciling them shows you have read beyond the slogans.
"How do you write a good delegation?" Objective, output format, sources, boundaries, and a step budget; workers start with nothing but the brief, so it must be complete.
"How does the dual LLM pattern defend against prompt injection?" The agent that reads untrusted text has no tools and outputs only a checked structure; the agent with tools never sees the raw text. The injection can corrupt field values, which code validates, but has no path to an action.
"Would you build a coding assistant as several agents?" Edits stay in one agent because they depend tightly on each other; subagents are useful for searching and reading. That distinction, reading versus writing, is the answer they are hoping for.
Something to volunteer: much of the gain from parallel subagents is simply more total reading. Anthropic found token spend explained about 80% of performance differences on a research benchmark. So a multi-agent design is partly a way to spend more compute on a problem, and it should be justified by the value of the answer, like any other cost.
Recall
- A multi-agent system runs several agent loops with separate contexts. Shapes: lead and subagents (briefs down, short reports up), hand-offs between specialists (one active at a time), and free-talking peers (rarely reliable).
- Agents share only what they write down, so: context is lost at hand-overs, hidden decisions conflict (Flappy Bird), errors multiply, tokens multiply (about 4× for an agent and 15× for Anthropic's multi-agent system, compared with chat), and debugging is harder.
- Several agents pay for wide, independent reading in parallel (Anthropic's research system: +90.2% over a single agent), for keeping bulk reading out of the main context, and for isolating untrusted input (the dual LLM pattern: a tool-less reader feeds a checked structure to the actor).
- The rule: split independent reading across agents; keep interdependent making in one agent.
- Build it well: complete briefs (objective, output format, sources, boundaries), per-worker step limits, cheaper worker models, only final answers returned, parallel delegation, effort scaled to the question, no nested subagents, a lead that checks, and traces as a tree. Hand-offs carry the whole conversation and are capped.
Self-test: Why did the Flappy Bird split fail even though each subagent did its job well? In the dual LLM pattern, what is the worst a hidden instruction in the email can achieve? Which of these should be split across agents: comparing twelve couriers, or changing the checkout code in five files?
Next: 12.10.8 Guardrails, Approval and Sandboxing — every page so far has relied on controls in the harness; the next page collects them into a complete safety design: checks on what goes in and comes out, approval for what matters, and sandboxes for agents that run code.