Multi-Agent Patterns

TL;DR — “Multi-agent” is four or five different architectures wearing one name: supervisor/orchestrator-workers, routing, swarm/handoff, debate, and pipeline. They share one property: you pay for coordination in tokens, latency, and new failure modes, and you buy breadth — the ability to explore many independent directions at once, and to hold more total context than one window. The honest answer to “should I split this into multiple agents?” is usually no. Anthropic’s own production numbers are about 4x tokens for a single agent and about 15x for a multi-agent system versus a chat turn, and the best-documented failure taxonomy (MAST, arXiv:2503.13657) finds that multi-agent systems’ gains on popular benchmarks are “often minimal”. Split when the task is breadth-first, parallelisable, and exceeds one context window, and the outcome is worth 15x the spend. Do not split to fix a weak single agent.

1. Why this exists

Consider a genuinely hard research question: “how have EU AI Act obligations changed what model providers publish about training data between 2024 and 2026?” Answering it well means reading a dozen sources across several jurisdictions, and holding all of them in view while you compare.

A single agent fails at this in a specific way. Its context is a budget, and a dozen long documents exceed it; so it either truncates (losing the early sources by the time it reaches the late ones), or compacts them into summaries (losing the exact clause numbers that make the comparison possible), or it searches sequentially and never gets past source three. The failure is not reasoning. It is that one context window cannot hold the working set, and the model cannot hold two independent lines of investigation in the same head without them contaminating each other.

Multi-agent systems attack exactly that: give each line of investigation its own context window, run them concurrently, and return only distilled summaries to the coordinator. Anthropic’s description of the mechanism is precise: “Subagents facilitate compression by operating in parallel with their own context windows, exploring different aspects of the question simultaneously before condensing the most important tokens for the lead research agent” (How we built our multi-agent research system, 2025-06-13). The post does not publish a token figure for how large that condensed summary is — treat any specific number you see quoted as unsourced.

That is a real capability, and it is the only one in this chapter. Everything else — “agents that debate”, “a team of specialists”, “swarm intelligence” — is a coordination topology, and coordination has a price. The failure mode to hold in mind is this one, from the same write-up:

“one subagent explored the 2021 automotive chip crisis while 2 others duplicated work investigating current 2025 supply chains, without an effective division of labor.”

Fifteen times the tokens, and two thirds of the work bought nothing. That is not a badly tuned system; that is the default outcome of adding agents without adding a delegation contract. The rest of this chapter is about when the extra spend is justified and how to keep it from being wasted.

2. How it works

2.1 The taxonomy, and which entries are actually agents

Anthropic’s Building effective agents draws the line this chapter follows: workflows are “systems where LLMs and tools are orchestrated through predefined code paths”; agents are “systems where LLMs dynamically direct their own processes and tool usage”. Most “multi-agent systems” in the wild are workflows with LLM-flavoured nodes. Naming which one you have is the first interview question.

Only the last four are multi-agent in any meaningful sense. The distinction between supervisor and pipeline is the one that matters economically: parallelisation decomposes subtasks you defined, while the orchestrator’s decomposition is “determined by the orchestrator based on the specific input”. The first is deterministic and cheap to reason about; the second is the thing that produces “spawning 50 subagents for simple queries”.

Debate deserves one specific note, because it is the pattern with the cleanest evidence. It is not Self-Refine with a different name: in debate the critics are independent instances with independent contexts (Du et al., arXiv:2305.14325), so their errors are correlated only through the base model, not through a shared transcript. That independence is the entire source of the gain. A “critic” that shares the generator’s context sees the generator’s mistakes as reasonable, because it shares the reasoning that produced them.

flowchart TB
    U["user query"] --> L["lead / orchestrator"]
    L -->|"brief 1"| W1["worker: jurisdiction A"]
    L -->|"brief 2"| W2["worker: jurisdiction B"]
    L -->|"brief 3"| W3["worker: jurisdiction C"]
    W1 -->|"summary ~1-2k tokens (example)"| L
    W2 -->|"summary ~1-2k tokens (example)"| L
    W3 -->|"summary ~1-2k tokens (example)"| L
    L --> A["synthesis + citation check"]
    A --> OUT["final answer"]

2.2 The coordination cost model

This is the section to be able to reproduce on a whiteboard, because every honest claim about multi-agent is a special case of it.

(a) Tokens multiply, and the multiplier is structural

