Multi-agent systems have become a popular architectural pattern in AI applications. The idea is appealing: if one agent is good, multiple agents working together must be better. Specialized agents for different subtasks. Agents reviewing each other’s work. Parallel execution across agents.
The appeal is intuitive. The implementation is often a mess of non-deterministic coordination, cascading hallucinations, and debugging nightmares where a problem in one agent produces a subtly wrong result that propagates through three others before producing a visible failure.
This doesn’t mean multi-agent architectures aren’t useful. It means they need to be justified by actual requirements, not enthusiasm.
When Single-Agent Systems Lose
There are tasks where a single agent genuinely hits limitations:
Context window exhaustion: some tasks require more context than any single prompt can hold. Processing a large codebase, analyzing a long document set, or maintaining a long task history may exceed context limits.
Parallel independent subtasks: if a task can be decomposed into genuinely independent subtasks, running them in parallel with separate agents reduces wall-clock time.
Quality control through independent verification: one agent generates a response; another checks it for errors, hallucinations, or policy violations. The checking agent has a different perspective because it’s evaluating output, not generating it.
Specialized capabilities: a coding agent optimized for Python generates code; a separate documentation agent explains it. Different system prompts, possibly different models, appropriate for their specific subtask.
These are real scenarios where multi-agent architecture adds value. They’re also not as common as the marketing suggests.
The Three Main Patterns
Supervisor Architecture
A supervisor agent orchestrates specialized worker agents. The supervisor decomposes the task, delegates to workers, collects results, and synthesizes the final output.
Task → Supervisor Agent
├── Research Agent (tool: web search)
├── Analysis Agent (tool: data processing)
└── Writing Agent (tool: document editor)
↓
Supervisor synthesizes results
↓
Final output
This works well when: the task decomposition is clear, workers can operate independently, and the supervisor can reliably verify worker outputs.
The failure mode: a supervisor that asks workers for subtasks they’re not equipped to handle well, workers that produce plausible-sounding but incorrect results, and a supervisor that can’t detect the errors. The supervisor’s credibility depends on its ability to evaluate the workers’ outputs — which is often the hardest part of the problem.
Peer-to-Peer / Collaborative
Agents interact directly with each other, passing outputs as inputs.
Draft Agent → Critique Agent → Revision Agent → Final output
Or more complex:
Agent A ←→ Agent B (negotiation / debate)
↓
Agreement or escalation
This pattern can improve quality through adversarial interaction — one agent finding flaws in another’s reasoning. It can also amplify errors if the critique agent is evaluating something it’s not equipped to judge.
Parallel Execution
Multiple agents run simultaneously on independent subtasks, with results merged.
Task
├── Agent 1: analyze section A → result A
├── Agent 2: analyze section B → result B (parallel)
└── Agent 3: analyze section C → result C
↓
Merge and synthesize
The merge step is critical and often underestimated. If section analyses can produce conflicting conclusions, you need a merge strategy that handles conflicts rather than just concatenating outputs.
The Hidden Costs
Latency multiplies. In a supervisor pattern with three workers, each running 3 LLM calls, the total is 9+ calls plus supervisor overhead. Wall-clock time may be similar to sequential if the workers share rate limits.
Cost multiplies. More agents = more LLM API calls = more money. For tasks where quality doesn’t meaningfully improve, this is waste.
Debugging is harder. A bug in a single-agent system has one call stack. A bug in a multi-agent system may be a miscommunication between agents, an incorrect assumption by the supervisor, or a worker producing a subtly wrong result that only fails when composed with other workers’ outputs. Reproducing the exact failure requires capturing the full agent interaction, not just the final call.
Non-determinism compounds. Each LLM call has probabilistic outputs. In a 3-agent pipeline, the non-determinism of each step combines. A task that succeeds 90% of the time per agent succeeds only 73% of the time across three sequential agents (0.9³). Test coverage for multi-agent systems must account for this.
State coordination is complex. Agents that share state need coordination mechanisms to avoid conflicts. Agents that each maintain their own state may make inconsistent decisions.
When a Single Well-Designed Agent Is Better
Most tasks that teams reach for multi-agent architectures for don’t actually require them.
A single agent with:
- A well-crafted system prompt that explicitly defines subtasks
- Access to all necessary tools
- Sufficient context window for the task
- Explicit reasoning steps (ReAct, chain-of-thought)
…will often outperform a multi-agent system that wasn’t designed carefully, while being easier to build, debug, and maintain.
The question to ask before adding a second agent: “Would a better prompt, better tools, or a better model for the single agent produce comparable results?” If yes, don’t add the second agent.
When to Actually Use Multi-Agent Systems
Long research tasks that require accumulating information over multiple steps and would exhaust a single context window.
Tasks with clear parallel decomposition and independent subtasks where parallelism meaningfully reduces time-to-result.
Quality-critical outputs where independent verification by a second agent catches errors that the first agent’s self-review misses.
Domain-specialized tasks where different subtasks benefit from different system prompts, tools, or models — and the benefit outweighs the coordination cost.
Not: “we want to seem sophisticated,” “our single agent felt like it needed a co-worker,” “we read about multi-agent systems in a blog post.”
Practical Advice
Start single-agent. Add agents when you hit a specific, measurable problem that additional agents would solve. Measure the improvement.
Instrument everything. Every agent call, every inter-agent message, every tool call. When a multi-agent system produces wrong output, you need to trace exactly where in the pipeline the error was introduced.
Define the interface between agents clearly. What does Agent A promise to deliver? What does Agent B expect to receive? Treat inter-agent interfaces with the same rigor as any other API boundary.
The multi-agent pattern is a tool. Apply it to problems it solves. Don’t apply it to problems you don’t have.