The Orchestrator's Tax
The Orchestrator's Tax
Subagents get justified by time saved and parallel execution, but that's not<br>what matters most in long-running multi-agent work. Every token in the orchestrator's<br>context is competing for its attention, and the real value of a subagent is what it keeps<br>out of that context, not how fast it runs. I argue that subagents should be treated as a<br>tool for protecting the orchestrator's working memory, offloading reasoning it doesn't<br>need to hold onto. Doing this well means giving the orchestrator explicit ground rules for<br>when and how to delegate. This is exploratory work, built from one real incident, and it ends<br>with more open questions than settled answers.
28 July 2026
Rahul Garg
Rahul is a Principal Engineer at Thoughtworks, based in Gurgaon, India.<br>He is passionate about the craft of building maintainable software through DDD and Clean Architecture,<br>and explores how AI can help teams achieve engineering excellence.
Contents
The Incident Was Not Really About Parallelism
The Costs Were Not All the Same
The Scarce Resource Is the Orchestrator's Working Memory
Cognitive Locality Changes What Parallelism Is For
Turning a Session into Standing Rules
The Next Mistake Would Have Been More Governance
Where This Leaves Me
I was deep into a Claude Code session on a .NET codebase when a doubt<br>interrupted the work. Four subagents were already running against a<br>response-pipeline refactor, results were arriving out of order, and the<br>session had started to feel harder to reason about than the code itself.
That is usually the moment I stop trusting the vague sense that things<br>are “probably fine.” Sometimes the code is the problem. Sometimes the<br>architecture is. Occasionally the workflow itself deserves inspection. This<br>time I decided it was the workflow.
At first I thought I already knew the question. Were four subagents<br>simply too many? That framing felt reasonable. Multi-agent systems are<br>usually sold as an obvious productivity win, and if one agent helps, four<br>should help more. But every additional agent also consumes tokens, repeats<br>some amount of work, and adds another stream of information the orchestrator<br>has to reconcile. It looked like a straightforward trade-off between<br>parallelism and cost.
I did not want a general argument about multi-agent systems. I wanted an<br>answer about that session. So I stopped the coding work and asked the<br>orchestrator to critique its own delegation decision, as factually as it<br>could.
The answer was not the one I expected. The largest cost in the session<br>did not look like it came from running four subagents. It looked like it<br>came from the orchestrator itself, specifically from what happened when it<br>suggested checking on the other agents.
The Incident Was Not Really About Parallelism
Four subagents had been launched in one wave. Three had clear runtimes:<br>roughly twelve minutes, five and a half minutes, and seven minutes. A fourth<br>was still running. Looked at one way, that already justified the delegation.<br>Three tasks ran concurrently, so wall-clock time was around twelve minutes<br>instead of something closer to twenty-five if the work had been<br>serialized.
But speed was the visible byproduct, not the interesting part. What I was<br>trying to find was the cost, and my first instinct was that it had to be the<br>duplicated effort of delegation itself: every subagent reading files,<br>reconstructing context, understanding the task independently.
That was not where the biggest surprise turned up.
At one point during the work, the orchestrator suggested checking on the<br>running agents. It was a small, throwaway prompt: “check on the agents.” I<br>followed it. Instead of a lightweight summary, the tool it used pulled back<br>the full raw transcript of a background agent: tens of thousands of tokens of<br>JSONL, intermediate reasoning, and tool output, imported wholesale into the<br>main thread. Then it happened again, for a second status check.
There is an important caveat here. The claim that this polling behaviour<br>cost more than the duplication tax of four agents was the orchestrator grading<br>its own mistake. I didn't have real per-call token accounting, so treat that<br>ranking as the orchestrator's account, not a measured fact. The trustworthy<br>part is narrower: the transcript dumps were real, the wall-clock timings were<br>real, and the status-check path clearly introduced a large, avoidable cost.<br>Whether it was the single largest cost remains a hypothesis until the tooling<br>can instrument it properly.
What mattered more was that I'd found a cost I hadn't been looking for.
The Costs Were Not All the Same
Once I stopped treating the session as one lump “subagent cost,” the<br>picture broke into pieces that didn't belong together.
First, two of the four subagents were working in the same area of the<br>response pipeline. Different tasks, different files, but both had to<br>understand the same architecture, the same testing conventions, and much of<br>the same...