Let there be $A$ agents (one lead, $A-1$ workers). Agent $k$ runs $N_k$ hops with a private fixed prefix $C_{0,k}$ (system prompt, tool schemas) and per-hop growth $a_k+o_k$. From the single-agent model:

$$T_{\text{multi}}=\sum _{k=1}^A\left[N_k{C}_{0,k}+(a_k+o_k)\frac{N_k(N_k-1)}{2}\right]+T_{\text{deleg}}+T_{\text{merge}}$$

• $A$ — the agent count. This is the term you control directly, and it is the one people increase for the wrong reason.
• $C_{0,k}$ — each agent’s private fixed prefix. This is the non-obvious cost: every worker needs its own system prompt, tool list, and copy of the context it was given. Nothing is shared between contexts, so the same instructions are paid for $A$ times. Doubling agents roughly doubles the baseline token rate before any work happens.
• $\frac{N_k(N_k-1)}{2}$ — the quadratic re-read term from the per-hop loop. Parallelism does not remove it; it just distributes it.
• $T_{\text{deleg}}$ — tokens in the task briefs the lead writes. Small individually, but the lead pays to generate them and every worker pays to read one.
• $T_{\text{merge}}$ — tokens the lead spends reading and reconciling summaries. If each of $W$ workers returns $s$ tokens, the lead’s context grows by $Ws$, so this term is linear in workers and lands inside the lead’s own quadratic loop on the next hop.

The 4x and 15x. Anthropic reports that “agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats”. Read those as two points on this formula: 4x is essentially $N\approx 4$ hops with a fixed prefix; 15x adds the $A$-fold prefix duplication and the delegation/merge overhead on top. They are vendor-internal measurements, not a controlled benchmark, and the exact figure depends on what you call a “chat interaction” — but the shape (linear in agents, quadratic in hops) is what you should carry, not the constant.

(b) Latency divides, then hits the critical path

Let $S$ be the number of sequential rounds (a round is one delegation wave plus one merge), $t_{\text{lead}}(r)$ the lead’s own compute in round $r$, and $t_i(r)$ the wall-clock of worker $i$ in round $r$. Then:

$$T_{\text{wall}}=\sum _{r=1}^S\left[t_{\text{lead}}(r)+\underset{i\in W_r}{\max }{t}_i(r)+t_{\text{sync}}(r)\right]$$

• $S$ — the round count. This is the number that kills the “just add agents” intuition: a supervisor with $S$ sequential rounds is at best $S$ times one round, regardless of how many workers exist.
• ${\max }_i{t}_i(r)$ — the slowest worker. Concurrency divides the sum of worker times by the achievable parallelism, but the round cannot finish until its slowest member does. Adding workers helps until the maximum stops moving; after that it only adds coordination.
• $t_{\text{sync}}(r)$ — the barrier cost: the lead must wait for the whole wave before writing the next briefs. Anthropic’s system is explicit that this is a bottleneck: “our lead agents execute subagents synchronously, waiting for each set of subagents to complete before proceeding. This simplifies coordination, but creates bottlenecks … the entire system can be blocked while waiting for a single subagent to finish searching.”
• $t_{\text{lead}}$ — the lead is not parallel with itself. Every round pays its full latency.

Anthropic’s reported lever is exactly this formula: spinning up 3–5 subagents in parallel and having each use 3+ tools in parallel “cut research time by up to 90% for complex queries” — that is reducing $S$ and maximising the $i$ that can run concurrently, not reducing total work. The work went up.

(c) Errors compound multiplicatively, and redundancy is what buys them back

If $k$ steps are independent and each succeeds with probability $p$, the whole chain succeeds with probability $p^k$:

• $p=0.95$, $k=5$: $0.774$
• $p=0.95$, $k=10$: $0.599$
• $p=0.99$, $k=10$: $0.904$

The mechanism is documented: “Agents are stateful and errors compound … One step failing can cause agents to explore entirely different trajectories, leading to unpredictable outcomes” (Anthropic). This is why a multi-agent system that only fans out is worse than it looks — it multiplies the number of steps that must all go right.

The counter-argument is also arithmetic. If you run $n$ independent attempts with per-attempt success $p$ and take a majority vote, the probability that the majority is correct is:

$$\mathrm{Pr}[\text{majority correct}]=\sum _{j=\lceil n/2\rceil }^n\left(\genfrac{}{}{0ex}{}{n}{j}\right)p^j(1-p{)}^{n-j}$$

