When does a multi-agent or orchestrator-worker design help, and when does it hurt?
- 2 min — orchestrator-workers; the two real benefits
- 3 min — token economics: ~4× chat vs ~15× chat; 3–4× single agent
- 3 min — breadth-first win vs coupled-task loss, with numbers
- 2 min — briefs, source ids, fan-out caps
- 2 min — platform capability and per-use-case approval
In orchestrator-workers (one of the patterns in Anthropic's 2024 taxonomy), a lead decomposes the task and dispatches sub-tasks to workers, each with a fresh context and its own tools, then synthesises their compressed results. Other multi-agent shapes include handoffs between specialists. The two real benefits are parallelism (wall-clock) and context isolation (each worker explores 50k tokens and returns 1–2k).
The bill: Anthropic's 2025 write-up of its research system reported single agents using about 4× the tokens of chat and multi-agent systems about 15× — roughly 3–4× a single agent — and found that token spend alone explained about 80% of performance variance on their browsing eval. Their multi-agent configuration beat a single agent by 90% on internal breadth-first research tasks. So multi-agent is mostly a way to spend more tokens in parallel; it pays when the task is breadth-first and the answer is worth the spend. Cognition's 2025 counter-argument (“Don't build multi-agents”) holds for tightly coupled work: workers make conflicting implicit decisions that the lead can't reconcile.
Due-diligence research: “summarise litigation exposure for 12 portfolio companies”. Lead plans 12 independent sub-tasks; 12 workers search court records and filings in parallel (each ~40k tokens explored, 1.5k returned); lead synthesises from ~18k tokens of summaries. Wall clock 4 min vs 38 min sequential. Counter-example: refactoring one service where change 5 depends on change 4 — two workers renamed the same interface differently and the lead spent 30% of its budget reconciling. That stays single-agent.
Require a single-agent baseline on the same task set and report success, wall clock and cost per successful task for both; approve multi-agent only where the success or latency gain justifies a 3–4× token bill. Name the hidden costs: information lost at every handoff (workers need an explicit brief — objective, output format, tool guidance, boundaries — or they duplicate work), harder tracing across nested runs, and compounding error when a wrong worker summary is trusted (keep source ids in worker output so the lead can verify). Cap fan-out (e.g. ≤10 workers) and give the lead a budget it allocates.
Org scope. Multi-agent is a platform capability, not a per-team architecture: one orchestration runtime with nested trace ids, per-run budgets and fan-out caps. Build vs buy: start on an SDK that supports sub-agents; own the budget allocator and tracing. Rollout: per use case with the baseline comparison attached. Failure mode: role-play decomposition (“planner”, “critic”, “coder”) for its own sake, when one agent with good tools would have been cheaper and better.
Assumptions: single agent = 25 steps at a mean 40k-token context → 1.0M input tokens. Multi-agent = lead 8 steps × 20k = 0.16M plus 5 workers × 15 steps × 30k = 2.25M → 2.4M input, ≈2.4× the single agent before synthesis and retries; observed systems land at 3–4×. assume $3 / M input and $15 / M output tokens (illustrative list prices, Oct 2026); cache writes 1.25× input (5-minute TTL), cache reads 0.1×. Uncached: single ≈ $3.00 + output, multi ≈ $7.20 + output. Worth it only if success or wall-clock gain is worth ≈ $4 per task.
What the answer sounds like at each level
A lead agent splits the work and sends parts to sub-agents that run in parallel, which helps for big research tasks.
Uses context isolation and parallelism as the justification, quantifies the 3–4× token multiple against a single-agent baseline, and avoids it for tightly coupled tasks.
Makes multi-agent a governed platform capability with fan-out caps, nested tracing and budget allocation, approved per use case on baseline evidence.
Follow-ups the interviewer will push
1How do you stop workers duplicating each other?
The lead writes a structured brief per worker — objective, scope boundary, output schema, tool hints, budget — and records which sources each worker covered. Duplicate-source rate across workers is a metric; >20% means the decomposition is bad.
2Now 10× traffic. What's your cost control?
Route by task breadth: a classifier sends narrow questions to a single agent. For multi-agent runs, the lead gets a dollar budget and allocates it; workers use a cheaper model where the eval allows, the lead keeps the stronger model.
3A worker returns a confident wrong summary. How is that caught?
Worker output carries source ids; the lead (or a verifier step) spot-checks claims against sources before synthesis, and the trajectory eval includes seeded wrong-source tasks.
Red flags interviewers listen for
- Splits by persona roles with no parallelism or context-isolation argument.
- No single-agent baseline in the evaluation.
- Doesn't know multi-agent costs several times the tokens of a single agent.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Economics | States the token multiple with its source and assumptions. |
| Task fit | Distinguishes breadth-first from tightly coupled work with examples. |
| Reliability | Briefs, source ids and verification against compounding worker errors. |
| Org scope | Central runtime, fan-out caps, nested tracing, baseline-gated approval. |
Sources
- How we built our multi-agent research system — Anthropic, 2025blog
- Building effective agents — Anthropic (Schluntz & Zhang), 2024blog