Multi-Agent vs Single-Agent: When You Actually Need More Than One

What is the difference between a single-agent and a multi-agent system?

One context window versus several, connected by a serialisation boundary. A single agent keeps every observation in one running history. A multi-agent system splits that history across processes, and the only thing that crosses between them is text somebody wrote to summarise state. That boundary is the entire design decision. Everything else is topology.

Splitting contexts buys two things: each agent keeps a shorter history, and each can carry a different tool set, permission scope and model. It costs one thing: information. Tran and Kiela's 2026 Stanford paper on multi-hop reasoning under equal thinking-token budgets grounds this in the Data Processing Inequality: every inter-agent handoff can only lose information, never create it. Empirically, single-agent systems match or beat multi-agent ones once reasoning tokens are held constant, and reported multi-agent gains are often confounded by the extra test-time compute.

The word that causes most of the confusion is agent. A subagent invoked as a tool, with fixed input and output schemas, that returns once and holds no state, is not a second agent. It is a tool that happens to be implemented with a model call. That pattern is fine, and it is what most successful production systems run. Cognition's public write-up describes the same shape: one main loop carries state, and subagents are stateless workers with narrow scope. If your second agent has a conversation, that is a multi-agent system. If it answers a question and dies, it is a tool.

I build both. AccioMatrix, the AI assessment and interview platform I architected and built solo for 20+ enterprise clients, runs an event-driven backbone orchestrating multiple LLMs, agents and MCP tooling. The genuinely multi-agent parts are where the subtasks are independent and the permission scopes differ. The rest is one loop with a good tool layer. For the loop itself, see how the agent loop actually works in production; the layer it sits inside is layer four of the full AI product architecture reference.

When do you actually need more than one agent?

When at least four of five conditions hold: parallelisable independent subtasks, genuinely different tool or permission scopes, separate context budgets, independent failure isolation, and different models per role. Fewer than four and you are buying coordination overhead with no structural return. This is the whole test, and it takes ten minutes to run.

Run it honestly and most systems score one or two. The most common single yes is parallelism, and usually the wrong kind. Subtasks that could run in parallel but constantly need each other's intermediate results are not independent, they are concurrent. Concurrency without independence is the worst configuration in this design space: you pay the handoff cost, you pay the coordination cost, and you get none of the context-splitting benefit because every branch carries the shared state anyway.

The two conditions that carry the most weight are structural, not economic. Different permission scopes is a real architectural boundary: a research agent holding only read credentials cannot issue a refund even if a tool description tries to talk it into one, whereas a single agent holding every credential is one successful prompt injection away from doing so. Separate context budgets is real when a branch legitimately needs to read 200,000 tokens to produce a 2,000-token conclusion. That is where a subagent as a context firewall is the right instrument, and Anthropic's own Research architecture is built on it: a lead agent spins up three to five subagents that each hold their own window.

The conditions that carry the least weight are the ones people lead with. Different models per role is real, but it is a routing decision, not an agent decision. You can call three models from one loop; that is how routing and caching actually price a request. Failure isolation is real, but a journal with per-step status gives you most of it inside one agent. Score both as half-points if you are being strict.

“A year ago, I would tell people to not build multi-agents and to focus on context engineering fundamentals. Today, many sexy ideas are still impractical, but we have found some setups that actually work.”— Walden Yan of Cognition, whose earlier post Do Not Build Multi-Agents set the default position this article starts from

Why do most multi-agent systems perform worse than one good agent?

Because a handoff is a lossy compression step, and you have inserted several into the middle of a reasoning chain. Tran and Kiela's Stanford paper states this formally through the Data Processing Inequality: under a fixed reasoning-token budget and perfect context utilisation, a single agent is strictly more information-efficient. Empirically, single agents match or beat multi-agent systems on multi-hop reasoning once you control for thinking tokens.

The practical version is more mundane and more damaging. A subagent gets a briefing written by another model, a summary of a summary. It cannot ask a clarifying question without a round trip that costs the lead a full turn. It makes decisions the other branches cannot see. Cognition's second published principle names this: every action implicitly makes a decision, and parallel actions produce conflicting implicit decisions. Two branches independently picking a different date format, customer identifier or scope assumption each produce internally coherent work that does not compose.

The synthesis step is where this turns invisible rather than merely wrong. A lead handed three branch reports produces a fluent, confident, well-structured document whether or not those reports contradict each other. It has no signal that two facts are incompatible, so it picks one, or worse, blends them. The failure mode is a 200 OK with a coherent answer built on an assumption no branch verified, and you catch it with a trajectory eval, not an error rate, because nothing errored.

