The Orchestrator's Tax

The setup sounds mundane: four subagents chewing through a .NET refactor, results trickling back out of order, and a nagging sense that the session had gotten harder to follow than the actual code. Most people would blame the code or shrug it off. This developer paused the work entirely and asked the orchestrator to critique its own delegation choices. What came back wasn't the answer anyone expected.

The instinct going in was that four agents were simply too many — more parallelism, more duplicated effort, more tokens burned reconstructing context independently. That trade-off is real, and it showed up: two of the four subagents ended up rebuilding the same mental model of the response pipeline because their tasks overlapped but had been split by task rather than by shared knowledge. But that wasn't the biggest offender. The orchestrator, at one point, casually suggested checking on the running agents. That single prompt triggered a tool call that pulled back the entire raw transcript of a background agent — tens of thousands of tokens of JSONL, reasoning traces, and tool output — and dropped it straight into the main thread. Twice.

The author is careful to flag that the ranking of 'biggest cost' came from the orchestrator grading itself, not from real per-call token accounting, so it's a hypothesis rather than a measured fact. What is verifiable is that the transcript dumps happened, the timings were real (three subagents running concurrently in roughly twelve minutes instead of a serial twenty-five), and the status-check behavior introduced a large, avoidable cost regardless of exact ranking.

The more interesting shift is conceptual: tokens are a one-time bill, but polluted context taxes every subsequent turn of the session. A bloated context window doesn't just risk running out of room — it makes it harder for the model to pick out what actually matters right now, even with space to spare. The author coins this cognitive locality: work should be grouped by the mental model it requires, not chopped up by task boundaries, so subagents aren't burning cycles reconstructing understanding that another agent already built. Under this framing, subagents aren't really about speed. They're there to keep messy, disposable reasoning out of the orchestrator's head entirely.

Rather than write a sprawling new policy, the fix got compressed into a handful of standing rules in CLAUDE.md: cap waves at two to four agents, treat five-plus as a cue to consolidate overlapping work instead of spawning more, ban full-transcript pulls for status checks, and block repo-wide git operations when multiple agents are writing concurrently. A later session revealed subagents don't automatically inherit skills active in the parent thread — the first fix was a heavyweight confirmation gate, which got scrapped in favor of a simpler rule: state which skills matter per task and point to the file, only confirming above the same batch threshold. The guiding test became whether a competent orchestrator would get it right just by knowing the one missing fact — if so, state the fact, don't build a process around it.