Zenaique

Which conditions favour a multi-agent architecture over a single agent system?

Multi-select·Medium·4.0 · 0·~1 min·Asked atForethoughtFractal AnalyticsSnap·Relevant atAnthropic
Attempt it
TL;DR

Multi-agent wins only when subtasks parallelise, specialist models beat a generalist, or volume overflows one context. Otherwise it just adds coordination cost.

Memory aid
Sign in to see the mnemonic that makes this stick.
Easy to grasp

Imagine you have a big project due. If the work splits into pieces that people can do at the same time without waiting on each other, hiring a team helps a lot. If one teammate is great at math and another at writing, splitting by skill also helps. But if the work is one long chain where step two needs step one finished first, a team does not finish faster. You just add the cost of everyone talking to each other and handing things off. AI agents are the same. A single agent is the simple default. You only split into a multi-agent team when the task genuinely parallelises, when specialists clearly beat a generalist, or when one agent simply cannot hold all the work in its head at once.

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

The choice between a single-agent and a multi-agent architecture is one of the most over-decided questions in applied agent design. Teams reach for a crew of cooperating agents because it feels powerful, then discover they have bought themselves routing logic, handoff bugs, duplicated token spend, and a debugging nightmare, all for a task one well-equipped agent could have handled in a single loop.

The disciplined framing is the opposite. A single agent in a loop is the baseline. Multi-agent is an escalation that must earn its place by delivering a benefit larger than the coordination cost it adds. This question tests whether you can name the specific conditions under which that escalation actually pays off, and whether you can spot the conditions that only look like they do.

Three conditions genuinely favour the split: parallel independent subtasks, a real specialist advantage that comes with context isolation, and scale that overflows one context window. Two of the listed options are deliberate traps. A strictly sequential chain looks like work you could divide, but it gives no parallelism. And the claim that orchestration is simpler than the task inverts the actual tradeoff. The sections below work through all five, and the worked example shows how to run the decision on a concrete task.

Condition one: genuinely parallel subtasks

The strongest reason to go multi-agent is parallelism. When a task decomposes into subtasks that have no dependencies on each other, you can spawn a worker agent per subtask and run them concurrently. The wall-clock latency drops from the sum of the subtask times toward the maximum of them. For a task with several truly independent branches, this is the difference between waiting minutes and waiting seconds.

The load-bearing word is independent. A research question like comparing the pricing, latency, and ecosystem of three cloud providers splits cleanly into three independent investigations whose results merge at the end. No branch needs another branch's output, so a fan-out of subagents is a genuine win. Anthropic's published research agent leans on exactly this shape: an orchestrator spawns subagents to explore separate parts of a question in parallel, then synthesises their findings.

Contrast that with subtasks that share state or feed each other. If branch two needs branch one's result, the branches serialise no matter how many agents you create. You get the coordination cost of multiple agents with none of the concurrency. This is false parallelism, and it is the single most common way teams talk themselves into an architecture that is slower and more expensive than a single agent.

The practical test before fanning out is a dependency check. Draw the subtask graph. If it has a wide layer of nodes with no edges between them, that layer is your parallelism budget. If the graph is a single long path, there is nothing to parallelise, and you should keep one agent.

Condition two: specialisation and context isolation
Condition three: scale beyond a single context window
The two distractors and why they fail
Sign in to unlock the full deep dive.

Situations where this technique stops working.

Sign in to see when this approach fails.

2–4 min · Everything important, quickly.

Sign in to see the quick scan of the deep dive.
DimensionSingle-agentMulti-agent
Latency on parallel workSerial, slowFan-out, fast
Coordination overheadNoneHigh: routing, handoffs, merge
Error propagationContained to one loopCompounds across agents
Context isolationSingle shared contextClean per-agent contexts
Default choiceYes, the baselineOnly when a real benefit wins

Real products, models, and research that use this idea.

  • Anthropic's multi-agent research system uses an orchestrator that spawns parallel subagents to explore independent search branches, reporting large latency wins over a single agent on broad research tasks.
  • OpenAI's Swarm and the newer Agents SDK model handoffs where a triage agent routes to specialist agents, a specialisation pattern rather than a parallelism one.
Sign in to see more production examples.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you decide the boundary between subagents in a research task, and what makes a clean split?
A

Split where subtasks are independent and produce mergeable artefacts. A clean boundary has no shared mutable state, a typed contract for the worker's output, and a context the worker can hold without seeing the others' scratchpads.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Reaching for a multi-agent design by default. A team of agents adds coordination cost and error propagation, so a single agent should be the baseline you must justify moving away from.

Sign in to see all red flags and common mistakes.

60 second bullets to scan on the way to the call.

  • Name the three conditions that genuinely favour a multi-agent design.

  • Explain why a strictly sequential chain gets no parallelism benefit.

Sign in to unlock the revision sheet.

Primary sources. Browse if you want the original framing.

Similar questions

Same topic, related formats. Practice these next.

4 curated
Next question
What is the Model Context Protocol (MCP) and what problem does it solve?
MCQ·Easy