Then there is the recursion hazard, the one that produces the invoice nobody can explain. If a subagent can spawn subagents, cost multiplies rather than adds. On the model below, one branch is about $0.27; a branch that spawns three of its own is about $1.06; two levels of that is roughly $4. Without a run-scoped global budget shared across every agent in the tree (a global one, not per-agent), there is no mechanical bound at all, and the detection signal is next month's bill.

What does multi-agent actually cost?

Less than one agent when the branches are truly independent, more when they are not, and the crossover is sharp enough to compute. On the model below, a three-way split pays back at about 13 turns of total work if the branches never need each other, and not until about 35 turns if they do. This is the opposite of the usual claim, and worth working through, because the usual claim rests on a comparison that does not hold.

Here is the model, in full. Static prefix per agent: 9,000 tokens for a single agent carrying the whole tool catalogue, 4,500 for a specialist subagent carrying a subset. Shared-state brief re-sent to each subagent every turn: 2,500 tokens when the branches are independent, 9,000 when they are coupled and need the full picture. Task input 400 tokens per turn. History grows 1,650 tokens per completed turn. Output 250 tokens per turn for workers, 600 for the lead. Mid tier at $2 per million input and $10 per million output. Substituting your own numbers takes five minutes and the shape does not change.

Multi-agent can win because the history term is quadratic. A single agent running 60 turns re-sends its whole transcript 60 times: about 3.48 million cumulative input tokens and $7.12. Three agents running 20 turns each re-send three much shorter transcripts: about 1.38 million tokens and $3.15 including the lead. Splitting the context breaks the quadratic term. That is a genuine, structural, arithmetical benefit the do-not-build-multi-agents position tends to skip.

It usually loses anyway because the branches are coupled. Once each subagent needs the full 9,000-token shared brief every turn, and one branch in three has to be re-run because the lead rejected its report, the same 60-turn task costs about $5.53, still below the single-agent $7.12, but now with worse answer quality, four transcripts to debug, and a coordination agent consuming 11% of the total while producing no work of its own. At 30 turns the coupled version is already more expensive than one agent: $2.41 against $2.08.

One more figure worth naming: the fixed floor per extra agent. A specialist subagent carries 4,500 tokens of static prefix plus a 2,500-token brief on each of its nine turns. That is 63,000 tokens, about 12.6 cents at mid-tier pricing, before it does a single piece of useful work. It is the marginal price of the fourth agent on a diagram, charged whether or not the branch contributes anything.

What is the real overhead nobody mentions?

Four things, and only one of them is tokens. Context duplication across agents, the coordination agent itself, a debugging surface that has quietly become a distributed system, and a cost model that multiplies rather than adds. Every architecture post covers the first. Almost none cover the third, which is the one that actually degrades your team's velocity.

Context duplication is the arithmetically obvious one. Every agent needs its own system prompt, its own tool schemas, and enough shared state to work. On the coupled model above that is 13,500 tokens of preamble on every turn of every branch: 526,500 tokens across a three-branch, thirteen-turn-per-branch run, or $1.05 of pure preamble at mid-tier pricing. That is 44% of the run cost spent re-establishing what each agent would already have known as the same agent. The real failure mode is not cost, it is drift. Three copies of a system prompt diverge, and the version skew shows up as branches that disagree about policy.

Coordination is the line that never appears in anyone's estimate. On the model above the lead agent is $0.232 in the independent case and $0.608 in the coupled case, 22% and 25% of the total, and it produces no primary output. It writes briefs, reads reports and synthesises. That is a real service, but price it as one, and compare it against the same tokens spent by a single agent actually doing the work. Its failure mode is the misbriefing above, silent by construction.

The debugging surface is the cost that compounds. A single agent produces one ordered transcript: step 7 did this, cost this, took this long, and the SQL to see it is in the reference architecture's journal schema. A four-agent system produces four transcripts plus the messages between them, and the interesting question is almost always the interleaving. Now you need a correlation identifier propagated through every spawn, a parent-child relationship in your span tree, and a way to reconstruct global ordering from four clocks. That is real distributed-systems work, roughly a week of engineering, and skipping it leaves your on-call engineer with four logs and no way to line them up.

And the cost model multiplies. A per-agent step budget does not bound a tree: three agents each allowed 25 steps is 75 steps, and if any can spawn, it is unbounded. The only mechanism that works is a run-scoped token and dollar budget shared atomically across every agent in the tree, decremented before each call, terminating the run into a named budget_exceeded status at zero. Without it, the detection signal for a runaway tree is the invoice.