• $n$ — the number of attempts. It is odd in practice so there is no tie.
• $p$ — per-attempt success, and crucially the attempts must be independent: same model, same prompt, temperature 0 gives $p$ for all of them and voting changes nothing.
• $\left(\genfrac{}{}{0ex}{}{n}{j}\right)p^j(1-p{)}^{n-j}$ — the probability of exactly $j$ correct attempts out of $n$.

For $p=0.95$ and $n=3$, the majority-correct probability is $\mathrm{Pr}[\ge 2\text{ correct}]=3(0.95{)}^2(0.05)+(0.95{)}^3=0.135+0.857=0.993$. Three attempts move a single step from 95% to 99.3% — at 3x the tokens for that step. That is the real trade debate and voting make: you buy reliability with tokens, and only if the attempts are genuinely independent. Nothing else about debate is special.

(d) Coordination cost grows faster than the work

Token and latency cost are not the worst terms. The undocumented one is communication complexity: with $A$ agents, the number of pairwise channels is

$$E=\frac{A(A-1)}{2}$$

For $A=4$ that is 6 channels; for $A=10$, 45; for $A=50$, 1,225. Every channel is a place where two agents can hold contradictory state, duplicate work, or block on each other. Anthropic’s observed early failures are exactly this: “spawning 50 subagents for simple queries, scouring the web endlessly for nonexistent sources, and distracting each other with excessive updates”; their fix was to encode explicit effort budgets — “Simple fact-finding requires just 1 agent with 3-10 tool calls, direct comparisons might need 2-4 subagents with 10-15 calls each, and complex research might use more than 10 subagents with clearly divided responsibilities.”

The other term people miss is the handoff loss. The lead sees only each worker’s summary, not its context. If a worker consumed $c$ tokens of real evidence and returns $s$ tokens, the lead’s view of that line of investigation has been compressed by roughly $c/s$ — with $c=30,000$ and $s=1,500$ (example), a factor of 20. Everything that got compressed is unavailable to the synthesis step and to any later worker. This is the “game of telephone” problem, and Anthropic’s fix is architectural, not prompt-level: subagent outputs “persist independently … then pass lightweight references back to the coordinator” — write the artifact to a filesystem, pass the path, let a later agent read it in full.

2.3 The uncomfortable finding: the gain is largely token spend

Anthropic measured what actually drove performance in their own system, and the answer is not architecture:

“three factors explained 95% of the performance variance in the BrowseComp evaluation… token usage by itself explains 80% of the variance, with the number of tool calls and the model choice as the two other explanatory factors.” (vendor-internal evaluation)

Read that carefully, because it reframes the whole chapter. Multi-agent systems “win” on breadth-first research partly because they spend 15x more tokens. A single agent given the same 15x budget — more search calls, more retries, a longer loop — captures some unknown fraction of the same gain. Their headline result, that a multi-agent system with Claude Opus 4 as lead and Claude Sonnet 4 subagents “outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval”, is a vendor-internal number on an internal eval, and it is not token-matched.

The consequence for your evaluation, stated as a rule. Any multi-agent result you report must be compared against a single agent with the same token budget. Otherwise you have measured buying more compute, not a better architecture.

2.4 What the empirical work actually shows

The best-evidenced statement is “Why Do Multi-Agent LLM Systems Fail?” (Cemri et al., arXiv:2503.13657, NeurIPS 2025 Datasets and Benchmarks). It built MAST-Data (1,600+ annotated traces across 7 multi-agent frameworks) and derived MAST — 14 failure modes in 3 categories (system design issues, inter-agent misalignment, task verification) from 150 traces with “high inter-annotator agreement (kappa = 0.88)”. Its headline:

“Despite enthusiasm for Multi-Agent LLM Systems (MAS), their performance gains on popular benchmarks are often minimal.”

Two caveats on how to use this. First, the 14 individual mode names are not in the abstract, and I have not verified them from the full text — cite the shape (3 categories, kappa 0.88, 1,600+ traces) rather than inventing names. Second, “often minimal” is a distribution, not a universal: the paper is compatible with large wins in the right regime (breadth-first, parallelisable, long-horizon) and near-zero or negative returns elsewhere.

