28  Multi-Agent Patterns

Chapter status: drafted. The cost model is arithmetic, with its constants taken from measurements earlier in the book — Chapter 27’s 89 tokens per tool definition and Chapter 23’s loop accounting — rather than from estimates. It answers a token question and deliberately not an accuracy question; the difference is the point of Section 28.4. Software: Python 3.14.5.

Learning objectives. After this chapter you can:

• choose a topology from the shape of the work rather than from fashion;
• compute whether splitting work across agents saves context or costs it;
• recognise the shared-state problems that make these systems fail;
• state the case for a single agent, and measure against it before adding one.

28.1 The single agent is the baseline

Multi-agent architectures are the most over-applied idea in this part of the book, and the reason is that they are interesting. A coordinator delegating to specialists is a satisfying diagram. A while-loop is not.

So this chapter starts where Chapter 23 ended: one agent with good tools is the thing to beat, and adding a second one has to be justified by a measurement rather than a diagram. There are exactly three justifications that survive contact with production, and all three are structural rather than aesthetic:

1. Context. The work produces more material than one window should hold. This is arithmetic, and Section 28.3 computes it.
2. Parallelism. Independent subtasks can genuinely run at once, and the wall-clock saving is real rather than imagined.
3. Isolation. Different subtasks need different tools, different permissions, or different models — and mixing them makes each worse.

Anything else — “the task is complex”, “it has stages”, “different expertise” — is usually a task a single agent handles with a longer prompt and a few more tools. Usually, not always: an expertise argument that turns out to mean a different model, a different tool set or a different permission set is justification 3 under another name, and that one is real. What does not survive is expertise as a description of the work rather than of the runtime. Build the single agent, measure it, and let the split earn its place.

What we will look at. First the four shapes a split can take, and the one heuristic that chooses between them: independent reads are easy to parallelise, and concurrent writes need explicit ownership, isolation or conflict resolution. Then the arithmetic behind the first justification, often asserted without an explicit cost model — how much material the work has to produce before three agents cost less than one. Then what that saving costs you, which is information rather than money. Then shared state, where these systems actually break, and the queue discipline that stops a failing task billing you forever. And finally the frameworks, each of which is a commitment to a control flow before you know which one you need.

28.2 Topologies, and what each is for

Suppose one of the three conditions holds. There are four shapes the split can take, and they are not interchangeable — each is good at a different kind of work and fails in a different way.

Four topologies

topology	shape	when it fits	what it costs
Hub-and-spoke (also called supervisor or orchestrator-worker)	one coordinator, N specialists, no lateral links	the default when you split at all. The coordinator is a context firewall: raw observations reach it only through a specialist’s report	the coordinator becomes a bottleneck and a single point of failure — and the firewall is only as strong as the discipline in that report’s format, since a specialist that pastes a stack trace has removed it
Sequential	a pipeline of agents, each consuming the last	stages with genuinely different requirements — extract, then verify, then write	it is a pipeline. Ask whether it needs agents at all
Parallel fan-out	N specialists on independent slices, results merged	read-heavy work over separable inputs: many documents, many repositories	merging is a real design problem, not a join
Loop / debate	agents critique or refine each other’s output	narrow: where an independent check genuinely catches things	expensive, and a critic that sees nothing new rarely helps: Section 24.2 measured recovery at 1.7% from feedback that carried no new information

The useful heuristic is one sentence: read-only subtasks are usually easy to parallelise; concurrent writes need explicit ownership and conflict handling. Ten agents reading ten documents approaches ten times faster — approaches, because that assumes equal-sized work, enough concurrency at the provider, and a merge step you are not counting. Ten agents editing one codebase is a distributed-systems problem you did not intend to take on, and Section 28.5 is about why. Writes can be split when ownership is disjoint — one agent per file, per record, per partition — which is the same fix a database would make you apply.

One more piece of arithmetic for the parallelism justification: a fan-out finishes when its slowest specialist finishes, and the coordinator’s own calls come on top. Ten slices where one is five times larger than the rest buy you nothing like a tenfold speed-up.

