Skip to content
Agentic Architectures & Multi-Agent PatternsWhen multi-agent hurts

Lead · 7 chapters

When multi-agent hurts

Coordination overhead, compounding error across steps, cost multiplication, unclear ownership of failure

Multi-agent designs should earn their extra latency, token cost, and failure surface; otherwise the single loop is the safer system.

Read these first

What you will know

  • Calculate compounding reliability across N steps

    The multiplication assumes independent steps, so correlated failures, retries, and recovery paths must be accounted for rather than hidden in an average.

  • Show a multi-agent system underperforming a single loop

    A controlled comparison should hold the task and model budget constant while exposing boundary latency, duplicated context, and coordination errors.

  • Attribute a failure when no single agent owns it

    Trace IDs, per-agent outputs, and explicit handoff records are needed to distinguish a bad decision from a broken delegation or integration.

  • Measure the cost multiplier of your architecture

    Count model calls, input and output tokens, wall-clock latency, retries, and orchestration work against the equivalent single-loop path.

  • Recommend removing agents from a design

    A credible simplification preserves the required quality and control while eliminating roles whose information gain does not repay their coordination burden.


Chapters

  1. 1

    The cost multiplier lives on the input side

    Five agents each making one call where a loop made one gets reported as 5x, and then the invoice says otherwise. Every agent re-reads the task, the shared context and the previous agent's output, so five calls can be twelve times the tokens, while the loop accumulates context once and can reuse a cached prefix. Count input and output separately, add retries and orchestration calls, and compare p95 rather than mean latency.

  2. 2

    Ninety-seven percent six times over assumes six independent steps

    A six-step chain at 97% per step gets quoted at roughly 83% end to end, and elsewhere per-agent rates above 96% sit beside an 84% end-to-end result nobody can explain. The load-bearing assumption is independence, which a shared brief and correlated retries both break. Here you do the arithmetic properly, and name what an average across steps is hiding.

  3. 3

    Four defensible outputs and no way to name the fault

    A four-agent pipeline issued an invoice with the wrong total, each output is reasonable given what sat above it, and two days of review has not settled which agent is at fault. What is missing is the record of what each agent was given set against what it returned, under one run ID, which separates a bad decision from a good decision taken on a broken delegation. A verifying agent buys detection and no attribution.

  4. 4

    The loop you kept in the repo has not been maintained

    Testing whether the three-agent design is losing means the same tasks, the same model and the same budget on both arms, with boundary latency, duplicated context and coordination errors instrumented so a loss points at a mechanism rather than being merely observed. Eight months of untouched loop code makes that comparison unfair as stated, and the remedy is specific: bring the loop forward, back-port the prompt and tool fixes the pipeline collected in the meantime, and spend comparable tuning effort on both arms before either number counts. Treating cost as next quarter's problem is how an expensive topology becomes permanent.

  5. 5

    A four-point quality win can be run-to-run variance

    A fair comparison does not make its output real. Run each arm repeatedly over the same tasks, report the spread rather than one pair of headline numbers, and ask whether a four-point gap survives the variance you measured between identical runs of the same arm. Then ask where those points came from: build the set of tasks the two arms disagree on, look at which stage's output differs there, and see whether a single stage accounts for most of them. A difference that localises to one stage is an argument for porting that stage into the loop, not for keeping the topology that carried it.

  6. 6

    Per-step traces are a logging feature, not a topology

    The multi-agent version matches on quality, costs three times as much and runs twice as slow, and the team wants to keep it because every agent has its own trace and debugging got far easier. That debugging gain is real and it is not what the money is buying: instrumenting the loop's steps produces the same traces. Stated properly, the choice is 3x spend against a day of logging work.

  7. 7

    Delete the stage the next one rewrites, then measure

    Asked to take 40% out of a six-agent pipeline, look for the stages whose output the next one rewrites or ignores, ablate each in turn and measure end-to-end quality without it. Moving four agents onto a cheaper model reaches the number while entrenching the stages that should not exist, and each still costs a boundary and a place for a constraint to be dropped. The rare-but-expensive-errors defence is testable rather than rhetorical, but not by ablation: a regression set containing none of the rare cases shows no regression whether the claim is true or false, so go to the historical runs, count the times that stage actually changed an outcome, and price them against what it costs to keep.

External resources