The defensible summary sentence, and the one to say in an interview: multi-agent helps when the task is breadth-first, parallelisable, and exceeds one context window, the subagents’ work is genuinely independent, and the outcome value justifies roughly 15x the token spend. It hurts on tightly-coupled, sequential, shared-context tasks — and it does not fix a weak single agent. Anthropic says the last part themselves: coding tasks have “fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time”, so “these architectures burn through tokens fast.”

3. Implementation

The pattern worth writing out is the supervisor with dynamic fan-out, because it is the one whose cost model matches section 2.2. Two implementations: the LangGraph one you would actually run, and the plain-SDK shape so you can see what the framework is doing.

3.1 A delegation contract, before any code

Every subagent brief needs four fields, and their absence is the documented cause of duplicated work:

Anthropic’s phrasing: each brief needs “an objective, an output format, guidance on the tools and sources to use, and clear task boundaries.”

3.2 Supervisor fan-out in LangGraph

Against langgraph==1.2.15 [as of 2026-10]. Send is what makes dynamic map-reduce expressible: a normal edge gives every destination the same state, while Send(node, state) gives each worker its own input, which is exactly the “each worker gets a different brief” requirement.

# pip install "langgraph==1.2.15" "langchain==1.4.5" "langchain-openai"
import operator
from typing import Annotated, Literal
from typing_extensions import TypedDict

from langchain.chat_models import init_chat_model
from langchain.messages import HumanMessage, SystemMessage
from langgraph.graph import END, START, StateGraph
from langgraph.types import Send
from pydantic import BaseModel, Field

lead = init_chat_model("openai:gpt-5.5", temperature=0)
worker = init_chat_model("openai:gpt-5.5-mini", temperature=0)  # cost tiering


class Brief(BaseModel):
    """The delegation contract. Structured output forces all four fields."""
    objective: str = Field(description="What a complete answer contains.")
    output_format: str = Field(description="The exact shape to return.")
    tools: list[str] = Field(description="Which tools may be used.")
    boundary: str = Field(description="What this worker must NOT cover.")


class Plan(BaseModel):
    briefs: list[Brief]


class State(TypedDict):
    question: str
    plan: list[Brief]
    # fan-in: every worker writes one summary; operator.add merges them
    findings: Annotated[list[str], operator.add]
    answer: str


def plan(state: State) -> dict:
    """The supervisor decomposes the question into non-overlapping briefs."""
    prompt = (
        "Break this research question into 2-4 non-overlapping sub-questions. "
        "Each must be answerable independently, with no shared sources needed. "
        "Prefer fewer, broader briefs over many narrow ones.\n\n"
        f"{state['question']}"
    )
    result = lead.with_structured_output(Plan).invoke([HumanMessage(prompt)])
    return {"plan": result.briefs}


def fan_out(state: State) -> list[Send]:
    """Dynamic map: one worker per brief, each with its own input state."""
    return [Send("worker", {"question": state["question"], "brief": b})
            for b in state["plan"]]


def worker_node(state: dict) -> dict:
    """One isolated context. It never sees the other workers or the lead's plan."""
    b: Brief = state["brief"]
    result = worker.invoke([
        SystemMessage(
            f"Objective: {b.objective}\n"
            f"Return format: {b.output_format}\n"
            f"Allowed tools: {', '.join(b.tools)}\n"
            f"Out of scope: {b.boundary}\n"
            "Return only the summary. Do not editorialise."
        ),
        HumanMessage(state["question"]),
    ])
    return {"findings": [f"[{b.objective}]\n{result.content}"]}


def synthesise(state: State) -> dict:
    """The lead reads only summaries. This is where handoff loss shows up."""
    joined = "\n\n".join(state["findings"])
    result = lead.invoke([
        SystemMessage("Synthesise. Flag any claim not supported by a finding."),
        HumanMessage(f"Question: {state['question']}\n\nFindings:\n{joined}"),
    ])
    return {"answer": result.content}


builder = StateGraph(State)
builder.add_node("plan", plan)
builder.add_node("worker", worker_node)
builder.add_node("synthesise", synthesise)

builder.add_edge(START, "plan")
builder.add_conditional_edges("plan", fan_out)                # dynamic map
builder.add_edge("worker", "synthesise")                      # barrier: fan-in
builder.add_edge("synthesise", END)

graph = builder.compile()
result = graph.invoke({"question": "...", "plan": [], "findings": [], "answer": ""})

