Multi-Agent Systems: When More Agents Help

What does coordination cost?

Let us start with a number, because it sets the floor. According to the vendor, agents use roughly four times as many tokens as a plain chat; multi-agent systems use fifteen times as many.

[Own calculation] From that: a multi-agent build raises the token cost roughly fourfold compared with a single agent.

That number is the entry fee. If the decomposition does not deliver four times the value, it runs at a loss — and you need to know that in advance, not afterwards from the invoice. Why the gain is not in the parallelism is what the subagents and parallel work post goes into in detail; from here on this article is about the patterns.

Five systems, measured results

The best available data on this is an academic study that processed 1,642 annotated run traces across seven multi-agent frameworks. It reported comparable success rates for five of them:

And the study's opening sentence is this: despite the enthusiasm for multi-agent systems, their gains on popular benchmarks are often minimal.

Look at the shape of that table. The rows that turned out well are all closed, short, checkable tasks. The rows that turned out badly are all long, open-ended and made of many steps. That is no accident — and it is precisely what choosing a pattern is about.

The six patterns

The primary documentation distinguishes six builds. It is worth learning their names, because with that vocabulary the sentence "let's use several agents" turns into a concrete design decision:

Of the six, four generally pay back the cost of coordination, and two only rarely do.

The four that pay back

1. Routing — the cheapest win

A small, fast model classifies the input, and from there the appropriate specialised prompt handles it. The extra cost is a single short call, and the gain is that every branch gets a focused system prompt.

It is good when the categories genuinely separate and the classification is reliable. It is bad when edge cases are common — because a task that lands in the wrong branch stays in the wrong branch all the way.

2. Chaining — accuracy for latency

A fixed sequence of steps: outline, then check, then expand. It is not dynamic, it decides nothing — which is what makes it predictable and debuggable.

This is the most underrated pattern. It is not exciting, but most business tasks are exactly like this: the steps are known in advance. Token cost here does not quadruple, it only grows with the number of steps, and the output of every step can be checked. If you pass a structured format between the steps, the chain gets more robust — the structured output primer gives you a handle on that.

3. Parallelisation — when the parts really are independent

There are two versions of it, and they are worth telling apart:

• Sectioning: the input can be cut into independent pieces (a hundred documents, a hundred calls).
• Multiple viewpoints: you run the same task from several angles, and agreement raises your confidence.

The key phrase in the definition is that the outputs are aggregated in code. The moment you hand the stitching to a model as well, you have stepped into the orchestrator pattern, and into its failure modes with it.

4. Evaluator and optimiser — the only one with hard evidence

This is the best-supported pattern, and two complementary measurements stand behind it.

The first is negative: a 2024 academic result found that models cannot correct themselves without external feedback — in fact, after self-correction their performance sometimes gets worse. So the "think it over once more" kind of self-check is not worth it.

The second is positive: in the same multi-agent study two interventions were tried out, with the same base model, changing only the build of the system:

This is the most important message in the article. The difference is not in the model but in whether the system has an external point of verification. Self-checking does not improve things; another call looking at it from outside does — and deterministic verification written in code does so even more.

One important caveat, though: the +15.6 points started from a base of 25%. Verification improves things, but it does not rescue a bad underlying build.

The two that rarely pay back

5. Orchestrator and workers

This is what most people call a "multi-agent system": a lead model decides as it goes what is needed, and delegates.

This is the most powerful pattern — and the most expensive. The fifteen-fold token multiplier lives here, and this is where the coordination failures cluster too. The documented early failures are concrete and instructive:

• fifty subagents started for simple questions;
• endless searching for sources that do not exist;
• of three subagents one gathered data on something else entirely, while two did the same work;
• delegation instructions so vague that the subagents misunderstood the task.

It is worth it when the subtasks genuinely cannot be defined in advance — typically in open-ended research. It is not when the steps are known in advance: there, chaining gives you the same thing at a quarter of the price.

The vendor's own documentation counsels caution in two places: most coding tasks have fewer genuinely parallelisable parts than research does, and — in a 2026 piece of theirs — "most conventional coding tasks do not need a five-person review panel".

6. Fully autonomous agents talking to each other

The bottom two rows of the measured table are systems like this. 25.0% and 13.3%.

The best explanation for it comes from a tool vendor's 2025 piece, which sets out two principles: share the whole trace, not just the messages, and actions carry hidden decisions, and decisions that contradict each other produce a bad result.