$ $ agentctl trace 8f3a --tree --with-cost
run 8f3a  kind=research_brief  status=succeeded  wall=214s  cost=$2.41
├─ lead        14 steps   $0.608   ctx_peak 61k   model=mid
│   step 03  delegate -> branch_a  brief=8,940 tok
│   step 05  delegate -> branch_b  brief=9,102 tok
│   step 07  delegate -> branch_c  brief=8,873 tok
│   step 11  REJECT branch_b report (reason: wrong fiscal year)
│   step 12  delegate -> branch_b'  brief=9,240 tok   <-- $0.449 repeat
├─ branch_a    13 steps   $0.451   ctx_peak 44k   FY=2026
├─ branch_b    13 steps   $0.451   ctx_peak 44k   FY=2025  <-- diverged
├─ branch_b'   13 steps   $0.449   ctx_peak 44k   FY=2026
└─ branch_c    13 steps   $0.451   ctx_peak 44k   FY=2026
$ $ agentctl diff-brief 8f3a branch_a branch_b --field fiscal_year
branch_a brief L41: 'the current fiscal year (FY2026)'
branch_b brief L39: 'the most recent completed fiscal year'
-> lead paraphrased the same constraint two ways. No error was raised.
-> cost of the divergence: $0.451 wasted + $0.449 rerun = $0.900 (37% of run)
verdict: not a model failure. a briefing failure, invisible to every error metric.

Which multi-agent topology should you use if you genuinely need one?

Orchestrator with stateless workers, in almost every case. It is the only common topology where the state boundary is explicit, the failure semantics are simple, and the cost is boundable. Anthropic's own Research system uses exactly this shape: a lead agent plans, spawns three to five subagents in parallel, and synthesises with a separate citation pass.

The critical property is that workers are stateless and return once. Give each one an explicit input schema, an explicit output schema, its own step and token budget deducted from the run-scoped global budget, and no ability to spawn. That last constraint is not stylistic: recursion turns a bounded cost into an unbounded one, and a boolean field on the worker contract is a cheaper defence than any amount of prompting. A worker that returns structured fields rather than prose also removes one of the two lossy compression steps, because the lead parses data instead of re-reading an essay at $2 per million tokens.

Sequential handoff pipelines are the second defensible shape, and only when each stage transforms rather than reasons: extract, then classify, then draft. They are cheap because no stage carries the others' history, and the failure mode is clean: stage three fails, stages one and two stay valid, and you resume from the journal. The weakness is they cannot backtrack. If stage two made a bad call, stage three has no way to notice.

Peer-to-peer and debate topologies I would avoid outside research settings. They multiply cost by participants times rounds, have no natural termination condition, and Cognition's guidance addresses them directly: parallel actions produce conflicting implicit decisions, and a single-threaded context is usually good enough. On the same token assumptions, a three-participant, three-round debate on a 10-turn task costs roughly $1.90 against $0.36 for one agent. That is a 5x premium for consensus rather than answers, with no failure signal when the participants confidently agree on something wrong.

import { z } from "zod";

/** A worker is a tool that happens to be implemented with a model call.
 *  It returns once. It holds no state. It cannot spawn. */
export type WorkerSpec<TIn extends z.ZodTypeAny, TOut extends z.ZodTypeAny> = {
  name: string;
  model: "cheap" | "mid" | "frontier";
  tools: string[];              // explicit subset, never the full catalogue
  scopes: string[];             // credential scopes, enforced at the gateway
  accepts: TIn;
  returns: TOut;                // structured, so the lead parses instead of re-reading
  canSpawn: false;              // not a default. a type. no code path sets it true.
  maxSteps: number;
};

export type RunBudget = {
  /** Shared atomically across EVERY agent in the tree. Per-agent budgets
   *  do not bound a tree: 3 agents x 25 steps is 75 steps, and if any of
   *  them can spawn, it is unbounded. */
  reserve(tokens: number): Promise<"ok" | "exhausted">;
  spentMicros(): Promise<number>;
};

export async function runWorker<TIn extends z.ZodTypeAny, TOut extends z.ZodTypeAny>(
  spec: WorkerSpec<TIn, TOut>,
  brief: unknown,
  budget: RunBudget,
  journal: Journal,
): Promise<z.infer<TOut> | { status: "budget_exceeded" | "invalid_brief" }> {
  const parsed = spec.accepts.safeParse(brief);
  if (!parsed.success) {
    // Fail loudly here. A malformed brief silently accepted is the
    // $0.45-of-wrong-work failure, and nothing downstream will catch it.
    await journal.writeBriefRejection(spec.name, parsed.error.issues);
    return { status: "invalid_brief" };
  }

  // Prove later that every branch got the same constraint.
  const briefHash = hashCanonical(parsed.data);
  await journal.writeSpawn({ worker: spec.name, briefHash, scopes: spec.scopes });

  const estimate = estimateTokens(spec, parsed.data);
  if ((await budget.reserve(estimate)) === "exhausted") {
    return { status: "budget_exceeded" };
  }

  const raw = await loop(spec, parsed.data, budget, journal);
  return spec.returns.parse(raw);   // structured out, or it throws
}