Two model handles, one lead and one worker, are the cost-tiering lever from section 4.3; the specific worker model above is illustrative (example) — the point is that planning and synthesis run on the strong model while narrow extraction runs on a cheaper one, which Anthropic lists as a real use of routing.

Every element, and why it is there:

3.3 What it looks like without the framework

The whole thing is one function if you write it yourself. This is pseudocode — there is no single canonical SDK for it:

def multi_agent(question: str, max_workers: int = 4) -> str:
    plan = lead.structured(PLAN_SCHEMA, question)
    assert len(plan.briefs) <= max_workers
    # concurrency, not for-loop: the latency model in 2.2(b) is about max(), not sum()
    findings = run_concurrently([lambda b=b: worker.run(brief=b) for b in plan.briefs],
                                max_concurrency=max_workers)
    return lead.synth(question, findings)

Two things to notice. First, the value the framework added was the reducer and the checkpointer, not the fan-out — asyncio.gather with a semaphore is the whole parallel part. Second, there is no persistence here: kill the process and all four workers’ work is gone. That is the trade from LangGraph reappearing at the multi-agent level.

4. Numbers and trade-offs

4.1 Deriving the multiplier on a concrete task

Take a breadth-first research task. Suppose the single-agent version runs $N=6$ hops with $C_0=2,500$ tokens of system prompt and tools, and per-hop growth $a+o=600$. From the single-agent formula:

$$T_{\text{single}}=6\times 2500+600\times \frac{6\times 5}{2}=15,000+9,000=24,000$$

Now split it into $A=4$ agents: one lead plus three workers. Give each worker the same $C_0=2,500$ (its own prompt and tools — nothing is shared), and let each run $N_k=4$ hops with the same per-hop growth:

$$T_{\text{workers}}=3\left[4\times 2500+600\times \frac{4\times 3}{2}\right]=3\left[10,000+3,600\right]=40,800$$

The lead then plans (say 1,200 output tokens), reads three 1,500-token summaries (4,500 input), and synthesises (1,500 output), across 3 hops with its own prefix: roughly $3\times 2500+1,200+4,500+1,500\approx 14,700$. Total $T_{\text{multi}}\approx 55,500$ tokens, or about 2.3x the single agent and about 15x a single chat turn of ~3{,}500. Those are illustrative figures (example) that illustrate the structure, not measurements: the multiplier is dominated by $A\times C_0$, so agent count is a cost lever before it is a capability lever.

4.2 The break-even question

Multi-agent is worth it when the quality gain exceeds the cost gain. Write $q_{\text{multi}}$ and $q_{\text{single}}$ for success rates and $T_{\text{multi}}$, $T_{\text{single}}$ for solved-task token cost. If a solved task is worth $V$ and tokens cost $c$ per token, multi-agent wins when:

$$V\left(q_{\text{multi}}-q_{\text{single}}\right)>c\left(\frac{T_{\text{multi}}}{q_{\text{multi}}}-\frac{T_{\text{single}}}{q_{\text{single}}}\right)$$

• $V$ — the value of a solved task. This is why research and due-diligence queries tolerate 15x and chat assistants do not: $V$ differs by orders of magnitude, while the token multiplier is a small constant.
• $q$ — success rates, and the division by $q$ is the part people forget: a system that costs 3x and succeeds 80% of the time costs more per success than it looks.
• $c$ — cost per token, which is why cost tiering (a cheaper model for workers) is one of the highest-leverage moves in the pattern.

With $V$ large this inequality is easy to satisfy; for a conversational assistant where $V$ is a few cents, it is essentially never satisfied. The inequality is the whole “usually no” answer, in one line.

4.3 Which axis you are optimising

4.4 The context transfer ratio

Let a worker consume $c$ tokens of raw evidence and return a summary of $s$ tokens. The lead’s information about that line of investigation drops by a factor of about $c/s$. With $c=30,000$ and $s=1,500$ (example) that is 20x. For three workers, the lead’s entire view of the research is roughly 4,500 tokens standing in for 90,000. Two consequences:

1. A bigger lead context does not fix this. The compression happens at the handoff, before the lead sees anything.
2. The fix is to change what crosses the boundary, not to summarise more carefully: pass file paths, document IDs, or structured records, and let the lead (or a later worker) re-read the source in full when it matters. This is just-in-time context applied to the delegation boundary.

5. Pitfalls

