{"slug": "the-orchestrator-s-tax", "title": "The Orchestrator's Tax", "summary": "A developer working with Claude Code on a .NET codebase found that the largest cost in a multi-agent session came not from running four subagents in parallel but from the orchestrator's status-check prompts, which pulled full raw transcripts of background agents into the main thread, importing tens of thousands of tokens of JSONL, intermediate reasoning, and tool output. The developer argues that subagents should be treated as a tool for protecting the orchestrator's working memory by offloading reasoning it does not need to hold onto, and that the real value of a subagent is what it keeps out of the orchestrator's context, not how fast it runs.", "body_md": "# The Orchestrator's Tax\n\n*Subagents get justified by time saved and parallel execution, but that's not\nwhat matters most in long-running multi-agent work. Every token in the orchestrator's\ncontext is competing for its attention, and the real value of a subagent is what it keeps\nout of that context, not how fast it runs. I argue that subagents should be treated as a\ntool for protecting the orchestrator's working memory, offloading reasoning it doesn't\nneed to hold onto. Doing this well means giving the orchestrator explicit ground rules for\nwhen and how to delegate. This is exploratory work, built from one real incident, and it ends\nwith more open questions than settled answers.*\n\n28 July 2026\n\n## Contents\n\nI was deep into a Claude Code session on a .NET codebase when a doubt interrupted the work. Four subagents were already running against a response-pipeline refactor, results were arriving out of order, and the session had started to feel harder to reason about than the code itself.\n\nThat is usually the moment I stop trusting the vague sense that things are “probably fine.” Sometimes the code is the problem. Sometimes the architecture is. Occasionally the workflow itself deserves inspection. This time I decided it was the workflow.\n\nAt first I thought I already knew the question. Were four subagents simply too many? That framing felt reasonable. Multi-agent systems are usually sold as an obvious productivity win, and if one agent helps, four should help more. But every additional agent also consumes tokens, repeats some amount of work, and adds another stream of information the orchestrator has to reconcile. It looked like a straightforward trade-off between parallelism and cost.\n\nI did not want a general argument about multi-agent systems. I wanted an\nanswer about *that* session. So I stopped the coding work and asked the\norchestrator to critique its own delegation decision, as factually as it\ncould.\n\nThe answer was not the one I expected. The largest cost in the session did not look like it came from running four subagents. It looked like it came from the orchestrator itself, specifically from what happened when it suggested checking on the other agents.\n\n## The Incident Was Not Really About Parallelism\n\nFour subagents had been launched in one wave. Three had clear runtimes: roughly twelve minutes, five and a half minutes, and seven minutes. A fourth was still running. Looked at one way, that already justified the delegation. Three tasks ran concurrently, so wall-clock time was around twelve minutes instead of something closer to twenty-five if the work had been serialized.\n\nBut speed was the visible byproduct, not the interesting part. What I was trying to find was the cost, and my first instinct was that it had to be the duplicated effort of delegation itself: every subagent reading files, reconstructing context, understanding the task independently.\n\nThat was not where the biggest surprise turned up.\n\nAt one point during the work, the orchestrator suggested checking on the running agents. It was a small, throwaway prompt: “check on the agents.” I followed it. Instead of a lightweight summary, the tool it used pulled back the full raw transcript of a background agent: tens of thousands of tokens of JSONL, intermediate reasoning, and tool output, imported wholesale into the main thread. Then it happened again, for a second status check.\n\nThere is an important caveat here. The claim that this polling behaviour cost more than the duplication tax of four agents was the orchestrator grading its own mistake. I didn't have real per-call token accounting, so treat that ranking as the orchestrator's account, not a measured fact. The trustworthy part is narrower: the transcript dumps were real, the wall-clock timings were real, and the status-check path clearly introduced a large, avoidable cost. Whether it was the single largest cost remains a hypothesis until the tooling can instrument it properly.\n\nWhat mattered more was that I'd found a cost I hadn't been looking for.\n\n## The Costs Were Not All the Same\n\nOnce I stopped treating the session as one lump “subagent cost,” the picture broke into pieces that didn't belong together.\n\nFirst, two of the four subagents were working in the same area of the response pipeline. Different tasks, different files, but both had to understand the same architecture, the same testing conventions, and much of the same surrounding code before either could begin. Each paid that orientation cost independently. That's not an argument against delegation. It's an argument that the work had been split too finely.\n\nSecond, one agent ran `git stash`\n\nand `git stash pop`\n\nwhile sibling agents\nwere writing elsewhere in the same tree. Nothing broke, but the risk was\nstructural, because repository-wide operations are perfectly reasonable in a\nsingle-threaded session and become much harder to justify the moment multiple\nwriters are active at once.\n\nBy now I had a growing list of culprits: status polling, duplicated orientation, unsafe git operations. I found myself trying to rank them. Which one cost the most? The longer I tried to answer that, the less convinced I became that ranking them was the right question at all.\n\n## The Scarce Resource Is the Orchestrator's Working Memory\n\nThe transcript-polling incident kept bothering me for a reason that had nothing to do with token cost. A token bill is one-time, you pay it and it's over. What happened here was different. The raw transcript stayed in the orchestrator's context after the tool call completed, and every turn after that carried it forward, whether or not it was still useful.\n\n*That was the moment I realized I had been treating two very different\nkinds of cost as though they were the same. Tokens are spent once. Context\nshapes every decision that follows. I wasn't simply looking at token\nconsumption anymore. I was looking at the quality of the orchestrator's\nworking memory.*\n\nThat realization was carrying two separate ideas, and I want to pull them apart rather than let them blur together. The first is what I just described. Pollution left in context taxes every later turn. The second is not about running out of space at all. The more that's sitting in context, competing for attention, the harder it gets for a model to pick out what matters right now, even with plenty of room still free. A bigger context window doesn't fix that. It just gives the noise more room to pile up before anyone notices.\n\nContext windows are only going to get bigger, that's a given. What matters is not how much room there is, but how much of what's sitting in that room is worth the model's attention. That's the real problem subagents need to solve, if they're used right.\n\nSeen this way, the orchestrator is the only part of the system that accumulates understanding across a long session. It remembers why a design decision was made, carries forward architectural constraints, and knows which trade-offs have already been discussed. The subagents don't, and that's by design. They are supposed to be disposable. Exploration, repeated file reads, failed approaches, and noisy intermediate reasoning are meant to stay in worker contexts and never make the trip back to the main thread.\n\n## Cognitive Locality Changes What Parallelism Is For\n\nThis reframes the duplicated-orientation problem, which wasn't really “two\nagents reading the same files.” It was two agents independently reconstructing\nthe same mental model of the codebase, because the work had been partitioned\nby task rather than by the knowledge each task required. I've started calling\nthat distinction **cognitive locality**: Tasks that need the same mental model should usually stay together.\nSplitting them just forces multiple agents to rebuild the same understanding\nfrom scratch.\n\nParallelism still matters here, it's just not the main point. Running four agents concurrently is useful, but ordinary. The real benefit is that they keep noisy intermediate reasoning out of the main thread and return only what it still needs. That's the isolation subagents are supposed to provide, and it only holds if the main thread respects it.\n\nMy working belief now: this is what subagents are actually for. Not that they save time, but that they let you offload reasoning the orchestrator doesn't need to hold onto, so it has less to carry and less competing for its attention. Get the isolation right, keep things local by cognitive locality, and subagents become the tool that protects the orchestrator's working memory, not just a cost you tolerate for parallelism. That's a belief, though, not a measurement. What I've actually measured is the other side of it, the cost of getting the isolation wrong.\n\n## Turning a Session into Standing Rules\n\nMy next move was the obvious one. Encode the lesson into `CLAUDE.md`\n\n, the\nstanding instruction file every session loads.\n\nIt would have been easy to write a large corrective policy here, but every extra line in a standing instruction file is a cost paid again on every future session. So I compressed the fix into the smallest set of rules that addressed the failures I'd seen. Each one is really answering the same question. Does this piece of information, or this way the work is split, earn a place in the orchestrator's context?\n\n- Prefer two to four agents in one wave. If the orchestrator wants five or more, it should first ask whether tasks sharing files or conventions ought to be merged.\n- Do not poll background agents for status when the answer can be given from what is already known. Do not fetch a full transcript to answer a lightweight question.\n- Do not allow repository-wide git operations inside concurrent agent prompts.\n- Treat overlapping file ownership as a consolidation signal, not a cue to spawn more agents.\n\nNone of these tell the orchestrator exactly what to do in every case. Each one gives it something to check or ask itself before acting, not a script to run, and none of them is profound on its own. Their only real value is that they're all aimed at the same thing, keeping disposable reasoning disposable and keeping room in the orchestrator's context for what it needs later in the session.\n\n## The Next Mistake Would Have Been More Governance\n\nA later session surfaced a different gap. I had started the orchestrator with explicit skills for the kind of work I wanted, coding guidance in one case, design guidance in another. I assumed that once a skill was active in the main thread, spawned subagents would follow it automatically. They don't. A subagent doesn't inherit skills active in the parent session unless the orchestrator passes them along explicitly.\n\nMy first instinct was to add a confirm-before-spawn gate. The orchestrator would stop, list which agents it wants to launch and which skills each should load, and wait for my approval.\n\nI'm glad I didn't keep that version. It solved the wrong problem. I didn't have evidence that bad spawn plans were slipping through for lack of a confirmation step. I'd discovered a missing fact about skill propagation, and that's a different kind of gap. A universal confirmation gate would have added a round-trip to every similar session, and before long I'd almost certainly have started approving those prompts on autopilot.\n\nAt that point, I realized I wasn't really improving governance. I was just adding another ritual.\n\nAnd it still wouldn't have caught the real problem from before, the orchestrator polluting its own context.\n\nThe narrower fix held up better. Before spawning, the orchestrator states which active skills are relevant to each agent's task and points the subagent at the skill file to load, rather than pasting the whole skill inline. Confirmation is only required above the same batch-size threshold already in place, or when file ownership is ambiguous.\n\nThat left me with a heuristic I now use more than the rule itself: *Before\nadding a line to a standing instruction file, ask whether a reasonably\ncompetent orchestrator would make the right decision once it knew the one\nmissing fact.*\n\nIf yes, the rule should just state the fact. If the fix starts specifying a decision procedure, such as approvals, checkpoints, mandatory steps, that's usually a sign I'm encoding process where a small clarification would have done the job.\n\nI don't know yet whether that heuristic survives harder cases. For now it stops me from turning every interesting incident into a miniature bureaucracy.\n\n## Where This Leaves Me\n\nI don't have a settled view of how much governance is enough, and I don't think this piece earns one.\n\nWhat I have instead is a small flywheel, with a human still firmly in the middle of it. A session exposes a gap. Someone has to notice that it felt wrong, stop the work long enough to inspect it, decide whether the problem is real or just noise, and judge what deserves to become a standing rule. The orchestrator can grade its own session and surface clues, as it did here, but it cannot make that judgment call itself. The choice of what to codify, what to leave alone, and what might be an overreaction is still mine. The next session then tells me whether that judgment improved the work or just created a different kind of waste.\n\nThe artifact of this round is the current version of\n[my CLAUDE.md](https://gist.github.com/techygarg/f8f98a2f026538fad4a69b593a964d95).\nIt isn't a finished prescription. It's the state of the calibration after this\niteration. The thresholds in it, two to four agents per wave, five as a\nconsolidation signal, fit the work I was doing when I wrote them. I wouldn't\npresent them as anything like universal constants, and I'd be suspicious of\nany orchestration write-up that did. They were also calibrated against Claude Sonnet 5,\nand I haven't tested how they hold up against others. A different\nmodel might reasonably need a different balance. A few more rules have accumulated\nin the file since. Treat this file as a sample, not a template, modify and optimize\nit for whatever model and workflow you're actually running. What matters isn't the\nspecific file, it's the habit behind it: noticing a failure, asking what it actually\ncost, and writing the rule that would have caught it.\n\nFor years we optimized software systems around CPU, memory, and throughput. The first wave of LLM tooling taught us to watch tokens. This session made me suspect there's a third thing worth watching in long-running agent workflows: the quality of the orchestrator's own working memory, the one resource that, once polluted, keeps charging rent for the rest of the session. I don't think that's a settled law yet. It's a pattern that held up in the sessions I've looked at so far.\n\nThe tax I went looking for was never on the subagents. It was on the orchestrator, in what it chose to carry forward. That's the question I carry into every multi-agent design now: not how many agents to run, but what earns a place in the orchestrator's context.\n\nThe questions I'm left with are genuinely open:\n\n- How do I measure this properly, instead of relying on the orchestrator's own account of its mistakes?\n- When should a missing fact go into the instructions, and when does that turn into too much process?\n- What's the next orchestration mistake I'm not seeing yet?\n\nI expect I'll revise the file again. That feels less like a failure of foresight and more like the normal cost of working with a system opaque enough that doubt itself becomes part of the method.\n\n## Related Work\n\nI've written before about context as a scarce resource, from a different\nangle. [Context\nAnchoring](https://martinfowler.com/articles/reduce-friction-ai/context-anchoring.html)\nargues that decision context should be externalized into a living document,\nsince a conversation forgets its own reasoning as it grows and nothing\nsurvives the session boundary. That piece is about context surviving across\nsessions. This piece is narrower. It's about keeping context clean within a\nsingle session, while several agents write to the same working memory at\nonce.\n\n## Acknowledgments\n\nThe move to turn this incident into a standing CLAUDE.md rule owes\nsomething to Birgitta Böckeler's [Harness\nEngineering](https://martinfowler.com/articles/harness-engineering.html),\nwhich names the loop I was running without having a word for it at the time. A\nfeedforward guide (the CLAUDE.md rule) meets a feedback signal (the\norchestrator's own self-critique, and my review of the session), with a human\nsteering the update. That article names three kinds of harness:\nmaintainability, architecture fitness, and behaviour. What this piece\ndescribes, using subagents deliberately to protect what the orchestrator\ncarries forward, belongs to a fourth, the orchestration process itself.\n\nThanks to Martin Fowler for his guidance and feedback throughout, which pushed this piece toward clearer thinking and articulation.\n\nChatGPT and Claude served as pair editors on this piece, helping with grammar, sentence crafting, and paragraph structure wherever it was needed.\n\n## Significant Revisions\n\n*28 July 2026: *", "url": "https://wpnews.pro/news/the-orchestrator-s-tax", "canonical_source": "https://martinfowler.com/articles/orchestrator-tax.html", "published_at": "2026-07-29 09:59:26+00:00", "updated_at": "2026-07-29 10:22:43.337040+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "large-language-models", "ai-tools", "developer-tools"], "entities": ["Claude Code", "Anthropic"], "alternates": {"html": "https://wpnews.pro/news/the-orchestrator-s-tax", "markdown": "https://wpnews.pro/news/the-orchestrator-s-tax.md", "text": "https://wpnews.pro/news/the-orchestrator-s-tax.txt", "jsonld": "https://wpnews.pro/news/the-orchestrator-s-tax.jsonld"}}