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

They often fail when the task is sequential rather than parallel. Extra agents add handoffs, reconciliation work, and duplicated reasoning, which can reduce output quality and increase token consumption. The right question is not how many agents to add, but whether the workflow actually benefits from distributed processing.

Why This Matters for Security Teams

Multi-agent systems are often introduced as a way to improve throughput, reasoning quality, and specialization, but the security and governance overhead rises quickly when coordination becomes part of the workload. Each additional agent can introduce more state, more permissions, more tool access, and more opportunities for drift between intent and execution. That matters for AI governance because failure is not only about accuracy; it is also about traceability, output validation, and whether the system can be controlled when tasks expand across multiple autonomous components. Guidance from the NIST AI Risk Management Framework is useful here because it frames AI as a risk system, not just a model.

Security teams often underestimate the coordination tax. A single agent can be simpler to observe, constrain, and test, while a swarm of agents can create hidden dependencies that are difficult to review after deployment. That is especially true when agents are allowed to call tools, retrieve external content, or hand work between planners and executors. Current guidance suggests treating agent count as a design choice with operational and risk implications, not an automatic path to better outcomes. In practice, many security teams encounter degraded quality only after agents have already been granted broad tool access and their cross-talk has become the source of the failure.

How It Works in Practice

Multi-agent workflows can perform worse when the task is actually sequential, tightly coupled, or sensitive to context consistency. In those environments, a single agent may preserve state more reliably than a chain of agents that must continuously restate goals, merge partial results, and resolve contradictions. The problem is not merely latency. It is also the cumulative effect of duplicated reasoning, inconsistent assumptions, and weak handoff discipline. That is why agentic security guidance such as the OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework both emphasise orchestration, trust boundaries, and controlled delegation.

• Use multiple agents only when the work can be partitioned cleanly into bounded sub-tasks with clear success criteria.
• Define who owns state, who validates outputs, and when an agent must stop rather than continue improvising.
• Limit tool access per agent, especially for agents that can write files, invoke APIs, or trigger downstream actions.
• Prefer explicit checkpoints for reconciliation, because informal agent-to-agent messaging often amplifies errors instead of correcting them.

From a defensive perspective, this also matters for threat modelling. More agents can mean more places for prompt injection, poisoned retrieval, or tool misuse to enter the workflow, which maps closely to adversarial patterns tracked in the MITRE ATLAS adversarial AI threat matrix. The practical test is whether decomposition really reduces complexity, or simply spreads it across more components that still need to agree on a final answer. These controls tend to break down when agents share a mutable context store and no single component is accountable for final output validation.

Common Variations and Edge Cases

Tighter orchestration often increases review overhead, requiring organisations to balance modularity against coordination cost. That tradeoff is real, and current guidance is still evolving on how many agents are optimal for a given workload. For some tasks, such as parallel research, triage, or independent verification, multiple agents can add value. For other tasks, especially those that are sequential, stateful, or highly regulated, extra agents may reduce confidence because every handoff creates another chance for drift.

Edge cases appear when the system mixes planning agents, execution agents, and monitoring agents with different permissions. In those designs, the primary question becomes governance of the whole workflow, not tuning of any one model. The practitioner should ask whether output quality depends on consensus between agents, whether disagreements are surfaced or hidden, and whether the final result is checked against authoritative sources before action is taken. This is where best practice is evolving, particularly for agentic systems that control business processes or security operations. The NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modelling framework both support that systems-level view.

In practice, the “more agents is better” assumption fails most often when teams optimise for apparent parallelism but ignore the cost of synchronisation, permission sprawl, and weak final review.

Related resources from NHI Mgmt Group

• Why do multi agent systems create more identity risk than single AI assistants?
• How should security teams implement agent-to-agent authentication in multi-agent systems?
• Why do multi-hop AI agent workflows create more risk than single-agent automation?
• How can security teams prevent privilege amplification in multi-agent systems?