A note on debate. The best-known loop is multi-agent debate: several agents answer the same question, read each other’s answers, and revise over a few rounds (Du et al., 2023). Before paying for it, run the cheap control from Section 10.4: sample the same model the same number of times and take a majority vote, at the same token budget. Choi et al. (2025) found that voting alone explains most of the gain usually credited to debate.

Handoff or delegation?

Two things get called the same thing, and they have different failure modes.

Delegation — the coordinator keeps the conversation, sends a subtask, gets a result back. The specialist is a function call with a model inside it, and it should be stateless: everything it needs arrives in the request. This is the pattern that behaves.

Handoff — the coordinator passes the conversation itself to another agent, which now owns it. Cheaper, because no coordinator call sits between the two, and it loses the firewall: whatever the second agent does is now in the same transcript, and there is no coordinator left to summarise or reject it.

Handoff — a coordinator passes the conversation itself to another agent, which now owns it; unlike delegation, nothing is left to summarise or reject what the second agent does. ↩︎

Prefer delegation with stateless specialists. A specialist that remembers previous calls is a distributed cache with no invalidation story: it may answer from stale memory, and nothing decides when that memory should be thrown away. Handoff has one honest use — when the next agent must talk to the user directly, as when a triage agent routes a customer to a billing agent. There the conversation is the work, and passing it on is the point.

28.3 Does splitting actually save context?

The first justification — context — is arithmetic, so here is the cost model it usually lacks.

Write n for the number of steps (one model call each), F for the fixed prefix every call carries (system prompt plus tool definitions), and o for the tokens one observation adds. A single agent re-sends its whole transcript on every model call, so call i costs F + i·o and the total has a quadratic term: n·F + o·n(n−1)/2. The linear part is the fixed prefix paid once per call and the quadratic part is the accumulated observations — which is already the answer to why the split loses on short work with small results, where the linear term still dominates.

A coordinator with specialists fights it by paying a fixed cost in each agent — system prompt plus tool definitions, which Chapter 27 measured at 89 tokens per tool — in exchange for two things: each specialist starts from a clean window, and the coordinator sees summaries instead of raw results.

Take the fixed cost as 1,450 tokens — fourteen tool definitions at 89 each is about 1,250, plus a system prompt of about 200 — and a specialist’s report back as 120 tokens. Here is the whole model, because every conclusion below depends on assumptions that are easier to argue with when they are written down:

all costs are prompt tokens; output tokens are not counted

  F = 1,450   fixed prefix per agent (system prompt + 14 tool defs)
  R =   120   a specialist's report back to the coordinator
  o           tokens returned by one observation
  n           total steps of work

  single = sum_{i=0}^{n-1} (F + i*o)       = n*F + o*n(n-1)/2
  three  = 3 * sum_{i=0}^{n/3-1} (F + i*o) + sum_{i=0}^{2} (F + i*R)

Five assumptions, and all five flatter the split:
  - the whole transcript is re-sent every call; no truncation, no compaction
  - no prompt caching (see below, where it changes three of the nine cells)
  - the n steps divide into three disjoint thirds with no duplicated work
  - the coordinator makes exactly three calls whatever n is, never re-plans,
    and never runs a final synthesis - a constant 4,710 tokens in every cell
  - output tokens are free and every agent is charged at the same rate

The three observation sizes below bracket what tools actually return: ~200 tokens is a list of search hits, ~800 a function body or a small API response, ~3,000 a file read or a fetched page.

Carry those five assumptions with every ratio you quote from the table. In particular, the coordinator never runs a final synthesis and output tokens are free — a real system pays for both, and the synthesis reads three reports, so the split’s true cost is above what is printed. These are modelled numbers, not a measured end-to-end saving.

One more assumption hides in the word step: each step is its own model call. Chapter 23 measured a model batching five independent lookups into 2.0 model calls. When that happens, n counts model calls rather than lookups, the single agent’s quadratic term shrinks, and the case for splitting is weaker still. The table is for work whose steps are genuinely sequential.

 steps  obs size   single agent   3 specialists    ratio
     6       200         11,700          14,010    1.20x
     6       800         20,700          15,810    0.76x
     6     3,000         53,700          22,410    0.42x
    12       200         30,600          25,710    0.84x
    12       800         70,200          36,510    0.52x
    12     3,000        215,400          76,110    0.35x
    24       200         90,000          56,310    0.63x
    24       800        255,600         106,710    0.42x
    24     3,000        862,800         291,510    0.34x

