The Coordination Cost

Overview

The previous topic listed three legitimate reasons for a second agent. This topic is the bill, and it is the reason a single bounded agent remains the right answer in most systems.

One piece of arithmetic in the middle of it is the most persuasive argument available in this entire module.

The arithmetic that settles most arguments

Each agent in a chain is probabilistic. Reliability multiplies.

graph LR
  A["One agent<br/><b>90%</b>"] --> B["Two in series<br/><b>81%</b>"]
  B --> C["Three in series<br/><b>73%</b>"]
  C --> D["Four in series<br/><b>66%</b>"]

  classDef ok fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef warn fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef bad fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A ok
  class B warn
  class C,D bad

Each stage at 90%, composed. Nothing here is specific to agents — it is what happens to any chain of independent probabilistic steps, and it is why adding stages to improve quality usually does the opposite.

Two caveats, because the arithmetic is a model rather than a measurement. Stage failures are not perfectly independent — a well-designed supervisor can catch a worker’s error, which is what supervision is for. And some arrangements are parallel rather than serial, where one failure does not doom the result.

But the direction is reliable, and it is the opposite of the intuition that adding a reviewing stage makes a system better. Adding stages to a serial chain lowers end-to-end reliability unless each stage genuinely catches more than it introduces — and that is a claim requiring evidence, not an assumption.

The other four costs

State handoff. What exactly does a worker receive, and what exactly does it return? That contract is a serialisation format you now own, version and debug. Under-specify it and the worker fills gaps with plausible invention, because that is what the component does when context is missing.

Context duplication. Shared background — instructions, tool schemas, the task framing — must be sent to each agent. Token cost multiplies by the number of agents rather than dividing among them. Delegation saves context in the main loop while raising total spend, and those are different budgets with different owners.

Cache fragmentation. Each agent has its own prefix, and agents on different models have separate caches entirely. Module 4’s cache-scoping finding applies here, multiplied by the number of participants.

Debuggability collapses. One loop is already a path rather than a value. Several loops are a distributed trace across non-deterministic actors, where re-running the inputs produces a different path and therefore cannot reproduce the fault. The next topic but one is about recording instead of reproducing, and multi-agent is what makes it unavoidable.

The honest default, and how to leave it safely

One agent, bounded, with a narrow tool surface and a reviewable plan.

If you must move beyond it, move once and measure:

• One worker, one narrow task, chosen for context isolation rather than ambition.
• An explicit contract for what it receives and returns, written down before it is built.
• The same model, so the cache survives and you have one fewer variable.
• Measured against the single-agent baseline on the same evaluation set. If it does not beat the baseline, it is a more complex system that performs worse, and the correct response is to remove it.

That last point is the one teams skip. A multi-agent design that was never compared against one agent is not a decision; it is an assumption with extra components.

The arithmetic that makes the rejection concrete

Maya Ortiz’s requirement is ≥ 90% correct on a 300-question golden set, with confident errors ≤ 1%.

Suppose the action path were decomposed into three delegated stages — one to interpret the request, one to plan the change, one to execute and verify — each individually achieving 90%.

0.90 × 0.90 × 0.90 ≈ 0.73

73% end-to-end, against a floor of 90%. The multi-agent design does not merely cost more and run slower; it breaks a stated requirement from Module 2 by construction. No amount of prompt work recovers 17 points, because the loss is structural.

To hold 90% end-to-end across three serial stages, each stage would need about 96.5% — a materially harder bar than the 90% the single-agent design has to clear.

That is the whole argument, and it is worth noticing what makes it persuasive to the people who matter here. It is not an architectural preference. It is arithmetic against a number Maya already owns, which means Ivan Petrov does not have to take an architect’s word for it, and Dev Raghunathan can see that the more elaborate design costs more and delivers less.

What survives: the read-heavy ticket-search worker from the previous topic. It sits outside the serial chain — the main loop asks it a question and proceeds with or without a useful answer — so a worker failure degrades the result rather than failing it. That structural difference, parallel-and-optional rather than serial-and-required, is why one delegation is defensible and three are not.

Feeds the workbook

Run this arithmetic in your agent design with your own numbers. The rubric asks for multi-agent to be justified or explicitly rejected; an arithmetic rejection against a named requirement is the strongest version of either.

Check your understanding

1. Run the multiplication for your own design. What per-stage reliability would each stage need to hold your end-to-end floor?
2. A proposed worker sits outside the serial chain. Why does that change the arithmetic, and what must be true of its failure behaviour?
3. Your multi-agent design does not beat the single-agent baseline. Write the sentence you would put in the ADR.

---

→ Delegation exists to protect context. Which raises the question of what context is, and what spending it costs. — Managing context