What is it?
Instead of one agent doing everything, a multi-agent system uses several. Each agent is typically a model call (or loop) with its own system prompt, tools and context window, and a narrower job. They cooperate through some coordination pattern.
Common patterns:
- Orchestrator–workers: a lead agent breaks a task into parts, delegates to worker agents, and combines results.
- Pipeline: each agent handles one stage and passes output onward (research → draft → edit).
- Specialists with handoff: a router sends the request to the agent best suited (billing, technical, legal).
- Generator–reviewer: one agent produces, another critiques against a checklist.
- Parallel exploration: several agents tackle independent sub-questions at once.
Why does it matter?
Reasons teams adopt the approach:
- Context isolation. Each agent sees only what it needs, keeping its context window focused instead of cluttered with everything.
- Specialisation. Narrow prompts and tool sets are easier to write, test and secure.
- Parallelism. Independent subtasks can run simultaneously, saving elapsed time.
- Independent review. A separate checker may catch errors the producer missed (though it can share the same blind spots if built on the same model).
How does it work?
Coordination is the hard part. Design decisions include:
- Roles and boundaries — what each agent is responsible for, and which tools it may use.
- Communication — structured messages (JSON with defined fields) are more reliable than loose prose between agents.
- Control flow — who decides the next step: a central orchestrator, fixed rules, or the agents themselves.
- Shared state — what is passed along, what is stored (Agent Memory: Short-Term, Long-Term and Beyond), and how conflicts are resolved.
- Termination — step limits, budgets and clear "done" criteria, to avoid agents talking in circles.
- Oversight — logging every message and tool call for debugging, and human approval for risky actions.
Cost is multiplicative: several agents each using many tokens can consume far more than a single agent. Latency and error propagation also rise: a wrong claim from one agent can be treated as fact by the next.
Example
Research report workflow:
- Planner splits the question into four sub-questions.
- Four researcher agents each search and summarise one sub-question, returning claims with source URLs in a fixed JSON format.
- A writer agent drafts from those findings only.
- A reviewer agent checks each claim against the cited sources and flags unsupported ones.
- A human approves the final document.
Compare with a fixed workflow: if the four sub-questions are always the same, a plain pipeline with no planner is simpler and more predictable.
When should I use it?
Start with a single agent or a deterministic workflow, and measure (How to Evaluate AI Systems and Outputs). Move to multiple agents when you hit a real limit: the context becomes too large or noisy, the task genuinely parallelises, or you need separated permissions. Do not add agents for the sake of architecture.
Common mistakes
- Starting with multi-agent by default.
- Free-form chatter between agents, which wastes tokens and drifts.
- Unclear ownership, so tasks are duplicated or dropped.
- No budget or step limits.
- Assuming agent agreement means correctness — agents built on the same model can share the same mistakes.
- Not logging inter-agent messages, making failures impossible to trace.