And the crossover — how large an observation has to be before three specialists become cheaper than one agent:

    6 steps  ->    393 tokens per observation
   12 steps  ->     98 tokens per observation
   24 steps  ->     25 tokens per observation

Splitting pays on volume, not on difficulty

One cell is red, and it is the cheap corner — short work with small results, which is exactly where many multi-agent systems get built. Both axes matter, but the step axis matters more than it looks: the break-even observation size falls with roughly the square of the step count, so doubling the steps cuts it by about four (393 → 98 → 25). At the same total material — 4,800 tokens — twenty-four steps of 200 reach 0.63× while six steps of 800 reach only 0.76×.

Two readings, and both matter.

On short work with small results, splitting is more expensive. Six steps returning 200 tokens each costs 1.20× as a three-agent system, because you paid the fixed per-agent cost three extra times to save transcript you never accumulated. This is the case people build anyway, and it is the case where the diagram is doing the arguing.

On long work with large results, splitting wins enormously. Twenty-four steps returning 3,000 tokens each is 862,800 tokens as one agent and 291,510 as three — 0.34×, a two-thirds saving. The mechanism is the quadratic: the single agent carries every observation through every subsequent call, and the specialists do not.

The dial is not how complex your task is. It is how much material it produces. More exactly, it is material multiplied by how many later calls have to carry it. Long transcripts with big observations are what splitting is for. Short ones are not.

Two assumptions that decide the whole table

The one doing all the work is that the n steps divide into three disjoint thirds. Real specialists read the same document twice, a coordinator splits the task badly, one specialist rediscovers what another found. Call the duplication factor d, so each specialist takes d·n/3 steps. The headline cell moves like this:

  24 steps, 3,000-token observations

    d = 1.0 (printed)     291,510 against 862,800      0.34x
    d = 1.5                650,910 against 862,800      0.75x
    d = 2.0              1,154,310 against 862,800      1.34x

At d = 2 — each specialist doing twice its fair share — there is no observation size at any step count that makes splitting cheaper. Even d = 1.5 puts four of the nine cells against the split, three more than the printed table. Measure your duplication before you trust the ratio; it is the parameter the conclusion actually hangs on, and it is not in the table.

The second is prompt caching, and it is not a footnote. Every turn of an agent loop re-sends the previous turn’s prompt as an exact prefix and adds a little at the end, which is the pattern caching is built for — and the single agent, with the longest repeated prefix, is the biggest beneficiary. In the model below, each call reads everything the previous call sent from the cache and writes only its new tokens. Charging cached reads at 0.1× and cache writes at 1.25× of the base rate, which is a common published schedule:

  steps / obs      raw ratio    with caching
     6 /   200        1.20x        2.27x
     6 /   800        0.76x        1.35x   <- flips
     6 / 3,000        0.42x        0.80x
    12 /   200        0.84x        1.60x   <- flips
    12 /   800        0.52x        1.00x   <- level (1.004x)
    12 / 3,000        0.35x        0.75x
    24 /   200        0.63x        1.09x   <- flips
    24 /   800        0.42x        0.76x
    24 / 3,000        0.34x        0.65x

The crossovers move from 393 / 98 / 25 tokens per observation to 1,643 / 810 / 268 — four to eleven times further out — three of the nine cells flip outright, and a fourth ends level, a hair on the wrong side. Caching does not shave the saving; on short work it removes it. Chapter 27 makes the same point from the other end, that tool definitions are the most cacheable thing in a context. If your provider caches, the single agent is a much stronger baseline than the first table admits — provided its calls come quickly enough, since cached prefixes typically expire after a few idle minutes.

28.4 The saving is paid for in information

That table answers a token question. It says nothing about whether the answer is still right, and this is where multi-agent architectures actually fail.

