When Multi-Agent Systems Are Worth It
Adding a second agent isn't an upgrade — it's a 3–10x token bill and a new failure mode. When a multi-agent system actually earns its cost, and the control layer I put around every spawn.
Adding a second agent is not an upgrade. It is a 3-to-10x token bill and a new class of failure — handoff loops, context bleed, runaway delegation — that a single, well-instrumented agent never has. A multi-agent system is not an architecture upgrade; it is a cost-and-reliability trade you should only buy against a named constraint. Anthropic's own guidance lists exactly three constraints that justify it — context pollution, genuine parallelism, and specialization — and says the coordination cost exceeds the benefit outside them. I run agents in production on chays.ai, and the control layer I put around every agent that can spawn another has mattered more than the model I point it at.
Why this matters now
On July 17, Claude Code added a per-session cap on subagent spawns — default 200, tunable with an environment variable — and the release note states the purpose in five words: to stop runaway delegation loops. The same release capped WebSearch calls per session for the same reason and moved long-running tool calls to the background so one greedy subagent cannot freeze the session. Two days earlier it added a flag to forward subagent text and thinking into structured output, because when delegation is invisible you cannot debug it. Foreground subagents are already constrained to a five-level delegation depth so a chain of agents spawning agents cannot recurse without bound.
Read the changelog as field data. The most-used coding agent in the world is shipping guardrails against its own delegation. That is not a niche edge case; it is the predictable failure mode of multi-agent systems meeting production load, and the vendor is now enforcing limits in the harness itself.
The counterweight is Anthropic's own advice. In its guidance on when to use multi-agent systems, the team is blunt: single agents handle most workflows, teams have spent months building elaborate multi-agent architectures only to find that better prompting on one agent matched the result, and multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks. The trigger and the guidance point the same way: reach for a second agent last, not first.
The three gates, and the code that guards them
Anthropic names three situations where multiple agents consistently beat one. Use them as gates — a spawn has to pass at least one or it does not happen.
The first is context protection. When a subtask floods the working context with tokens the main task will never use — a 2,000-token order lookup in the middle of a diagnosis — an isolated agent keeps the main context clean and returns only the summary. The second is parallelism. Independent research paths, or components with a clean interface, can run at the same time and cover more ground than one agent working inside a single context window. The third is specialization. When one agent is juggling twenty-plus tools across unrelated domains and mis-selecting, splitting into focused agents with tailored prompts fixes the selection errors.
Then decompose by context, not by problem type. This is the mistake Anthropic saw teams make most: splitting a feature into planner, implementer, tester, and reviewer agents produces a telephone game where each handoff loses fidelity, and in their experiment the subagents spent more tokens on coordination than actual work. Split work only where the context can be genuinely isolated — the feature and its tests belong to one agent because they share context; a blackbox verifier that only runs the test suite belongs to another because it needs almost none.
Even a spawn that passes a gate needs a control layer. This is what the harness just externalized — a spawn budget, a depth cap, one owner per task — and it is a hundred lines you should own yourself:
// A subagent is a cost, not a default. This guard makes every spawn pay a
// budget and return a compact summary — the same primitives Claude Code now
// enforces (a per-session spawn cap and a five-level depth limit).
type Ctx = { depth: number; budget: { spawns: number } }
const MAX_DEPTH = 3 // beyond this, delegation is almost always the telephone game
const MAX_SPAWNS = 8 // a hard per-request budget; a runaway loop hits a wall, not your bill
async function spawnSubagent<T>(
ctx: Ctx,
task: { goal: string; context: string; summarize: (raw: string) => T },
): Promise<T> {
if (ctx.depth >= MAX_DEPTH) throw new Error(`delegation too deep (${ctx.depth})`)
if (ctx.budget.spawns <= 0) throw new Error('spawn budget exhausted')
ctx.budget.spawns--
// The subagent runs in its own clean context — the entire point of delegating.
const raw = await runAgent({
system: task.goal,
input: task.context,
ctx: { depth: ctx.depth + 1, budget: ctx.budget },
})
// Return 1–2k tokens of distilled result, never the raw context. This is the
// whole reason to isolate: the parent stays clean, the handoff stays cheap.
return task.summarize(raw)
}
// Seed the budget once per request; every spawn decrements it toward zero.
const rootCtx: Ctx = { depth: 0, budget: { spawns: MAX_SPAWNS } }
// One owner per task: the parent decides to delegate; the child answers and exits.
// It never re-delegates the whole job — the failure Anthropic patched in the harness.The typed summarize step is the load-bearing part. A subagent that returns its raw context has bought you nothing — you paid a second context window and then poured its contents back into the first. The reason to isolate is to hand back a distilled 1–2k-token answer, not a transcript.
What this means for a founder
Multi-agent is a budget-and-reliability decision, not a sophistication signal. If your AI feature's token bill is climbing and its latency got worse, a multi-agent design is a prime suspect, not a badge. The three gates are a procurement checklist: if nobody can name which gate a given agent is buying against, you are paying the multi-agent tax for a single-agent job. The strongest single-agent move is often not a second agent at all — Anthropic points to on-demand tool search that cut token usage by up to 85% as the thing to try before you split.
The delegation decision
Before you spawn a subagent, one of these must be true:
- Context protection. The subtask generates high-volume context (more than ~1,000 tokens) that the main task does not need afterward.
- Parallelism. The work decomposes into independent paths that can run at once, and you want coverage more than you want the lowest possible cost.
- Specialization. One agent is mis-selecting across 15–20+ tools or juggling conflicting instructions, and focused agents with tailored prompts resolve it.
Then wrap every spawn that passes:
- A depth cap, so a chain of agents cannot recurse without bound.
- A spawn budget per request, so a runaway loop fails loudly instead of quietly billing you.
- One owner per task, so a child answers and exits rather than re-delegating the whole job.
- A blackbox verifier where you need a check, because verification needs almost no shared context and is the one delegation that pays off nearly everywhere.
My perspective
The opinion I will defend: default to one agent, and treat every spawn as a purchase you have to justify. On chays.ai I run persistent-memory agents that carry context across a fractional-CTO engagement, and the lesson that saved the most money was not a better model — it was refusing to delegate by default. Most of what looked like it needed a team of agents was one agent with a clean context and the right tool. When I do split, it is almost always the context-protection case: a lookup or a retrieval that would pollute the main thread, isolated so it returns a summary and nothing else.
This is the same argument I have made from two other angles — that wiring Claude Code into a real codebase is about controlling where the loop breaks, and that the memory architecture behind chays.ai is tiered state rather than a growing prompt. Multi-agent is that discipline pointed at the org chart of your agents: build the smallest system that works, and add an agent only when a named constraint forces your hand. That judgment — what to delegate, what to keep, and what control layer to put around the difference — is the agentic engineering work I do for teams shipping AI into production.
Recommended action this quarter
Audit one AI feature this week. Count the agents; for each hop, name the gate it passes. Kill every spawn that fails the test — most will — and put a depth cap and a spawn budget on the ones that survive. Then forward your subagent traces so delegation is visible in your logs, because you cannot govern what you cannot see. None of this requires a new framework. It is a checklist and a hundred lines of guard code, and it is the difference between an agent design you can reason about and a token bill you cannot explain.
Thinking about going multi-agent?
If your agent's token bill is climbing faster than its results, the fix is usually fewer agents, not more. Book a time and we will audit your agent design against the three-gate test — and put a control layer around what is left.