When Not To

The largest empirical study of multi-agent failures to date annotated over 1,600 execution traces across seven open-source frameworks and found failure rates ranging from 41% to 86.7%. The resulting taxonomy sorts fourteen distinct failure modes into three families:

Notice what is not on that list. Almost none of it is model capability. The great majority of multi-agent failures are specification and coordination: problems you introduced by splitting the work, that would not have existed in a single agent, and that no model upgrade will fix.

That is the case against, stated as evidence rather than opinion. This chapter is about the case for, which is narrower than it looks and real where it applies.

The tax is not a metaphor

The coordination tax chapter priced this in tokens and seconds. The short version, because it drives everything else:

Context does not cross the boundary; a summary does. Agent A read four documents and formed a judgment. Agent B receives three sentences. Everything B decides is downstream of a lossy compression that A chose, and B cannot tell what was dropped.

Errors corroborate instead of cancelling. The hope is that a second agent catches the first one's mistake. In practice a reviewer reading the previous agent's conclusion is a second vote, not a check. Part III made this argument about poisoning and it is the same mechanism here, with an org chart drawn on it.

Every boundary is a new failure surface. A handoff can be dropped, duplicated, malformed, or infinitely bounced. None of those exist in a function call.

Which yields the sentence to hold onto, and it is the one the failure data supports:

A single agent that can hold the whole task in its context beats a team of agents that has to coordinate. The only honest reason to split is that it cannot.

The three legitimate reasons

They are all structural. None of them is about capability.

1 · Context genuinely does not fit. Not "the prompt is long": the task involves more material than any single window can hold while still reasoning well, and the budget chapter's tools have been exhausted. Auditing four hundred files, or reading two hundred documents to answer one question. Here isolation is a context-engineering technique that happens to be implemented with agents, and it is the strongest case on the list.

2 · A trust or authority boundary must be enforced. The agent reading untrusted content must not be the one holding the tools, which is the dual-LLM pattern from Part XVII, and it is a security architecture rather than a team of collaborators. The "agents" here do not negotiate; one is quarantined by construction.

3 · Ownership is genuinely separate. Two teams ship, version, evaluate, and are on call for two different agents with different release cycles. This is a real reason and it is an organizational one: you are paying the coordination tax to buy independent deployability, which is exactly the microservices trade and should be made with the same eyes open.

Everything else on the usual list does not survive examination:

The first row is the common one and worth being blunt about. A "specialist agent" is usually a system prompt. If the specialization is a different instruction and a narrower tool list, that is a routing decision inside one agent, which costs one conditional edge instead of a message boundary, a serialization format, a failure mode, and a fresh context.

The promotion test

Before splitting, four questions. A yes to any of the first three is a reason; a no to the fourth is a warning.

   1. Does the work exceed one context window,
      after compaction and selective retrieval?          ── yes ▶ split
                                                              (isolation)

   2. Must some component be denied the tools or
      the data another component holds?                  ── yes ▶ split
                                                              (trust)

   3. Do two teams need to deploy and be paged
      independently?                                     ── yes ▶ split
                                                              (ownership)

   4. Can you write down, right now, the exact
      handoff contract and the termination condition?    ── NO  ▶ do not
                                                              split yet

   All four "no"? It is a workflow. Build the workflow.

Question four is the one that catches most premature splits, because "missing termination condition" and "ambiguous role definition" are named failure modes in the taxonomy above, both in the design-issues family. If you cannot state what each agent is handed, what it must return, and what makes the whole thing stop, you do not have a design; you have a diagram, and the model will improvise the rest at runtime.

What to build instead

The alternative is not "one giant prompt." It is the thing Part VI spent a whole part on: a workflow whose control flow you wrote, with model calls at the steps that genuinely need judgment.

The last row is the one that resolves the parallelism argument honestly. Fanning out over two hundred documents is correct and it is faster, and it does not require agents that talk to each other. Each worker gets one document, returns a structured result, and never learns the others exist. The coordination tax is near zero because there is no coordination: the map-reduce pattern is deterministic orchestration over isolated model calls, and it is what most successful "multi-agent" systems turn out to be underneath.

If you split anyway

Sometimes the answer is genuinely yes. Then the taxonomy is a checklist rather than a warning, and four rules cover most of it:

Write the contract as a schema. What each agent receives and returns, validated, versioned, and tested independently. Prose handoffs are where inter-agent misalignment lives.

Give every loop a termination condition and a budget. Maximum turns, maximum cost, and a defined outcome when either is hit. "It should converge" is not a termination condition.

Make verification independent. A checker that reads the previous agent's conclusion is a second vote. A checker that reads the source data is a check. This is the single highest-value structural fix available, and it maps directly onto the taxonomy's verification family.

Trace across the boundary. One trace ID spanning every agent, or debugging becomes archaeology across three systems. The tracing requirements get strictly harder here, which is another cost in the tax column.

Where the core path leaves you

This is the last chapter of the shortest route through the book, so it is worth naming what you have.

You can build an agent and know why it is a loop. You can budget its context, put its answer where it belongs, and tell when it should not have been an agent at all. You can design tools that survive a model calling them, make them safe to repeat, survive a crash mid-run, put a person in the loop without drowning them, know whether a change made it better, find out what happened afterwards, contain what a hostile ticket can do, and pay a bill you can explain.

The thread through all of it is one claim, made in a different register each time: the model is the part you do not control, so everything around it must be the part you do. Deterministic control flow, typed state, argument-scoped authority, structural rather than requested constraints, and a record you can reconstruct.

What is left in this book is depth, not filler: the parts that matter when a specific thing gets hard. The capstone builds one system end to end with all of it.

References

• Why Do Multi-Agent LLM Systems Fail?, Cemri et al.: the MAST taxonomy and the failure rates quoted here.
• Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets, the equal-budget control the benchmarks usually lack.

Takeaways

• The largest study of multi-agent failures annotated over 1,600 traces across seven frameworks and found 41–86.7% failure rates. The great majority of the causes are specification and coordination, not model capability.
• Context does not cross an agent boundary. A lossy summary does, chosen by the sender, and the receiver cannot tell what was dropped.
• Errors corroborate rather than cancel. A reviewer reading the previous agent's conclusion is a second vote, not a check.
• A single agent that can hold the whole task in context beats a coordinating team. The only honest reason to split is that it cannot.
• Three legitimate reasons, all structural: context genuinely doesn't fit, a trust boundary must be enforced, or two teams need to deploy and be paged independently.
• "Specialist agents" are usually a system prompt and a tool subset, both available inside one agent, for the price of one conditional edge.
• Mirroring the org chart is Conway's law presented as architecture.
• If you cannot state the handoff contract and the termination condition right now, you do not have a design. Missing termination and ambiguous roles are named failure modes for a reason.
• Build the workflow instead: routing edges, evaluator-optimizer loops, conditional tool exposure, and map-reduce over isolated contexts.
• Fan-out over disjoint inputs is genuinely good and is not multi-agent in the risky sense: the workers never negotiate and the reduce step is code.
• If your design has agents talking, you are in the failure regime. If it has agents fanning out, you are not.
• If you split anyway: schema-validated contracts, explicit termination and budget, verification against source data rather than conclusions, and one trace ID across every agent.

Part XIX ends where it started, with one agent and a fan-out that never negotiates, which is the shape the rest of this book has been building all along. Next: The Brief, Part XX, one system built end to end, with every constraint from the preceding twenty parts applied at once.