The coordinator sees a summary, not the observations. That is the whole mechanism of the saving — and it means the coordinator is reasoning about a lossy compression of what the specialist saw. Anything the specialist did not think worth reporting is gone, and nothing downstream can recover it. Chapter 14 measured what summarisation does to faithfulness; the same applies when the summariser is your own subagent and the reader is your own coordinator.

Errors compound across a boundary you cannot see through. A specialist that is 90% right hands a confident report to a coordinator that has no way to check it. Three such specialists give 0.9³ — about 73% — if their errors are independent and all three have to be right. Neither is guaranteed: three specialists running the same model over the same corpus fail in correlated ways, and errors that fully overlap put the system back at 90%. Errors that never coincide pull it the other way, down to 1 − 3 × 10% = 70%, which is the floor under any dependence. So the honest figure is not a point but the band [70%, 90%], with independence at 72.9% inside it. Where your system sits in that band you have to measure rather than compute — and the band is wide enough to be the whole decision. Either way it is before the coordinator’s own synthesis — the kind of step where Chapter 23’s single agent broke: tool use was perfect at every step count while accuracy fell from 100% to 40%, so the failure was in combining what came back, not in the calls.

The most visible production system measures the opposite trade, and it belongs here rather than in a link at the end. Anthropic (2025) reports its research system beating single-agent Claude Opus 4 by 90.2% on an internal research eval while spending about 15× the tokens of a chat, with token usage alone explaining roughly 80% of the performance variance on BrowseComp, a web-browsing benchmark. The same post puts a single agent at about 4× a chat, so the multi-agent system spends roughly four times what one agent does. Read that together with the arithmetic above and the two results do not conflict: the split can save context tokens per unit of work done and still cost far more in total, because the agents you added do more work rather than the same work in thirds. Section 28.3 is a saving on the transcript. It is not a saving on the bill.

There is a second lever there that this chapter’s token arithmetic cannot see, and it is probably the bigger one: that system runs an expensive coordinator (Claude Opus 4) over cheaper specialists (Claude Sonnet 4). Cost per token is a dial a single agent does not have, and it belongs in the comparison before the token counts do — along with the fact that output tokens typically cost four to eight times the input rate on current price lists, and are counted as free above.

A specialist’s report is untrusted input. Whatever a specialist read — a web page, a ticket, a PDF — can reach the coordinator through its summary, and the coordinator has no way to tell a finding from an instruction. The context firewall filters volume, not authority. Give reports a fixed schema the coordinator parses rather than reads, and never let a low-permission specialist’s prose decide what a high-permission coordinator writes. That is a confused deputy — a program with high privileges tricked by a less privileged party into using them on its behalf — with a language model in it, and Chapter 36 is where it gets taken seriously.

Debugging gets qualitatively harder. One agent produces one transcript. Five agents produce five, plus the delegation decisions between them, and the question “why did it answer that” now requires reconstructing a distributed trace. Chapter 23’s argument that an agent trades debuggability for open-endedness applies again, one level up and more sharply.

So the honest test before splitting is two-sided:

  does it save tokens?   compute it. The table above is the shape.
  does it stay right?    measure it, against the single agent, on your task.

If you cannot answer the second, you have not evaluated an architecture; you have chosen a diagram.

28.5 Shared state is the hardest part

Everything above assumes specialists only read. The moment two agents can write to the same thing, you have a distributed system, and the ordinary distributed-systems problems arrive without the ordinary distributed-systems discipline.

Four ways shared state fails

problem	how it shows up here
Lost update	two agents read a file, both edit, the second write erases the first. Neither notices, and neither reports an error
Inconsistent read	a specialist reads state another is midway through changing, and reasons confidently from a half-written value
Conflicting conclusions	two agents reach opposite answers from the same data and the coordinator has no rule for choosing — Chapter 26 measured what a model does with contradictions, and it mostly hedges
Non-determinism	the run is not reproducible, so the bug you saw yesterday cannot be recreated today

Those four are the classic distributed-systems problems, and they are the ones your distributed-systems training prepares you for. The ones that actually dominate in practice are not of that kind at all. Cemri et al. (2025) built a taxonomy of fourteen failure modes in three categories from 150 traces labelled by human experts (\(\kappa\) = 0.88 between annotators), then used an LLM judge to label 1,600+ traces from seven multi-agent frameworks. The most frequent modes in their counts appear nowhere in the table above:

