Why do multi-agent systems sometimes perform worse than a single agent?

Why more agents can make a coordination problem harder, not smarter

Multi-agent systems are attractive because they promise division of labour, but the gains only appear when the work can be separated cleanly. Once a task is sequential, tightly coupled, or dependent on shared context, each added agent becomes another source of delay, disagreement, and rework. That is why the performance question is really about workflow structure, not agent count, and why agentic design needs the same discipline as any other distributed system. For governance and failure-pattern context, the OWASP Agentic AI Top 10 is useful because it frames orchestration weaknesses as a first-class risk rather than an implementation detail.

Teams often assume more specialised agents will automatically improve reasoning quality. In practice, the coordination overhead can consume the very capacity that the extra agents were meant to create, especially when the system must repeatedly pass partial conclusions between roles.

How the workflow structure determines whether parallelism helps

Multi-agent systems tend to work best when the task can be decomposed into independent subtasks with clear boundaries, such as parallel research, separate evaluations, or staged drafting and review. They tend to underperform when each step depends on the exact output of the previous one, because every handoff introduces a chance for drift, loss of detail, or inconsistent assumptions. The system may still produce a reasonable answer, but it often does so more slowly and with more token use than a single well-directed agent.

The main mechanism is not that agents are inherently worse at reasoning. It is that the orchestration layer has to preserve context, reconcile competing outputs, and decide when disagreement is signal versus noise. That reconciliation work is useful only if the task benefits from independent perspectives. If the work is fundamentally sequential, the extra roles often duplicate thinking instead of adding new information.

• Parallel decomposition helps when outputs are largely independent.
• Sequential work suffers when one agent’s intermediate result becomes another agent’s input.
• Shared state creates a hidden cost because every agent must understand enough context to avoid contradiction.
• Consensus steps can improve confidence, but they also add latency and extra token consumption.

In agent design terms, the question is whether the system is performing distributed computation or merely adding ceremony around a single-threaded task. CSA MAESTRO agentic AI threat modelling framework is relevant here because it treats orchestration and interaction boundaries as part of the risk surface, not just the model outputs themselves. This guidance breaks down when the task is already naturally parallel and the agents have genuinely independent evidence to process.

Where multi-agent setups overpromise, and what the exceptions look like

Tighter coordination often increases overhead, requiring teams to balance specialised reasoning against the cost of handoffs and reconciliation.

Some comparisons are misleading because they pit a single-agent baseline against a multi-agent design that has not been tuned for routing, memory sharing, or role boundaries. If the single agent is allowed to use tools, retrieve context, and iterate, it may outperform a poorly coordinated multi-agent system even on a complex problem. That does not mean multi-agent patterns are weak in general. It means the architecture has to match the task shape, and the evaluation method has to compare equivalent capabilities.

There is also an important edge case where multiple agents are useful despite the overhead: when the goal is not speed but independent critique, adversarial checking, or separation of duties. In those cases, the extra cost is deliberate and can improve reliability, but it should be treated as a trade-off rather than a free productivity gain. Guidance in this area is still evolving, so teams should be cautious about broad claims that “more agents is better” when the evidence is mostly anecdotal.

External guidance from the NIST AI Risk Management Framework is useful for keeping the evaluation anchored in performance, reliability, and governance outcomes rather than novelty. The practical limit appears when orchestration overhead, context fragmentation, or consensus churn starts to dominate the task itself.

Risk and Threat Considerations

Multi-agent systems introduce a material operational risk when orchestration becomes the dominant failure point. The more agents you add, the more interfaces exist for context loss, conflicting outputs, prompt injection propagation, or misrouted authority. That risk becomes especially relevant when agents can act on tools, external data, or downstream workflows without strong gating.

Failure mechanism: A weak coordination design can let one compromised, confused, or overconfident agent contaminate the others through shared context, delegated tasks, or unverified intermediate outputs. The failure pattern is usually compounded by over-trust in consensus, where repeated agreement is mistaken for correctness.

Impact: The system can become slower, more expensive, and less reliable at the same time, while also increasing the chance of unsafe actions, duplicated mistakes, or governance blind spots across the workflow.

Practitioner Guidance

What to prioritise: Start by classifying the task as parallel, sequential, or mixed. If most work depends on the previous step’s exact output, a single agent with strong tool use and clear instructions is usually the better baseline.

What to verify: Measure whether additional agents are producing new information or simply rephrasing the same conclusion. Good multi-agent design shows distinct contribution, not just more chatter or higher token spend.

Decision rule: Use multiple agents when you need independent critique, specialised subskills, or separation of duties. Use fewer agents when the main benefit is simply a longer chain of thought, because that usually increases overhead faster than it improves quality.

What practitioners underestimate: The hidden cost is not only latency. It is the accumulation of small coordination errors that are hard to notice until the system is scaled, automated, or trusted in production.

Practitioner takeaway: Multi-agent design should be justified by task structure and assurance needs, not by the assumption that more roles automatically mean better reasoning.

Related resources from NHI Mgmt Group

• Why do multi agent systems create more identity risk than single AI assistants?
• Why do multi-agent systems create more security risk than single-agent systems?
• Why do multi-agent workflows make MCP governance harder than single-agent systems?
• How should security teams implement agent-to-agent authentication in multi-agent systems?