What breaks in a multi-agent system that does not break in a single agent?

Nine things, and seven of them return HTTP 200. That is the defining operational property here: the new failure modes are not crashes, they are agreements. Branches that confidently agree, briefs that quietly diverge, syntheses that smooth over contradictions. Your error rate does not move for any of them.

The two that do throw are the easy ones. A worker that exceeds its budget terminates into a named status, and a worker whose output fails schema validation throws at the parse boundary. Both are handled by the contract above. Everything else in the table needs an eval or a purpose-built detector, and those detectors do not exist in any framework I know of. You write them.

The row I would build the detector for first is brief divergence: cheap to catch, expensive to miss. Hash the canonical form of every brief, store the hash on the spawn record, and alert when two branches of the same run got briefs whose constraint fields differ. That is about forty lines. On the model above it catches a failure worth $0.90 on a $2.41 run, 37% of the run, and it is the only detector in this table that pays for itself on a single incident.

The row that will actually page you is the orphaned worker. The lead crashes, three workers keep running, and nobody reads their results. Without a supervision relationship and a heartbeat, you pay for three branches producing output into a void, about $1.35 on the coupled model, and the run sits in a running state forever. The fix is a lease with a heartbeat and a reaper, the same durable-execution machinery from the reference architecture, applied one level up.

How do you migrate from one agent to several without rewriting everything?

Extract a subagent as a tool first, and only promote it to an agent when you have measured a reason. The migration path is short if your single agent was built correctly, because the contract for a stateless worker is identical to the contract for a tool: schema in, schema out, budgeted, journalled, idempotent.

Step one is to stop calling it a migration. Take the branch you believe needs its own agent and implement it as a tool that internally runs a bounded model loop and returns a structured result. It is now mechanically a subagent, with its own context, tool subset, model choice and budget, but from the parent's perspective it is just a tool call. Nothing in the parent loop, the journal schema or the observability changes. This gets you conditions two, three and five from the five-question test at zero architectural risk.

Step two is to measure the thing you assumed. Instrument the tool with its own token and cost lines and compare against the single-agent baseline for the same tasks. Most of the time the answer is that the branch is short, the brief is large, and the split loses money. That is a two-day experiment producing a number, versus a two-month rewrite producing an opinion.

Step three, only if the numbers hold, gives the worker true parallelism and independent failure handling. That is where you take on the distributed-debugging work: correlation identifiers, span parentage, global ordering, the brief-hash detector, the run-scoped budget and the reaper. Budget about a week and a half for that layer alone. If you are doing this under time pressure with a team that has never built a distributed system, that is exactly what AI product development services exist for, and the honest advice in most of those conversations is that steps one and two are the whole answer.

What should you build instead, most of the time?

One agent with a tool layer good enough that a second agent is not tempting. Nearly every multi-agent proposal I review is a workaround for a tool layer that returns unbounded prose, exposes fifty schemas the agent never uses, and has no way to fetch tools on demand. Fix that and the case for the second agent usually evaporates.

The single highest-leverage change is tool subsetting and on-demand discovery. Anthropic reports that deferring tool definitions and letting the model search for them cut context from 77,000 tokens to 8,700, an 85% reduction, while tool-selection accuracy on their internal evaluation rose from 79.5% to 88.1% on Claude Opus 4.5. That is the same benefit people go multi-agent to get, without a serialisation boundary, a coordination agent or four transcripts to correlate. The tool-layer mechanics are in MCP in production.

The second is bounding tool results at ingestion. A tool that returns 40,000 tokens does not need a subagent to summarise it; it needs head-and-tail truncation with the full payload in an object store and a pointer in the journal. That is an afternoon. The subagent version is a week of engineering, adds a lossy compression step, and costs about 12.6 cents of fixed floor per invocation on the model in this post.

The third is unglamorous, and where I would actually start: measurement. My strongest example is not an agent-architecture story at all. Retell AI published a case study of my work on AccioMatrix where a proctoring false-positive rate went from roughly 50% to roughly 15%, about a 70% reduction, integrated in 48 hours. That was signal design and thresholding, not a second agent, and it took 48 hours rather than a quarter because the system was instrumented well enough to see which signal was firing wrongly. The principle holds: most problems that look like they need more agents need better observations, and per-request cost and quality attribution is the cheapest instrument you can build. The full method is in how routing and caching actually price a request.