The five most frequent ways the agents themselves fail, with their share of all labelled failures (Cemri et al. 2025)

problem	how it shows up here
Step repetition (15.7%)	an agent redoes work already done — the duplication factor d from Section 28.3, observed
Reasoning–action mismatch (13.2%)	an agent’s reasoning says one thing and its next action does another
Unaware of stopping conditions (12.4%)	the agents do not recognise that the task is done, and keep going long after they should have stopped
Disobeying the task specification (11.8%)	an agent ignores a constraint the task stated — a format, a scope, a limit
Missing or incorrect verification (8.2% + 9.1%)	nothing checks the synthesis, or the check passes a wrong answer — and synthesis is the kind of step Chapter 23 found breaking

Two modes that describe this chapter’s argument exactly are rare in those counts: information withholding (0.85%) — a specialist knows something and leaves it out of its report — and ignoring another agent’s input (1.9%). Read that with care: a trace shows what an agent said, not what it failed to say, so a failure of omission is hard to label, and a low count need not mean a rare problem.

The second table has no tidy fix; the paper’s own conclusion is that these failures need more than prompt tweaks. The mitigations for the first table are the boring ones, and they are boring because they work:

• Give each agent its own workspace. A branch, a scratch directory, a transaction. Merge deliberately, at a point you chose.
• Decide the transaction boundary explicitly. Is one delegated subtask atomic, or can it half-succeed? If it can, every side effect needs a compensating action — the saga pattern — because there is no distributed transaction to roll back for you. Chapter 24’s idempotency requirement is the other half of this.
• Make writes single-threaded. One agent — usually the coordinator — owns every mutation. Specialists propose; the owner applies.
• Make tools idempotent, per Chapter 24, because retries are certain and a second create_invoice is not a rounding error.
• Prefer append-only. A log of proposals that someone reconciles beats concurrent mutation of shared state, and it leaves a trace you can debug.
• Name what you are doing. Keeping state as an append-only log of proposals is close to event sourcing; one owner making every change is the single-writer principle; letting each agent work on its own copy and checking for conflicts only at merge time is optimistic concurrency. The literature on all three is decades old and better than anything an agent framework will hand you.

28.6 Queues, and what to do with a poisoned message

The previous section was about two agents reaching for the same state. This one is about the wire between them, which is a decision you have already made even if you did not notice making it.

Direct calls are the default, and they are simple, but they couple the caller’s lifetime to the callee’s: if the specialist crashes or stalls, the coordinator waits or fails with it. A queue decouples them and buys the things queues always buy — backpressure (a slow consumer makes producers wait instead of being flooded), retries, and the ability to restart one side without the other.

Three rules that are ordinary infrastructure practice and get skipped here because the payloads look like conversation rather than messages:

• Bound the retries. A timeout or a rate limit may clear on retry, but an agent task that failed for a real reason — a bad input, a request the model cannot satisfy — will usually fail again, often identically and always expensively: every retry is a fresh model bill. Chapter 23’s step cap, one level up.
• Have a dead-letter queue, and read it. A task that cannot be processed goes somewhere a human looks. Without this, poisoned messages either loop forever or vanish, and both are worse than an alert.
• Make the payload self-contained. A message that refers to state elsewhere — continue the analysis we were doing — cannot be retried or replayed. This is the stateless-specialist rule from Section 28.2, enforced by the transport.

Dead-letter queue — where a task that keeps failing lands so a person reads it, instead of retrying forever or vanishing. ↩︎

28.7 Frameworks, as of 2026

Every framework here opts you into a model of control flow, and that choice matters more than the API. This section will date; check versions.

Six frameworks and their commitments