Duplicated work. Symptom: two workers return the same sources under different headings; total tokens are up, coverage is not. Cause: briefs without boundaries. Fix: the four-field contract, plus non-overlap checks in the planner prompt.

The orchestration loop degenerates. Symptom: the lead spawns 50 subagents for a question three searches would answer, or keeps spawning more as each result raises new questions. Cause: no effort budget. Fix: put explicit rules in the orchestrator prompt (“1 agent, 3-10 calls for fact-finding; 2-4 subagents for comparisons; >10 only for open-ended research”) and a hard cap in code.

The telephone game. Symptom: the final answer is fluent and vague; specific numbers and clause references present in the workers’ raw material are absent. Cause: summarisation at every handoff. Fix: subagents write artifacts and return references.

Error compounding. Symptom: one worker’s bad result produces a confidently wrong synthesis, and the trace shows the lead treating a summary as a verified fact. Cause: no verification layer, and $p^k$ doing its work. Fix: a separate verification node, or voting on the steps that matter.

Correlated “independent” agents. Symptom: debate or voting changes nothing. Cause: the agents share a context or run at temperature 0, so their errors are identical and the majority is unanimous. Fix: genuinely separate contexts; check that the attempts disagree sometimes.

Optimising the wrong axis. Symptom: latency did not improve after adding workers, and cost tripled. Cause: the workers are gated behind a synchronous barrier or a sequential round structure. Check ${\max }_i{t}_i$ and $S$ before adding $A$.

No end-state verification. Symptom: evaluators argue about whether the path was “correct” while the answer is plainly wrong. Cause: evaluating the trajectory. Anthropic’s guidance: “we usually can’t just check if agents followed the ‘correct’ steps … focus on end-state evaluation rather than turn-by-turn analysis.”

Cost blowout discovered late. Symptom: the invoice, not a metric, is what tells you the system is misbehaving. Cause: no per-task token budget enforced in code. See the LLM10 discussion in Guardrails.

Fixing a weak single agent by adding agents. Symptom: every configuration performs about the same, at 15x cost. Cause: the bottleneck was the tool set, the prompt, or retrieval. Measure the single agent with the same token budget first.

6. Using it in a project

The honest answer to “should you split this into multiple agents?”

Usually no. Run this decision procedure in order, and stop at the first “no”:

1. Does the task exceed one context window in evidence, not just in length? If the whole working set fits in a window, a single agent with a bigger budget is simpler and cheaper. If it fits after good retrieval, fix retrieval — see The RAG Pipeline.
2. Are the sub-tasks genuinely independent? If they need the same sources, the same conversation state, or each other’s intermediate results, they are not parallel work; they are one piece of work you are about to pay for several times.
3. Is it breadth-first? Multiple directions explored, then compared. If the task is a sequence of dependent steps, a pipeline or a single agent wins.
4. Can you write a delegation contract? If you cannot say what each worker’s objective, format, tools, and boundaries are, the workers will duplicate work.
5. Will you measure against a token-matched single agent? If not, you cannot tell a real gain from extra spend.
6. Is the outcome valuable enough? Section 4.2’s inequality, with a real $V$.

If all six are yes, split. In practice, on product-engineering tasks, step 2 or 3 fails.

Reach for multi-agent when

• Breadth-first research or due diligence where sources are independent and the answer is a synthesis.
• Genuinely parallel tool work: check 40 hosts, summarise 40 tickets, run 40 eval cases. The decomposition is obvious and the work is independent.
• Cost tiering with a cheap worker model: a strong lead that plans and a cheap model that extracts is often the real win, not the parallelism.
• A second opinion on a high-stakes decision, with independent contexts and a judge — the debate pattern, sized at 3, not 30.

Do not use multi-agent when

• The task is sequential. Every “and then, based on that” step is a barrier you pay for at full latency.
• The sub-tasks share context. Shared context across agents means duplicated context in every worker, which is the $A\times C_0$ term with no benefit.
• You have not fixed the single agent. Tool descriptions, prompt altitude, and retrieval quality dominate before architecture does.
• Your budget is per-request and small. 15x is not negotiable down with clever prompting.
• You cannot observe the system. Trajectories diverge between runs even with identical prompts, so without full tracing you cannot debug or evaluate. See Memory and Context Management for what to log.
• A single agent with a subagent tool would do. One agent that can spawn one helper is often the right amount of structure.

The default recommendation. Start with one agent, give it a bigger token budget and better tools, and measure. Split only when a measurement says the bottleneck is context isolation or real parallelism — and split into two or three.