The example that goes with it is the best illustration of the topic. The task: build a simple arcade game. After the decomposition one subagent misreads the style and produces a background reminiscent of a completely different game; the other draws a main character that does not fit it. The closing agent gets an impossible job: it has to fit two incompatible pieces together.

And notice the twist: neither subagent made a mistake. Both did sensible work — just on different assumptions. A coordination failure is not assembled from wrong answers, but from right answers that do not fit together.

Where exactly does it break?

The full failure typology, from 1,642 run traces, in three categories:

One surprising reading comes out of this. The largest share of failures does not come from communication between agents but from the design of the system — from the agent repeating itself, not knowing when it is done, or not sticking to the specification it was given.

That is good news: the biggest category is the one you can improve by changing prompts and budgets, not the one that would need a different model. The second largest item, reasoning and action diverging — where the agent describes what it is going to do and then does something else — can also be caught by verification: if you ask for the plan in structured form and compare it in code with the steps actually executed, the failure mode becomes visible.

The relationship between step count and reliability has its own piece: the agent reliability math post derives why 95% per-step accuracy is not enough.

A 2026 development that rearranges the picture

A sentence has turned up in the documentation of the newer models that is worth taking seriously: the new model generation delegates to subagents more readily than the previous one did. The recommendation from the same place: give explicit guidance on which situations justify delegation, or cap the number of subagents.

That means multi-agent behaviour is no longer only an architectural decision, it is also model-version-dependent behaviour. The same prompt with the same build may, on a new model, start more agents, burn more tokens and fail differently.

The practical consequence: when you switch models, the decomposition rules have to be reviewed again, not only the prompts. And if your cost suddenly jumped after an upgrade, this is the first place to look.

The decision order

1. IS THERE A KNOWN SEQUENCE OF STEPS?
   -> CHAINING. Cheap, predictable, debuggable.

2. DISTINCT CATEGORIES, HANDLED SEPARATELY?
   -> ROUTING. One short call is the whole cost.

3. INDEPENDENT PIECES, JOINABLE IN CODE?
   -> PARALLELISATION. But do NOT let a model do
      the joining.

4. IS THERE A CLEAR EVALUATION CRITERION?
   -> EVALUATOR-OPTIMISER. Strongest measurement:
      +15.6 points. But it takes an EXTERNAL check,
      self-checking does not improve anything.

5. ARE THE STEPS REALLY UNDEFINABLE UP FRONT?
   -> ORCHESTRATOR AND WORKERS. 4x the token cost
      of one agent, and cap the number of subagents
      it may start.

6. IN EVERY OTHER CASE
   -> ONE AGENT. This is the correct default.

The first four points cover most business tasks — and none of them needs what is colloquially called a multi-agent system.

Common misconceptions

• "A multi-agent system is more powerful." In the measurement they scattered between 13.3% and 84.8%. The build decides, not the head count.
• "If the task is complex, you need more agents." Complexity on its own is not a reason. The question is whether the steps can be defined in advance: if they can, chaining gives you the same result more cheaply.
• "The agents will sort it out between themselves." Close to a third of the measured failures are exactly the failure of sorting it out — and its most common form is not a wrong answer but an assumption that does not match.
• "Let's add a checking agent and it will be fine." It helps — measurably, by 15.6 points — but that measurement started from a base of 25%. Verification does not repair a bad build.
• "Let's ask the model to check itself." Without external feedback, self-correction does not improve anything, and sometimes makes it worse.
• "Coding is the home turf of multi-agent systems." According to the primary documentation, coding tasks have fewer genuinely parallelisable parts than research does.
• "The same build will work the same way on a new model." Newer models delegate more readily. The same prompt may run more expensively.

What to take away

The question is not "how many agents should I use" but which pattern fits the task. Four of the six — chaining, routing, parallelisation and the evaluator-optimiser pair — are cheap and predictable. The remaining two are powerful but expensive, and most of the measured failures are generated there.

One number worth remembering: plus 15.6 points from an external verification step, with the same model. If you build in one thing, build in that — and do not ask the model for it, put it there from outside.

And the best self-check question before you design anything: can you write the steps down in advance? If you can, you do not need a multi-agent system — you need a chain. How you measure and watch the finished system is what the testing and monitoring agents post takes through, end to end.