framework	what it opts you into
LangGraph	the loop as an explicit state machine. Verbose, and the right choice when the control flow deserves to be a diagram you can inspect
OpenAI Agents SDK	a small loop with handoffs and guardrails; the closest thing to Chapter 23’s fourteen statements with production edges added. It also supports delegation, by exposing an agent as a tool
Pydantic AI	typed tools and typed results; strongest when the boundary between agents needs validation rather than prose
CrewAI	roles and tasks as first-class concepts. Fast to a working demo; the abstraction is opinionated about a topology you may not want
AutoGen	conversational multi-agent, with agents talking to each other. Powerful, and the pattern most likely to produce the failures in Section 28.4. Now in maintenance mode: Microsoft points new projects to its successor, Microsoft Agent Framework
Google ADK	agents as deployable services, oriented at operating them rather than prototyping

The advice that outlasts any of them: build the single agent first, with no framework. You will then be choosing between these on the basis of what you already know your control flow needs, rather than adopting someone else’s answer before you have the question.

28.8 Intuition checks

Answer each one before you open it. Two are settled by arithmetic in this chapter — the token model and the way errors compound — and the other four are design decisions it argues for, every one of them cheaper to change before you have built the thing than after.

Note1. When does a task need multiple agents?

When one of three structural conditions holds: the work produces more material than a window should hold, independent subtasks can genuinely run at once, or different subtasks need different tools, permissions or models. “The task is complex” is not on that list — complexity is handled by a longer prompt and better tools. The single agent is the baseline, and the second agent has to beat it on a measurement.

Note2. Does splitting work across agents save tokens?

It depends on how much material the work produces, and the arithmetic is worth running. Six steps with 200-token observations costs 1.20× as three agents — splitting is more expensive, because you pay the per-agent fixed cost three extra times. Twenty-four steps with 3,000-token observations costs 0.34× — a two-thirds saving, because a single agent carries every observation through every later call. The dial is material produced, not difficulty. Then say what the arithmetic assumes: no prompt caching, and no duplicated work between the specialists. Relax either one and the split can stop paying entirely.

Note3. What does the token saving cost you?

Information. The saving exists precisely because the coordinator sees a summary rather than the observations, so it reasons about a lossy compression of what the specialist saw. Errors also compound across a boundary nobody can check: three specialists at 90% give about 73% if their errors are independent and the system needs all three to be right, and anywhere from 70% to 90% depending on how much their errors overlap. All of that is before the coordinator’s own synthesis — combining what came back, which is where Chapter 23’s agent broke.

Note4. Why does write-heavy work not parallelise?

Because concurrent writes make it a distributed system: lost updates where the second write erases the first with no error, inconsistent reads of half-written state, conflicting conclusions the coordinator has no rule to resolve, and non-determinism that makes yesterday’s bug unreproducible. Ten agents reading ten documents can approach ten times faster; ten agents editing one codebase is a problem you did not intend to take on — unless each owns a disjoint part of it.

Note5. Handoff or delegation?

Delegation, with stateless specialists. The coordinator keeps the conversation, sends a self-contained subtask, and receives a result — which preserves the context firewall and makes every specialist retryable. A handoff passes the conversation itself, so the second agent’s output lands in the same transcript with no coordinator left to summarise or reject it, and a specialist that remembers previous calls is a distributed cache with no invalidation story.

Note6. Which framework should you use?

Build the single agent with no framework first. Each of these opts you into a model of control flow — an explicit state machine, roles and tasks, conversational agents — and that commitment matters more than the API. Choosing after you know what your control flow needs is a different activity from adopting someone else’s answer before you have the question.

28.9 Interview questions

On sourcing — the same caveat as Chapter 2. These recur in the two credible open sources this book uses, plus the ones this chapter’s own arithmetic makes answerable.

Testing whether you understand the trade

Q: When would you use a multi-agent architecture?

Name the three structural conditions — context volume, genuine parallelism, different tools or permissions — and say explicitly that task complexity is not one of them. Then show you have costed it: splitting pays when the work produces a lot of material, because a single agent’s cost grows with the square of its steps, and it loses on short work because the per-agent fixed cost is paid in every agent. The strongest answer names what the saving costs: the coordinator sees summaries, not observations.

Q: Why does write-heavy work not parallelise?

Because it becomes a distributed system with none of the usual guarantees. Give the concrete failures — lost updates that raise no error, inconsistent reads, conflicting conclusions the coordinator cannot resolve — and then the mitigations, which are unglamorous: one writer, per-agent workspaces merged deliberately, idempotent tools, append-only proposals.

