Multi-agent systems
Multi-agent systems split work among several AI agents with different roles. Learn the main architectures, when they beat a single agent, and their costs.
Overview
A multi-agent system is an AI application in which several agents, each with its own instructions, tools and often its own model context, work together on a task. One agent might research, another write, another check the result. They pass work to each other or report to a coordinating agent.
A newsroom is a useful picture. A reporter gathers facts, an editor shapes the story, a fact-checker verifies claims and a section chief decides what runs. No single person could do all of it as well within a deadline, because each role needs different focus and different sources. But a newsroom also has meetings, handoffs and misunderstandings. A small story written by one person is often faster. Multi-agent AI has the same trade-off: specialisation and parallelism on one side, coordination cost on the other.
What it is
An agent is a model running a loop of reasoning and tool use, with its own system instructions and tool set. A multi-agent system connects several such agents through a defined communication pattern. The key design choices are:
- Roles: what each agent is responsible for and which tools it has.
- Topology: who talks to whom, and who decides.
- Shared state: what information agents see in common, such as a task board, a document or a memory store.
- Termination: who decides the task is complete.
Where it came from
Multi-agent systems are an old idea in computer science. Research in the 1980s and 1990s studied software agents that negotiate, coordinate and share tasks, with formal languages for agent communication. Reinforcement learning later studied multiple learning agents in shared environments.
Language models revived the idea from 2023 onward. Research projects showed role-playing agents cooperating on software and simulated societies of agents with memory. Open-source frameworks made it easy to define agents that converse, hand off and delegate. By 2025 major model providers published SDKs with handoffs and sub-agents as first-class concepts, and protocols such as A2A appeared for agents from different vendors. At the same time, practitioners reported that many multi-agent designs were slower and less reliable than one well-equipped agent, which led to more careful guidance on when to split work.
How it works
Common architectures
| Architecture | How it works | Good for |
|---|---|---|
| Orchestrator-workers | A lead agent plans, sends sub-tasks to worker agents and combines results | Research and analysis that split into parallel parts |
| Supervisor and router | A front agent classifies the request and hands it to a specialist | Customer service with distinct domains |
| Sequential pipeline | Agents work in a fixed order, each refining the previous output | Draft, review and polish workflows |
| Handoffs | The active agent transfers the conversation and control to another agent | Conversations that move between departments |
| Debate or critique | Agents propose and challenge answers until they agree or a judge decides | Reasoning tasks where errors are costly |
| Shared blackboard | Agents read and write a common workspace and act when relevant | Loose collaboration on a shared artefact |
Context isolation
One of the most useful properties of sub-agents is that each starts with a clean context. A research sub-agent can read fifty pages, then return a one-paragraph summary to the lead agent. The lead agent never carries the fifty pages. This keeps the main context small and focused on long tasks.
Communication
Agents in the same program usually communicate through function calls: the lead agent calls a tool such as delegate_research(question) that runs another agent and returns its answer. Agents from different vendors or services communicate through a protocol such as A2A, with tasks and artifacts.
Termination and budgets
Every multi-agent system needs a clear rule for when work is done and limits on steps, time and cost for each agent and for the whole run. Without them, agents can keep passing work back and forth.
Key concepts and terms
| Term | Meaning |
|---|---|
| Agent | A model with instructions and tools running a reasoning loop. |
| Orchestrator | An agent that plans and delegates to other agents. |
| Worker or sub-agent | An agent that handles one delegated part of the task. |
| Handoff | Transfer of control from one agent to another. |
| Router | An agent or step that picks the right specialist. |
| Shared state | Information visible to several agents. |
| Context isolation | Each agent working in its own separate context. |
| Topology | The pattern of communication between agents. |
A worked example
A market research team wants a briefing on battery storage suppliers in three regions.
- The lead agent reads the request and splits it into three regional research tasks plus a comparison step.
- Three research sub-agents run in parallel, each with web search and a document reader, each limited to fifteen steps. Each returns a structured summary with sources.
- A analysis agent receives the three summaries, builds a comparison table and flags gaps, for example missing price data for one region.
- The lead agent sends one targeted follow-up to the relevant research agent, receives the missing data and assembles the final briefing.
- A review agent checks every claim against its cited source and marks two claims as unsupported. The lead agent removes them.
Running regions in parallel cut the wall-clock time. Isolated contexts kept the lead agent's context small. The review step caught errors a single agent would likely have kept.
Strengths and limitations
Strengths
- Specialisation. Focused instructions and tools per role improve quality on complex tasks.
- Parallelism. Independent sub-tasks run at the same time.
- Context management. Sub-agents absorb large inputs and return compact results.
- Checks and balances. Separate reviewer or judge agents catch mistakes.
- Modularity. Agents can be improved, replaced or reused independently.
Limitations
- Cost. Several agents often use several times the tokens of one agent.
- Latency. Handoffs and sequential steps add time.
- Error propagation. A wrong result from one agent can mislead all the others.
- Coordination failures. Duplicated work, conflicting decisions and loops are common.
- Harder debugging. Problems span several trajectories and require good tracing.
How it compares with alternatives
| Option | Choose it when |
|---|---|
| Single agent with tools | The task fits in one context and one set of instructions |
| Fixed workflow | The steps are known and never change |
| Multi-agent in one framework | One team owns all agents and needs specialisation or parallelism |
| Multi-agent over A2A | Agents belong to different teams or vendors |
A reasonable default is to start with one agent and add agents only when a measured problem appears: a context that overflows, a sub-task that would benefit from parallelism, or a quality gap a reviewer could close.
Practical guidance and best practices
- Start with one agent. Split only when evaluation shows a clear reason.
- Give each agent one job. Clear, narrow roles beat general ones.
- Return structured results. Sub-agents should hand back typed summaries with sources, not long prose.
- Budget every agent. Limit steps, time and tokens per agent and per run.
- Define completion. Make one agent responsible for deciding the task is done.
- Trace end to end. Use one trace id across all agents and log every handoff.
- Evaluate the whole system. Measure final quality, cost and latency, and compare with a single-agent baseline.
Common mistakes
- Agents for the sake of agents. Splitting a simple task adds cost with no gain.
- Overlapping roles. Two agents doing the same work produce duplication and conflict.
- Passing full contexts. Sending every transcript to every agent defeats context isolation.
- No final authority. Without a clear decider, agents keep revising.
Frequently asked questions
When is a multi-agent system better than a single agent?
When a task splits into independent parts that can run in parallel, when sub-tasks need very different tools or instructions, or when a separate reviewer measurably improves quality. Otherwise a single agent is usually cheaper and more reliable.
What is the orchestrator-workers pattern?
A lead agent plans the task, sends parts to worker agents, and combines their results into the final output.
How do agents communicate?
Inside one application, usually through function calls that run another agent. Across vendors or services, through protocols such as A2A.
Do multi-agent systems cost more?
Usually yes. Each agent consumes tokens, and coordination adds overhead. The extra cost is justified only if quality or speed improve enough.
How do I debug a multi-agent system?
Trace every agent's steps under one shared trace id, log handoffs and tool calls, and replay failing runs. Evaluate both individual agents and the whole system.
Glossary
- A2A: an open protocol for communication between agents.
- Blackboard: a shared workspace that several agents read and write.
- Handoff: passing control from one agent to another.
- Orchestrator: an agent that plans and delegates.
- Trace: a recorded path of one request through a system.
Summary
Multi-agent systems divide work among agents with distinct roles, tools and contexts. Orchestrator-workers, routers, pipelines, handoffs and debate are the main patterns. They bring specialisation, parallelism and built-in review, at the price of cost, latency and coordination risk. Start with one agent, split only for measured reasons, give each agent one job, budget everything and trace every handoff.
Related
It belongs to Patterns in my stack, under Agentic AI. Others in the same group: