A multi-agent system is an LLM setup where several agents, each with its own context window, instructions and tools, split one task between them, usually with a lead agent that plans the work and hands pieces to subagents. Anthropic's engineering team defines it plainly: "A multi-agent system consists of multiple agents (LLMs autonomously using tools in a loop) working together."
The pattern can make broad tasks faster and more thorough, but it costs far more tokens and adds coordination problems. This guide explains the main patterns, what the published numbers say, and how to decide whether you need more than one agent.
What is a multi-agent system?
Start with a single agent. Anthropic's Building effective agents post (19 December 2024) separates two kinds of LLM systems:
- Workflows: "systems where LLMs and tools are orchestrated through predefined code paths."
- Agents: systems where "LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."
A multi-agent system puts several agents to work on one goal. Each agent runs its own loop of reasoning and tool calls, in its own context window. One agent usually coordinates, and the others report back to it.
The key idea is context isolation. A subagent can read 40 files or run 20 searches, and only its summary returns to the lead. The lead's context stays small and focused on the overall plan.
How does the orchestrator-worker pattern work?
The orchestrator-worker pattern is the most common multi-agent design. Anthropic's post describes it as "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results," and says it is "well-suited for complex tasks where you can't predict the subtasks needed."
Anthropic's multi-agent research system post (13 June 2025) shows the pattern in production. It uses an "orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents." The flow:
- The lead agent reads the query and plans an approach, "saving its plan to Memory to persist the context."
- It "creates specialized Subagents" for separate research threads.
- The subagents search in parallel, "with their own context windows," and act "as intelligent filters by iteratively using search tools."
- The lead combines their findings and decides whether more research is needed.
- A final step "passes all findings to a CitationAgent" that attaches sources.
Each subagent returns a compressed result, not its full transcript. That is what lets the system cover more ground than one context window could hold.
What other multi-agent patterns are there?
Orchestrator-workers is one of several shapes. Anthropic and OpenAI document these:
| Pattern | How it works | Source |
|---|---|---|
| Orchestrator-workers | A lead agent plans, delegates subtasks and merges results | Anthropic |
| Parallelization: sectioning | "Breaking a task into independent subtasks run in parallel" | Anthropic |
| Parallelization: voting | "Running the same task multiple times to get diverse outputs" | Anthropic |
| Evaluator-optimizer | "one LLM call generates a response while another provides evaluation and feedback in a loop" | Anthropic |
| Agents as tools | A manager agent calls specialist agents as tools and keeps control of the conversation | OpenAI Agents SDK |
| Handoffs | A triage agent routes to a specialist, which "becomes the active agent for the rest of the turn" | OpenAI Agents SDK |
| Agent teams | Peer agents share a task list and message each other directly | Claude Code |
The OpenAI Agents SDK orchestration page also separates orchestrating "via LLM," where the model decides the next step, from orchestrating "via code," where your program fixes the flow. You can mix both: code for the steps you can predict, an LLM for the ones you cannot.
Why use more than one agent?
There are three main reasons.
Parallelism. Independent subtasks run at the same time. Anthropic's research system added parallel subagents and parallel tool calls, and reports: "These changes cut research time by up to 90% for complex queries."
Context isolation. Each subagent explores in its own window and returns only what matters. The Claude Code subagents docs recommend subagents when "The task produces verbose output you don't need in your main context."
More total reasoning. Anthropic's analysis found that "token usage by itself explains 80% of the variance" in performance on its browsing eval, and concluded: "Multi-agent systems work mainly because they help spend enough tokens to solve the problem." Its multi-agent setup "outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval."
That last number is from one internal eval of research tasks. It does not mean multi-agent beats single-agent in general.
What does a multi-agent system cost?
Tokens, mostly. Anthropic measured that "agents typically use about 4× more tokens than chat interactions" and "multi-agent systems use about 15× more tokens than chats." Its conclusion: "For economic viability, multi-agent systems require tasks where the value of the task is high enough" to pay for that.
Claude Code's agent teams docs say the same about coding: agent teams "use significantly more tokens than a single session," and "Token costs scale linearly" with the number of teammates. The docs suggest starting with 3 to 5 teammates and note that "Three focused teammates often outperform five scattered ones."
There is also a latency and coordination cost. Each delegation needs a clear brief, and the lead has to wait for and merge results.
When is a single agent the better choice?
Often. Anthropic's general advice is "finding the simplest solution possible, and only increasing complexity when needed."
The research post names two poor fits for multi-agent systems: "domains that require all agents to share the same context," and many coding jobs, since "most coding tasks involve fewer truly parallelizable tasks than research."
The Claude Code subagents page gives a practical checklist. Use the main conversation when:
- The task needs frequent back-and-forth or iterative refinement
- Multiple phases share significant context, such as planning, implementation and testing
- You are making a quick, targeted change
- Latency matters
Use subagents when the work is self-contained, produces verbose output, or needs its own tool restrictions. The agent teams page adds that for "sequential tasks, same-file edits, or work with many dependencies, a single session or subagents are more effective."
How do you write prompts for an orchestrator?
The lead agent's delegation briefs make or break the system. Anthropic's research post lists what each one needs: "Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries." Its warning: "Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information."
It also recommends you "Scale effort to query complexity" with explicit rules in the prompt, for example: "Simple fact-finding requires just 1 agent with 3-10 tool calls." The post notes that "Early agents made errors like spawning 50 subagents for simple queries" before those rules existed.
A delegation brief that follows that advice might look like this:
Objective: Find every place the app reads the DATABASE_URL variable.
Scope: src/ only. Do not edit files.
Tools: search and read files.
Output: a list of file:line entries with one sentence each on how the value is used.
Stop when: you have searched all of src/ or found 20 matches.
In Claude Code you can save a recurring worker as a subagent file in .claude/agents/ with a name, a description and optional tools and model fields. See Claude Code subagents for the format.
How do multi-agent systems fail?
The research post lists production problems worth planning for:
- Errors compound. "Agents are stateful and errors compound." One bad step early in a long run can derail everything after it.
- Synchronous bottlenecks. "Synchronous execution creates bottlenecks." Anthropic's lead agents wait "for each set of subagents to complete before proceeding," so the slowest subagent sets the pace.
- Deployment breaks running agents. Anthropic uses "rainbow deployments to avoid disrupting running agents" when it ships changes.
Coding agents add a fourth: write conflicts. The agent teams docs warn that "Two teammates editing the same file leads to overwrites," so split work by file ownership.
Testing matters more than usual because behavior varies run to run. Anthropic started "with a set of about 20 queries representing real usage patterns," used an LLM judge with a rubric, and kept human review because "Human evaluation catches what automation misses." Our guide to LLM evals covers how to build that kind of test set.
Where can you try multi-agent setups?
You do not need a framework to start. Anthropic suggests "developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code." Ready-made options:
- Claude Code subagents: each "runs in its own context window with a custom system prompt, specific tool access, and independent permissions." By default a subagent can spawn its own subagents, "up to three layers below the main conversation." See Claude Code subagents and skills vs subagents.
- Claude Code agent teams: experimental and off by default; enable with
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. See Claude Code agent teams. - Codex subagents: see Codex subagents.
- SDKs: the Claude Agent SDK and the OpenAI Agents SDK both support delegation to other agents.
The delegation briefs and subagent instructions you refine are worth keeping. Kipt stores prompts and Agent Skills as Markdown in a private GitHub repo you own, so a brief that reliably produces good subagent output is easy to find and reuse on the next project.
What should you read next?
Read context engineering to see why isolating context is the main benefit of subagents. Then read LLM evals before you trust any multi-agent setup with real work, since you need a test set to know whether the extra agents help.