Testing whether you have shipped one

Q: Your multi-agent system is less accurate than the single agent it replaced. What happened?

Two candidates, and you can distinguish them from the transcripts. Either the summaries lost something — read specialist windows for information that was present and unreported — or the errors compounded, which you check by measuring each specialist alone, comparing against both the product (the independence case) and the [70%, 90%] band, and then measuring the system end to end; the product alone is not the answer. Say that this comparison should have existed before the migration, and that the single agent is the baseline for exactly this reason.

Q: How do you debug a five-agent system?

By admitting it is a distributed tracing problem and building for it in advance: a correlation id (one identifier carried by every message that belongs to the same user request) through every delegation, every specialist transcript persisted, and the coordinator’s delegation decisions logged as first-class events. The honest addition is that this is a real cost of the architecture — one agent produces one transcript, and that is a debugging property you gave up deliberately.

28.10 The 2026 toolbox

Nothing here was run against a model. The cost model is arithmetic over constants measured in earlier chapters, so the stack is one line — and the frameworks below are the ones you would reach for after the arithmetic says to split, not before.

The stack these numbers came from

library	version used	what it is for here
Python	3.14.5	the cost model in Section 28.3 is arithmetic and needs nothing else

Worth knowing about, not used above:

The wider ecosystem, versions as of writing

library	current version	when you would reach for it
langgraph	1.2.11	explicit graphs, checkpointing, and human-in-the-loop interrupts
openai-agents	0.22.0	handoffs and guardrails with very little machinery
pydantic-ai	2.35.3	typed boundaries between agents
crewai	1.15.18	roles and tasks, fastest to a demo
autogen-agentchat	0.7.5	conversational multi-agent research; maintenance mode, so do not start new production work on it
google-adk	2.8.0	agents packaged as deployable services

28.11 Lab: earn the second agent

The order is the point: you compute the split before you build it, which means you are allowed to finish at step 2.

Step 1 — build the single agent

One loop, the tools the task needs, a step cap. Measure score, tokens, and wall-clock on twenty real tasks. This is the number to beat.

Step 2 — compute the split before building it

Take your observed step count and observation size and run Section 28.3’s arithmetic. If the model says splitting costs more, write that down — it is a real result and it is most of the answer. Stop there only if cost is the whole decision. If you are splitting for justification 2 or 3, the arithmetic was never going to be favourable: parallelism buys wall-clock and isolation buys a permission boundary, and both are worth paying tokens for. Say which of the three you are buying, and price it against that.

Step 3 — build the coordinator and three specialists

Delegation, not handoff. Stateless specialists. The coordinator sees summaries.

Step 4 — measure the same twenty tasks

Score, tokens, wall-clock. Report all three, including if the single agent won.

Step 5 — find what the summaries lost

Take five tasks the multi-agent system got wrong and read the specialist transcripts. How often was the information present in a specialist’s window and absent from its report?

Step 6 — introduce a write

Give two specialists the ability to modify the same resource. Run twenty tasks and count the inconsistencies. This is the step that decides whether your architecture is a distributed system.

What to hand in

The two three-column results tables, the count from step 5, the inconsistency count from step 6, and one sentence: did the second agent earn its place?

28.12 Exercises

1. Beat the baseline. Take a task you assumed needed multiple agents. Implement it with one. Compare score, cost and latency, and report the result even when the single agent wins.
2. Run the arithmetic. Measure your real step count and observation size, then compute the crossover for your system. How far are you from it?
3. Find the lost information. For five failed runs, read the specialist transcripts and count how often the answer was present in a specialist’s window and missing from its report.
4. Create the race. Design a shared-state scheme for two agents that can both write. Then describe the race condition you just created, and the smallest change that removes it.
5. Poison a queue. Send a message your agent cannot process. Watch what happens: does it loop, vanish, or reach a dead-letter queue somebody reads?
6. Compound the errors. Measure one specialist’s accuracy in isolation, then predict the three-specialist system’s accuracy before measuring it. Compare your prediction to the result.
7. Delete an agent. Take a working multi-agent system and remove one agent, folding its job into a neighbour. Measure. Removals are as informative as additions and nobody runs them.

