Sub-agents are context isolation, not delegation theater
Every multi-agent pitch deck has the same slide: an org chart of little robots — a researcher agent, a critic agent, a PM agent — delegating to each other like a startup. The framing is theater. What a sub-agent actually is, mechanically, is a fresh context window with its own system prompt, its own scoped tool permissions, and a hard rule that only its result flows back to the parent. That's not an employee. That's a process. And the value it delivers is the value process boundaries have always delivered: isolation.
Two isolations, specifically. The first is keeping noisy work out of the main thread. An exploration sub-agent grepping a codebase burns thousands of tokens on dead ends, file listings, and half-relevant reads; if all of that lands in the orchestrator's context, it degrades every decision that follows. Spawn it in a child, and the parent receives one distilled summary. The pattern even works mid-task: production harnesses respawn a clean-context sub-agent when the working context hits its limit, deliberately shedding the exploration debris.
The second is bounding blast radius. Look at what a mature harness actually configures on a sub-agent boundary and tell me it isn't a process boundary: read-only tool sets for analysis agents, scope isolation to a defined directory or API surface, permission isolation from the parent's grants, a no-recursive-spawning constraint (in the Claude Agent SDK, a child spawned via the Task tool cannot itself carry Task), fork budgets and max-depth limits to stop O(N^k) proliferation, resource budgets applied to the whole agent tree. That is capabilities, chroot, and ulimits, reinvented for LLMs — and correctly so.
The structure wins, not the personas
The strongest published numbers support the isolation reading. Anthropic's asymmetric-model pattern — an Opus 4.5 orchestrator dispatching Haiku 4.5 sub-agents — hit 87.0% on evaluation versus 74.8% for solo Opus. The sub-agents weren't "specialists" in any meaningful sense; they were cheaper models given clean, narrow contexts and scoped tools. The decomposition and the isolation did the work. Likewise, Anthropic's production research system — LeadResearcher, sub-agents, CitationAgent — embeds its scaling rules directly in the orchestrator prompt (1 sub-agent for simple queries, 2–4 for moderate, 10+ for complex), and passes results through structured handoff schemas and filesystem artifacts rather than free-form chat. Every one of those choices is boundary engineering.
None of this is free, which is exactly why the process-boundary framing matters. Parallel sub-agents carry roughly 7× token overhead; full multi-agent systems run to a 15× multiplier over single-agent baselines. And the result summary crossing the boundary is lossy compression — the sub-agent context leak problem — which is a loss-function choice you should make deliberately, not discover in production. You wouldn't spawn OS processes casually because forking felt organizationally tidy; the same discipline applies here.
I'll concede the counter-case: role framing isn't pure theater. A critic agent with a genuinely different system prompt catches things a generator grading its own work never will — self-evaluation is a documented anti-pattern, and separating them helps. But notice why it helps: the "role" cashes out as a different context, different instructions, different permissions. The persona is a label on an isolation profile. When the label comes with no profile — five agents sharing one context and one tool set, chatting — you've paid the token multiplier for a costume party.
So design sub-agent boundaries the way you design process boundaries. Decide what crosses (a schema, not vibes), what's denied (tools, scope, depth), and what it costs (budgets on the tree). If a proposed sub-agent doesn't need a different context, different permissions, or a different model tier, it doesn't need to exist — it's harness complexity with no isolation payoff.