Multi-agent AI is an approach where several AI agents, often with different roles, instructions and tools, work together on a task. One agent may research while another writes and a third reviews, coordinated by an orchestrator or by handing work along a chain. The appeal is specialisation and parallelism; the cost is complexity, tokens and new failure modes.
Key takeaways
- Each agent has its own instructions, tools and context.
- The most common pattern is orchestrator-worker.
- Multi-agent designs help most when subtasks are genuinely independent.
- They typically cost several times more tokens than a single agent.
- Many “multi-agent” problems are better solved by a well-designed single agent.
Multi-agent AI explained in simple terms
A small consulting team splits a project: one person researches, one builds the model, one writes the report, and a lead coordinates. This works because the tasks are separable and each person has focus. It fails when they duplicate work, misunderstand handovers or need constant meetings. Multi-agent systems have exactly the same strengths and failure modes.
Common coordination patterns
| Pattern | Structure | Good for |
|---|---|---|
| Orchestrator-worker | A lead agent plans and delegates subtasks | Research, broad information gathering |
| Sequential handoff | Output passes along a chain of specialists | Draft, edit, fact-check pipelines |
| Parallel workers | Several agents work simultaneously, results merged | Independent subtasks, breadth |
| Debate or critique | Agents argue or review each other’s answers | High-stakes reasoning, quality checks |
| Router | A dispatcher sends each request to a specialist | Mixed request types |
| Blackboard | Agents share a common workspace | Complex collaborative tasks |
When multiple agents help
- Subtasks are independent and can run in parallel, such as researching ten suppliers.
- Roles need genuinely different tools or permissions.
- Separate context is valuable, so one agent’s long tool output does not clutter another’s.
- Review benefits from a fresh perspective, as in generate-then-critique.
When they hurt
- Tasks are sequential and tightly coupled, so agents wait on each other.
- Shared context matters more than specialisation.
- Handovers lose information, a very common failure.
- Cost and latency multiply without a matching quality gain.
A practical rule: try a single agent with good tools first. Add agents only when a specific limitation, such as context pollution or parallelism, demands it.
A worked example
Task: “Compare five CRM products for a 50-person company.”
- The orchestrator creates five subtasks, one per product, plus a comparison task.
- Five worker agents research in parallel, each with search and page-fetch tools, each returning a structured summary.
- The orchestrator merges the summaries into a comparison table.
- A reviewer agent checks for unsupported claims and missing sources.
Parallelism makes this much faster than sequential research, and each worker keeps a clean context.
Engineering considerations
- Structured handoffs: pass structured output, not free text.
- Clear ownership: every subtask needs one responsible agent.
- Termination: cap rounds to prevent endless delegation.
- Cost controls: budget tokens per agent and overall.
- Observability: trace every agent’s steps, or debugging is impossible.
- Shared memory: decide explicitly what is shared and what stays local.
Limitations
- Token use often several times a single agent’s.
- Errors propagate across handovers.
- Coordination overhead can exceed the benefit.
- Non-deterministic behaviour makes testing hard.