28.13 Where to go deeper

Before reading: build the single agent and measure it. Every argument below is easier to evaluate once you have a baseline.

Beyond the papers

resource	what it is
Building effective agents — Anthropic	argues for the simplest thing that works, and is the best counterweight to this chapter’s subject
How we built our multi-agent research system — Anthropic	the other side, from production: where fan-out earned its cost and what it broke
langgraph	control flow as an inspectable state machine
openai-agents	handoffs and guardrails in a small readable loop
autogen	conversational multi-agent, and the clearest way to see the failure modes for yourself
crewAI / adk-python	roles-and-tasks, and agents-as-services

The primary sources

topic	source
the loop each agent runs	Yao, Zhao, et al. (2023)
why self-critique does not rescue a wrong answer	Huang et al. (2024); Madaan et al. (2023)
planning as a separate search	Yao, Yu, et al. (2023)
what a long shared context does to retrieval	Hsieh et al. (2024)
why these systems fail in practice: a taxonomy from 150 expert-labelled traces, applied to 1,600+	Cemri et al. (2025)
the production case for fan-out, and its 15x token bill	Anthropic (2025)

28.14 What to remember

• The single agent is the baseline, and the second agent must beat it on a measurement. Three structural justifications qualify — context volume, genuine parallelism, different tools or permissions. “It is complex” does not.
• Compute the split before you build it. Six steps with 200-token results costs 1.20× as three agents; twenty-four steps with 3,000-token results costs 0.34×. The dial is how much material the work produces, not how hard it is. Both numbers assume no prompt caching and no duplicated work between specialists: turn caching on and the 0.34× becomes 0.65× while three of the nine cells flip, and let each specialist do twice its fair share (d = 2) and no cell pays at all.
• The saving is paid for in information. The coordinator sees summaries because that is the mechanism, so it reasons about a lossy compression. Three specialists at 90% give somewhere in [70%, 90%]: 70% if their errors never coincide, 72.9% if they are independent, 90% if they fully overlap. Where your system sits in that band has to be measured, not computed — and all of it is before the coordinator’s own synthesis, the kind of step where Chapter 23’s agent broke.
• Read-heavy work parallelises; write-heavy work does not. Concurrent writes turn an architecture into a distributed system with lost updates that raise no error and bugs that will not reproduce.
• One writer, own workspaces, idempotent tools, append-only proposals. The mitigations are boring because they are the ones that work.
• Delegate to stateless specialists; do not hand off the conversation. A self-contained subtask is retryable and preserves the context firewall.
• Debugging is a cost you pay deliberately. One agent, one transcript. Five agents need correlation ids, persisted specialist transcripts, and logged delegation decisions — built in advance, not after the first incident.

Anthropic. 2025. How We Built Our Multi-Agent Research System. Anthropic Engineering. https://www.anthropic.com/engineering/multi-agent-research-system.

Cemri, Mert, Melissa Z. Pan, Shuyi Yang, et al. 2025. Why Do Multi-Agent LLM Systems Fail? https://arxiv.org/abs/2503.13657.

Hsieh, Cheng-Ping, Simeng Sun, Samuel Kriman, et al. 2024. “RULER: What’s the Real Context Size of Your Long-Context Language Models?” Proceedings of COLM.

Huang, Jie, Xinyun Chen, Swaroop Mishra, et al. 2024. “Large Language Models Cannot Self-Correct Reasoning Yet.” Proceedings of ICLR.

Madaan, Aman, Niket Tandon, Prakhar Gupta, et al. 2023. “Self-Refine: Iterative Refinement with Self-Feedback.” Advances in Neural Information Processing Systems.

Yao, Shunyu, Dian Yu, Jeffrey Zhao, et al. 2023. “Tree of Thoughts: Deliberate Problem Solving with Large Language Models.” Advances in Neural Information Processing Systems.

Yao, Shunyu, Jeffrey Zhao, Dian Yu, et al. 2023. “ReAct: Synergizing Reasoning and Acting in Language Models.” Proceedings of ICLR.