In this article
Before you start
Why interviewers ask this
A candidate who says "I would use several agents" without a reason has usually not paid for one. Interviewers raise multi-agent systems, reported by candidates in questions about orchestration patterns, swarms, frameworks and "the multi-agent version beats the simple pipeline on the benchmark, do you ship it?", because the answer separates people who have thought about cost, failure and evaluation from people who like diagrams with many boxes.
A weak answer lists agent roles such as "researcher" and "writer". A strong answer says what is split, what each piece can see, how results come back, and what the extra agents cost. A Staff-level answer also names the case where the split loses: tasks whose steps depend tightly on each other, where parallel agents make conflicting choices. This page gives you that answer from first principles, with sourced numbers and a worked cost model. For the wider design question, see how to design an AI agent system.
Multi-agent systems from first principles
- Multi-agent system
- A multi-agent system is a software design that splits one task across several LLM agents, each with its own instructions, tools and context window, and combines their outputs under a fixed coordination pattern, so that work can be divided and run side by side.
- Orchestrator-worker pattern
- The orchestrator-worker pattern is a multi-agent design in which one lead agent plans the task, delegates pieces to worker agents that run separately, and then merges their results into a single answer.
- Agent handoff
- An agent handoff is a transfer of control of a conversation or task from one agent to another, together with the context the receiving agent needs, so that the specialist best suited to the next step takes over.
In plain words
Think of a newsroom editor who splits a big story among reporters. Each reporter works alone, with their own notebook, and sends back a short summary. The editor merges the summaries into one article. The analogy breaks in one place: reporters can phone each other, while subagents in the common design cannot see each other's notebooks at all, so the editor must give each one a clear brief.
In one precise sentence, a multi-agent system trades extra tokens for more total capacity, and works only when the pieces are independent enough to be split. A token is a small chunk of text a model reads or writes, and the unit its cost is counted in.
A subagent is a worker agent started by a lead agent for one narrow job. A swarm is a design where peer agents hand work to one another with no single lead. Both are variants of the same idea: several model loops instead of one.
Step 1: The lead agent plans and saves the plan
The lead agent reads the user's request, thinks through an approach and writes a plan. In Anthropic's research system the lead saves its plan to memory because a context window that grows past 200,000 tokens is truncated, and losing the plan would mean losing the thread.
Input: the user's question. Output: a plan and a set of narrow assignments. A good assignment names an objective, an output format, the tools to use and the boundaries of the job. Anthropic reports that vague assignments led subagents to duplicate each other's searches, in one case with two subagents investigating the same supply chains. You now know where the quality of the whole system is set: in the brief the lead writes.
Step 2: Subagents work in separate context windows
Each subagent receives its assignment and nothing else, then runs its own loop of tool calls, such as web searches, in a fresh context window. Separate windows are the reason the design exists: Anthropic found that token usage alone explains 80% of the variance on a browsing benchmark, so several windows add capacity for reasoning that one window cannot hold.
The same separation is the main weakness. Cognition argues for the principle of sharing context and full agent traces, not just individual messages, because actions carry implicit decisions: two subagents that cannot see each other can build parts that clash, such as two pieces of a game with different visual styles. Shared context is therefore the term to name. Where the pieces depend on each other, separate windows cost correctness, not just tokens.
Step 3: Results return and the lead synthesizes
Each subagent returns a short result to the lead, which merges the results into one answer. Input: several summaries. Output: one answer, plus any gaps the lead notices. Anthropic describes the lead as coordinating while subagents operate in parallel, and notes that, as of June 2025, its lead agents run subagents synchronously, meaning the lead waits for a batch to finish before continuing. That is simple, but the lead cannot steer a running subagent, and one slow subagent can block the whole system.
A handoff differs from this fan-out. In an agent handoff control moves to another agent and stays there, as when a general support agent passes a billing problem to a billing agent. In orchestrator-worker control returns to the lead. Both are "multiple agents", but they route work differently, which is why interviewers ask which one you mean.
Step 4: The lead checks the result and stops or plans again
The lead decides whether the combined result answers the question. If a gap remains, it writes new assignments and the loop repeats; if not, it finishes. Without a limit this loop can overspend, so the lead needs a rule for effort. Anthropic embedded scaling rules in its prompts: simple fact-finding needs one agent with 3 to 10 tool calls, a direct comparison might need 2 to 4 subagents with 10 to 15 calls each, and complex research might use more than 10 subagents. It reports that overinvesting in simple queries was a common early failure.
You now have the whole mechanism: plan, delegate in separate windows, synthesize, check. Notice what is missing: the agents do not chat. They communicate only through the assignments going down and the summaries coming back, so those two messages carry all the coordination.
Step-by-step description
- The lead agent plans and saves the plan.
- Subagents work in separate contexts.
- Results return and merge into one answer.
- The lead stops or plans again.
- The lead agent saves its plan to memory before delegating.
- Each subagent works in its own context window.
- The lead agent synthesizes the returned results into one answer.
- The lead agent then stops or plans again.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
How much more does a multi-agent system cost, and what does the extra cost buy? Anthropic reports that in its data agents typically use about 4 times the tokens of a chat interaction and multi-agent systems about 15 times, and that its lead-plus-subagents system beat a single-agent model by 90.2% on its internal research evaluation.
Dividing the two averages gives about 3.75 times the tokens of a single agent, a ratio of two separate averages rather than one measured comparison.1 The 90.2% compares a lead on Opus 4 with Sonnet 4 subagents against a single-agent Opus 4 on Anthropic's internal research evaluation, so the token and quality figures describe different set-ups and cannot be divided into a cost-per-quality figure. The system is worth its bill only when the task's value covers it, which is Anthropic's own condition.
| Fact | Value (Anthropic Engineering, 2025-06-13) |
|---|---|
| Tokens versus chat, single agent | about 4 times (source) |
| Tokens versus chat, multi-agent | about 15 times (source) |
| Gain over single-agent Opus 4 on its internal research evaluation | 90.2% (source) |
| Share of browsing-benchmark performance variance explained by token usage | 80% (source) |
| Context length beyond which the lead's context is truncated | 200,000 tokens (source) |
| Effort rule for simple fact-finding | 1 agent, 3 to 10 tool calls (source) |
Next an illustrative cost model of one delegated research task: a lead using 8,000 tokens in total, each subagent 40,000 tokens, and each returned summary 2,000 tokens that the lead reads.1
| Subagents | Tokens, separate contexts (illustrative) | Tokens, with a 30,000-token shared trace each | Minutes in parallel | Minutes one after another |
|---|---|---|---|---|
| 1 | 50,000 | 80,000 | 5 | 5 |
| 3 | 134,000 | 224,000 | 5 | 13 |
| 5 | 218,000 | 368,000 | 5 | 21 |
| 10 | 428,000 | 728,000 | 5 | 41 |
A shared trace of 30,000 tokens per subagent (illustrative) lifts the 10-subagent total to 728,000.1 Read the two columns together. Parallel work buys speed, because the slowest subagent sets the wall time (4 minutes each plus 1 for the lead, illustrative). Following Cognition's advice to share full context costs tokens on every subagent, so the cheaper design is often fewer agents, not more.1
Text description of the diagram
- With separate contexts the illustrative model uses 50,000 tokens for 1 subagent and 428,000 for 10.
- A shared trace of 30,000 tokens per subagent lifts the 10-subagent total to 728,000.
Trade-offs and edge cases
When does a multi-agent system win, and when does it lose? It wins on breadth-first work with independent branches and information that exceeds one context window. Anthropic reports that the design is a poor fit where all agents must share the same context or have many dependencies, and gives most coding tasks as an example. Cognition recommends, by default, ruling out architectures that break its two principles, and suggests the simplest compliant design is a single-threaded linear agent.
The three common designs differ mainly in who controls the work and how much context each agent sees. A single agent keeps one continuous context, which suits tightly dependent steps. An orchestrator-worker system splits independent branches across subagents with separate contexts. A swarm passes control between peer agents by handoff.
Text description of the diagram
- A single agent keeps one continuous context, which suits tightly dependent steps.
- An orchestrator-worker system splits independent branches across subagents with separate contexts.
- A swarm passes control between peer agents by handoff.
Edge cases an expert raises:
- Long tasks on one agent. When a single agent's history overflows its window, Cognition describes adding a model that compresses the history into key details and decisions, and warns this is hard to get right. See why agents fail on long tasks and context rot.
- Errors compound. Anthropic notes agents are stateful and a restart from the beginning is expensive, so it resumes from where an error occurred and uses gradual rollouts so running agents are not disrupted.
- Evaluation is harder. Final-answer checks miss a bad process; see evaluating agents.
- People in the loop. High-stakes steps may need approval; see human in the loop AI agents.
How to answer it in an interview
When would you use a multi-agent system instead of a single agent?
I would use one when the task splits into independent branches, like researching many sources, or when the information exceeds one context window. I would use an orchestrator-worker design: a lead plans, subagents work in separate contexts, and the lead synthesizes. The cost is tokens, reportedly around fifteen times a chat, and tasks with tight dependencies can break because subagents make conflicting assumptions. So I would start with one agent and a good evaluation, and add agents only when the measured gain justifies the cost.
The spoken structure: say when it fits, name the pattern, state the cost, name the failure, then say you would measure before adding agents.
Common mistakes
- "More agents is always better." (wrong) Each subagent adds tokens, and dependent steps can conflict. (right) "I add agents only where branches are independent and the measured gain covers the cost."
- "Multi-agent is just retrieval-augmented generation (RAG)." (wrong) Retrieval fetches text for one model call; a multi-agent system runs several loops that each decide what to do next. (right) "Retrieval is a step an agent can use; the multi-agent part is the delegation."
- "The agents chat until they agree." (wrong) In the orchestrator-worker design they never talk to each other. (right) "Coordination travels through the assignment and the returned summary."
- "I need a framework." (wrong) A framework is a convenience, not a requirement. (right) "I compare frameworks on state handling and control flow; see LangGraph vs CrewAI vs AutoGen."
Follow-up questions
How do agents communicate and coordinate in a multi-agent system?
In orchestrator-worker, only through messages the lead writes and the summaries returned; a plan saved to memory persists across context limits. In a swarm or handoff design, the active agent passes control and context to the next. Tool and data access is a separate layer, covered by the Model Context Protocol (MCP).
When would you use a multi-agent swarm instead of a single LLM with multiple tools?
Use a swarm when the work is a routing problem between distinct specialties, each needing its own instructions and tools, so a single prompt with every tool becomes crowded. If one agent with a few tools handles it, stay with one.
What are the risks of using multi-agent systems in production, and how do you mitigate them?
The risks are token cost, duplicated or conflicting work, long-running state and blocking on slow subagents. Mitigate with effort rules in the lead's prompt, clear assignments, full traces where steps depend on each other, resumable execution and process-level evaluation.
Should you build agent orchestration yourself or use a framework?
Build it yourself when the control flow is a short loop you fully understand; use a framework when you need durable state, branching and tracing you would otherwise rewrite. Decide on those needs, not on popularity.
A multi-agent system beats your simple RAG pipeline by 15% on the benchmark. Do you ship it?
Not on that number alone. Ask what it costs per request, how latency and failures behave, whether the benchmark matches real traffic, and whether the gain holds on the hard cases. Ship if the value covers the cost and the failures are acceptable.
What protocols govern how agents hand off work in a multi-agent system, and when does naive multi-agent lose?
As of October 2026 there are two layers. The Model Context Protocol connects an agent to tools and data. Agent2Agent (A2A) is an open protocol for agent-to-agent messaging and task handoff, announced by Google on 2025-04-09. Inside one application, a handoff is commonly a tool call that transfers control: in OpenAI's Agents software development kit (SDK), "Handoffs are represented as tools to the LLM". Naive multi-agent loses when parallel agents act on assumptions they cannot see. More questions of this kind are in agentic AI interview questions.
- A multi-agent system splits one task across several agents, each with its own context window.
- Orchestrator-worker is the common pattern: the lead plans, subagents work, the lead synthesizes.
- Reported gains are large on breadth-first research, and so is the token bill.
- Shared context decides success: dependent steps need full traces or a single agent.
- Start simple, measure, and add agents only when the gain covers the cost.
Sources
- How we built our multi-agent research system — Anthropic Engineering, 13 Jun 2025
- Don't Build Multi-Agents — Cognition (Walden Yan), 12 Jun 2025
- Building effective agents — Anthropic Engineering, 19 Dec 2024
- A2A: a new era of agent interoperability — Google Developers Blog, 9 Apr 2025
- Handoffs - OpenAI Agents SDK — OpenAI, 26 Oct 2026
