The assumption is intuitive: more agents, more parallelism, better results. You split the work, you scale the reasoning, you ship faster.
A recent study across 180 agent configurations — spanning GPT, Gemini, and Claude model families — tested that assumption directly. The finding was uncomfortable: blindly adding agents can degrade performance by up to 70%.
This is not a model quality problem. It is an architecture problem.
Three Failure Modes That Explain Why
1. Coordination Tax
When a task requires many tools or subcomponents, extra agents spend more tokens communicating than reasoning. Each handoff carries context. Each agent restates the problem for the next. Each message is a token cost that produces no output.
At low agent counts, coordination is cheap relative to the work. At high agent counts, the overhead eats the benefit. You end up with a system that is simultaneously expensive and slower than a single well-prompted agent would have been.
The signal to watch: if your agents are spending most of their turns summarizing prior outputs for the next agent, you have a coordination tax problem. The fix is usually fewer agents with broader scope, not tighter coordination protocols.
2. Capability Saturation
If a single agent already solves a task at roughly 45% accuracy, adding more agents gives diminishing — or negative — returns.
Why? Because the bottleneck at that point is not throughput. It is the quality of the reasoning step itself. More agents running the same flawed reasoning in parallel doesn't improve accuracy — it amplifies variance. You get more answers, none of them more correct, and now you have a voting problem on top of a quality problem.
Multi-agent architectures pay off when tasks are genuinely parallelizable and independent — different documents, different customers, different data partitions. They do not pay off when the core reasoning step is the bottleneck and you're trying to brute-force past it with concurrency.
3. Error Amplification
In peer setups where agents pass outputs to each other without verification, one agent's wrong output becomes a false premise for the next. The error doesn't just persist — it compounds. Each subsequent agent reasons confidently on top of a flawed foundation.
This is the most dangerous failure mode because it is invisible. The system produces outputs. The agents complete their tasks. The final answer arrives with the same formatting and confidence as a correct one. The error is buried in step three of eight.
Centralized manager architectures contain this better. A manager agent that reviews and validates outputs before passing them forward can catch errors before they propagate. The cost is latency. The benefit is reliability. For high-stakes workflows, that tradeoff is usually worth it.
What This Means for How You Build
Before adding another agent to your system, ask three questions:
- Is the task actually parallelizable? If each step depends on the previous output, agents running in parallel can't help. You need a better single-agent loop, not more agents.
- Where is the bottleneck? If accuracy on the core reasoning step is below 60%, adding agents is the wrong fix. Improve the prompt, the retrieval, the tool definitions, or the model. More agents on a broken foundation is faster failure.
- Who verifies the handoffs? If agents are passing outputs to each other without a validation step, you are building error amplification in by design. Decide where in the chain you need a checking layer — and build it explicitly, not as an afterthought.
The most reliable multi-agent systems I have seen are not the most complex. They are the most deliberate. Fewer agents, clearer boundaries, explicit validation, and a clear answer to the question: what happens when one agent is wrong?
The Advertising and Media Context
In campaign reporting or media measurement pipelines, error amplification is especially dangerous. A misclassified conversion event from one agent becomes a false premise for the budget optimization agent downstream. The budget agent allocates spend based on inflated ROAS for a channel that didn't actually earn it. The reporting agent summarizes the allocation as a success. By the time a human looks at the numbers, three steps of compounded error are baked into the output.
The fix is architectural: validate conversion classification before it enters the optimization layer. Don't assume agent outputs are clean just because they arrived.