One agent with good tools can do a lot. But some tasks are too broad for one context window, or they need different skills and permissions. Then teams split the work: one agent plans, several research in parallel, another one checks the result. Done well, this raises quality. Done badly, it multiplies cost, errors and confusion.
This is part 3 of Level 4 (Expert) in our AI Development path. You will learn four proven patterns, when several agents help and when they hurt, how errors and costs compound, how to trace a multi-agent run and where people must check the work. It builds on AI agents with tools, loops and memory from Level 3.
What makes a system multi-agent
A multi-agent system consists of several agents, each with its own instructions, context, tools and permissions, that hand work to each other. Either your code coordinates them along fixed paths, or an agent decides at run time who does what. Anthropic calls the first kind a workflow and the second an agent in the narrow sense (Source: Anthropic, “Building effective agents”, 2024). Many systems sold as multi-agent are really workflows — often good news, because fixed paths are easier to test.
Several agents can bring real benefits:
- Clean contexts. Each agent sees only what its subtask needs, instead of one overflowing context.
- Parallel work. Independent subtasks run at the same time, which shortens the waiting time.
- Specialization. Each role gets its own prompt, tools and, if useful, its own model.
- Least privilege. A research agent can read but not send; only one agent may write.
- Independent review. A second agent with its own instructions checks the work of the first.
Two open protocols connect the parts. The Model Context Protocol (MCP), published by Anthropic in November 2024, standardizes how agents access tools and data. The Agent2Agent protocol (A2A), announced by Google in April 2025, describes how agents from different systems exchange tasks.
Four proven patterns
Most real systems are built from a few basic patterns:
The table lists the four patterns and adds debate, a research variant of the reviewer pattern:
| Pattern | Good for | Main risk | Control |
|---|---|---|---|
| Orchestrator and workers | Broad research, parallel subtasks | Duplicate work, vague briefs | A precise brief per worker: goal, output format, limits, tools |
| Pipeline | Fixed stages such as extract, check, write | Errors flow downstream | Schema validation between stages |
| Generator and reviewer | Drafts with clear quality criteria | Endless loops, shared blind spots | A round limit; a rubric or another model for the reviewer |
| Debate or voting | Hard questions with checkable answers | Cost grows with every agent; agreement on a wrong answer | Use only where your evals show a gain |
| Shared memory | Long tasks that build on findings | Conflicting entries; one wrong note misleads all | One writer, versioned entries with sources |
The orchestrator-worker pattern is the best documented. In Anthropic’s research system, a lead agent plans the research, starts subagents that search in parallel and combines their findings. With Claude Opus 4 as the lead and Claude Sonnet 4 as subagents, it outperformed a single Claude Opus 4 agent by 90.2 percent on Anthropic’s internal research eval. The analysis also explains much of the gain: on a browsing benchmark, token usage alone explained 80 percent of the differences in results. Several agents work partly because they can spend more tokens in parallel (Source: Anthropic, “How we built our multi-agent research system”, 2025).
In a debate, several instances of a model answer, read each other’s answers and revise them over several rounds. In experiments by researchers at MIT and Google Brain, this improved factual accuracy and reasoning (Source: Du et al., “Improving Factuality and Reasoning in Language Models through Multiagent Debate”, 2023, arxiv.org).
When several agents help — and when they hurt
Two questions decide: how many parts of the task can run in parallel, and how independent are those parts?
Tightly coupled work is the classic trap. Anthropic notes that most coding tasks contain fewer truly parallel parts than research. Cognition, the maker of the coding agent Devin, argues that every action carries hidden decisions about style, names or edge cases. Parallel agents that cannot see each other’s decisions then produce parts that do not fit together (Source: Cognition, “Don’t Build Multi-Agents”, 2025). In 2026, the same company reported that multi-agent setups work best today when “writes stay single-threaded”: several agents may analyze or review, but only one changes the code (Source: Cognition, “Multi-Agents: What’s Actually Working”, 2026).
Research confirms that coordination itself is a source of failure. A study of popular multi-agent frameworks grouped 14 failure modes into three categories: weak system design and task specification, misalignment between agents, and poor verification and termination (Source: Cemri et al., “Why Do Multi-Agent LLM Systems Fail?”, 2025, arxiv.org). Hence the rule: start with one agent, measure a baseline on your eval set, and add agents only when the measured gain justifies the extra cost.
Errors and costs compound
Every step and every handoff can fail. If each step succeeds independently 95 percent of the time, a chain of ten steps succeeds only about 60 percent of the time:
Real errors are not fully independent, but the direction holds: long chains need checks between the steps. Validate each handoff against a schema, let a step retry on its own before the whole task restarts, and save intermediate results so that a run can resume.
Costs compound as well. Every agent reads its own context, and many re-read what others wrote. In Anthropic’s data, agents used about four times as many tokens as chat interactions, and multi-agent systems about 15 times as many (Source: Anthropic, 2025, see above). Set a token budget per task and per agent, and consider lighter models for workers with simple jobs.
Keep each worker’s task small. The METR time horizon measures the length of tasks that a model completes in about half of the attempts — so tasks of that length still fail half the time. These are the current leaders in our data:
| # | Model | Released | Result |
|---|---|---|---|
| 1 | Claude Mythos Preview (Early) Anthropic | Apr 7, 2026 | 17 h 25 min |
| 2 | Claude Opus 4.6 (unknown thinking) Anthropic | Feb 5, 2026 | 11 h 59 min |
| 3 | Gemini 3.1 Pro Preview Google DeepMind | Feb 19, 2026 | 6 h 24 min |
| 4 | GPT-5.2 (high) OpenAI | Dec 11, 2025 | 5 h 52 min |
| 5 | GPT-5.3 Codex OpenAI | Feb 5, 2026 | 5 h 50 min |
The length of the tasks a model completes correctly about half of the time, measured by how long a human expert needs for them. The number is a duration, not a score: a longer horizon means the model can work on its own for longer. Data: Epoch AI, retrieved on October 17, 2026, licensed CC BY 4.0. All models: LLM database.
Give workers tasks that are far shorter than this horizon, and let the orchestrator combine many short successes instead of hoping for one long one.
Tracing a multi-agent run
When a multi-agent task fails, you need to know which agent got which brief, what it did and what it returned. Record each task as one trace, with a span for every agent and tool call and a link to its parent span:
The OpenTelemetry project has semantic conventions for generative AI. They standardize attributes such as the model name and token counts, so traces from different frameworks fit into one tool. Level 3 shows how to set up observability for LLM apps. For multi-agent systems, watch four numbers per task: success rate, cost per successful task, number of handoffs and repeated loops. Then evaluate the system end to end and per role; Level 2 shows how to test AI features with evals.
Human checkpoints
More agents mean more actions that nobody watches in real time. Put people where a mistake is expensive:
- Before the fan-out: approve the plan before the orchestrator starts dozens of workers.
- Before external actions: sending, paying, deleting or deploying always needs approval.
- At the result: for high-stakes output, a person signs off the final answer.
- On disagreement: when generator and reviewer do not converge, escalate instead of looping.
Agents also pass content to each other. A worker that reads web pages can carry hidden instructions into the orchestrator’s context — a form of prompt injection. Treat every worker result as data, never as instructions, and give workers read-only rights. Our AI Security section explains the attack.
Design checklist
Answer these questions before you build:
| Question | A good answer |
|---|---|
| Would one agent with better tools do the job? | You measured a single-agent baseline on the same eval set |
| Are the subtasks independent? | Yes — or only one agent writes |
| Does every handoff have a contract? | Goal, inputs, output schema, limits |
| What are the limits? | Maximum agents, rounds and tokens per task |
| Where do people check? | The plan, external actions, the final result |
| Can you see everything? | One trace per task, one span per agent |
You do not have to code the orchestration yourself. According to the vendors, MindStudio builds AI agents without code, Turbotic builds automations from a plain-language description, Devs.ai lets teams build and run agents on their own data, and Dry Ground AI handles routine work through connected tools:
Short descriptions from our tool comparison, based on the vendors' information — not tested by ABXK.
Whatever the platform, keep measuring: a multi-agent system earns its place only when it beats the single-agent baseline on quality per unit of cost.