Rahul Garg’s The Orchestrator’s Tax, published on martinfowler.com in July, argues that the point of subagents is not parallel speed but context protection: the scarce resource is the orchestrator’s working memory, and the tax is whatever noise gets carried forward in it. I run a multi-agent pipeline daily for ilo-lang development (dogfooding personas on Haiku, fix agents on bigger models, all in isolated worktrees), so I read it against my own logs:
- His transcript-pollution incident, and the reporting convention that avoids it
- His git-stash hazard, and why worktree isolation removes the class of bug
- One cost he does not cover: subagents that outlive their stop signal
The argument, briefly
Garg’s incident: four subagents refactoring a .NET pipeline in one wave, roughly 12 minutes wall clock against 25 serialised. The parallelism worked. The damage came when the orchestrator “checked on the agents” and pulled full raw transcripts, tens of thousands of tokens of JSONL, into its own thread, twice. His framing is that polluted context is worse than a one-off token bill because it degrades every decision that follows, and larger context windows just let the noise pile higher.
He distils the fix into standing rules: 2 to 4 agents per wave, no polling background agents, no repo-wide git operations in concurrent prompts, overlapping file ownership means consolidate.
Transcripts never come home
The transcript incident maps exactly onto a rule I converged on with my persona pipeline. A persona agent runs a long dogfooding session and produces a mass of tool calls and dead ends. The convention that survived: the subagent reports distilled findings to the parent as its return value, and the parent writes the log. The raw transcript stays on disk where it can be pulled up if a specific claim needs checking, and it never enters the parent’s context wholesale.
Garg reaches the same place from the incident side: his rule is not “never look”, it is “don’t fetch full transcripts for lightweight questions”. The version I would add is that the subagent’s final report is a designed artefact. If you leave its shape to chance you get either a one-line “done” that hides failures or a transcript dump, and both are taxes.
Worktrees make the git hazard structural
The finding that worried me most is an agent running git stash and git stash pop while sibling agents wrote to the same tree. His fix is a prompt rule banning repository-wide git operations in concurrent agents.
I would go further and remove the opportunity rather than asking for restraint. Every fix agent in my pipeline gets its own git worktree with its own build cache, so a stash, a checkout, or a stray reset touches only that agent’s copy. The failure Garg observed cannot occur across worktrees, whatever the prompt says. Prompt rules are the fallback for hazards structure cannot reach.
The cost he does not cover
One entry for his ledger from my own logs: subagents that outlive their stop signal. I have had a stopped fix agent keep committing to its branch after the kill, which is why my runbook now says to audit git log on any subagent-touched branch before pushing. The orchestrator’s context is one place state leaks; the repository is another, and a cancelled agent’s half-finished commits are noise of exactly the kind Garg describes, persisted where the next session will trip on it.
His closing heuristic is the piece’s best line of thinking: before adding a standing rule, ask whether a competent orchestrator would decide correctly if it simply knew the missing fact. If yes, state the fact and skip the procedure. Most of my runbook’s growth has been in the opposite direction, checklists accreting where facts would have done, and I am taking that as the prompt to prune it.