7. How you would prove it worked

Multi-agent claims are easy to fake and easy to test honestly. The three rules: compare against a token-matched single agent, evaluate the end state, and report cost per solved task.

Baselines. Two, not one:

Metrics.

The ablation that matters. Take the multi-agent system and replace the parallel workers with a single agent given the same total token budget. If the multi-agent version does not beat it, you have measured spend. This is a direct consequence of the “token usage explains 80% of the variance” finding, and it is the first thing a strong interviewer will ask for.

Fault injection. Kill one worker mid-run and confirm the supervisor degrades gracefully rather than producing a confident synthesis from two of three findings. A system that silently answers with missing evidence is worse than one that fails.

Reporting template (example — replace with your own numbers). “On 200 breadth-first research tasks, single-agent success was 54% at 24k tokens/task; the token-matched single agent reached 61%; the 4-agent supervisor reached 68% at 57k tokens (example). Cost per solved task rose 22% (example). We shipped the supervisor only for the agentic research feature, where the task value justifies it, and kept the single agent everywhere else.”

8. Interview drill

“Should you split this into multiple agents?” Strong answer: usually not. Multi-agent buys breadth and context isolation, and costs roughly 15x tokens plus a new class of coordination failure. Run the decision: does it exceed one context window, are the sub-tasks genuinely independent, is it breadth-first, can you write a delegation contract, will you token-match the baseline? If any is no, stay single. Common wrong answer: “yes, one agent per role” — role-play is not decomposition, and a “researcher / writer / critic” trio on a shared context often performs worse than one agent with a bigger budget because the critic shares the author’s blind spots.

“What does multi-agent actually buy you?” Strong answer: two things — concurrent exploration of independent directions, and total context larger than one window, because each subagent explores in its own context window and returns only a condensed summary to the lead. The published write-ups do not give a token figure for that summary, so quote the mechanism, not a number. Everything else is coordination overhead. Common wrong answer: “better reasoning” — there is no mechanism for that. If anything, error compounding makes it worse unless verification is added.

“You get a 90% improvement from multi-agent. Is it real?” Strong answer: not until it is token-matched. Anthropic’s own analysis found “token usage by itself explains 80% of the variance” in their BrowseComp evaluation, and their 90.2% figure is a vendor-internal eval against a single-agent baseline with a different budget. Compare against one agent given the same tokens. Common wrong answer: quoting the 90.2% as a benchmark result.

“How do errors behave as you add steps?” Strong answer: multiplicatively, $p^k$: at $p=0.95$ and $k=10$ the chain succeeds about 60% of the time, and a single failure can send the agent down an entirely different trajectory. Redundancy and verification are how you buy the reliability back — majority vote over $n$ independent attempts. Common wrong answer: “errors average out with more agents” — they correlate, because the agents share a base model and often a context.

“Why does majority voting help sometimes and not others?” Strong answer: it helps when attempts are independent and per-attempt accuracy $p>0.5$; with $p=0.95$ and $n=3$ the majority is correct with probability about $0.993$. It does nothing when the attempts share a context or run at temperature 0, because then the errors are identical and the vote is unanimous. Common wrong answer: “more samples always improve the answer” — it is a conditional claim with two conditions.

“What’s the most common multi-agent failure?” Strong answer: inter-agent misalignment from bad delegation — overlapping or misinterpreted briefs, which is the mechanism Anthropic describes when one subagent chased 2021 while two others duplicated 2025. MAST’s 14 modes fall into three categories — system design, inter-agent misalignment, and task verification — derived from 150 traces with kappa 0.88, and its headline is that benchmark gains are “often minimal”. Common wrong answer: “agents get into infinite loops” — that is a single-agent failure mode, and it is bounded by a step cap.

“Why does the lead agent block the whole system?” Strong answer: rounds are synchronous by design — the lead waits for the whole wave before writing the next briefs, so wall-clock is the sum over rounds of $t_{\text{lead}}+{\max }_i{t}_i+t_{\text{sync}}$. Latency is bounded below by the slowest worker per round, so adding workers helps only until that maximum stops moving. Common wrong answer: “it doesn’t, the subagents are parallel” — the subagents are parallel within a round; the rounds are sequential.

Next: Memory and Context Management — the context budget that makes multi-agent look attractive in the first place, and how to spend it well inside one agent.