# The Orchestration Tax By **addyosmani** · Artículos Addy Osmani's essay on why more AI agents don't mean more shipped work, and how to architect your attention like a concurrent system. - Source: https://x.com/addyosmani/status/2059844244907696186 - Tags: multi-agent, agentic-workflows, developer-productivity, llm, systems-design, cognitive-load, orchestration, open-source - Upvotes: 0 --- ## The big picture The orchestration tax is the gap between how fast AI agents produce work and how fast one human can review it. Addy Osmani named the concept at a Google I/O panel alongside Richard Seroter, Aja Hammerly, and Ciera Jaspan, and then expanded it in a written essay. The thesis is simple: starting an agent costs a keystroke; closing the loop on its output costs your full attention. ## Why it matters Feeling busy is not the same as being productive. You can run 20 agents and generate 20 queued diffs, but every one of those diffs still needs a human to verify correctness, resolve merge conflicts, and confirm architectural fit. That human is you, and you are the single serial thread in an otherwise concurrent system. Osmani reaches for two familiar CS concepts to make this concrete. First, Python's Global Interpreter Lock: many threads exist, but work requiring the lock still executes one at a time. Second, Amdahl's Law: parallel speedup is strictly bounded by the fraction of work that cannot be parallelized. In agentic software development, judgment is that serial fraction, and it does not shrink because you launched more agents. ## Zoom in The practical signal that a team has crossed the tax threshold is review queue depth. If open agent threads outnumber the diffs a developer can genuinely evaluate in a session, the queue is growing faster than it clears. A concrete decision rule from the essay: keep parallel agent count low enough that every review stays real, not a rubber-stamp. Osmani's heuristic is backpressure: scale agents to review capacity, the same way a well-designed producer-consumer system scales producers to consumer throughput. The Towards AI breakdown (May 2026) extends this to production infrastructure costs: context replay at every agent boundary, supervisor-loop token overhead, tool-call retries, and observability trace storage all multiply before a single user sees a response. The orchestration tax is therefore both a human-attention tax and a compute cost tax. ## Yes, but The argument is not that multi-agent systems are bad. Both Osmani and the Towards AI analysis say explicitly that they are expensive by construction, and that cost should be a first-class architectural concern, not an afterthought. The key design question becomes: how much useful progress does this system make per model call, token, tool execution, and second of latency? That reframes the problem from raw parallelism to throughput efficiency. ## The bottom line The orchestration tax is an architecture problem, not a discipline problem. The concrete fix is treating your own attention as a bounded resource in the system design: split work into tasks that can run isolated in the background versus tasks where human judgment is the actual work, batch reviews instead of context-switching between half-finished threads, and never scale agent count past what your review pipeline can absorb. Read Osmani's original essay, then apply the backpressure question to your current agent setup: if every agent shipped a result right now, could you actually review them all? ## FAQ ### What is the orchestration tax? The orchestration tax is the gap between how fast AI agents produce work and how fast one human can review it. Addy Osmani coined the term at a Google I/O panel to describe the hidden cost of agentic workflows: launching agents is cheap, but closing the loop on their output requires human judgment that does not parallelize. The more agents you run, the deeper the review queue grows, which means throughput can stall even as activity increases. ### How does Amdahl's Law apply to AI agent workflows? Amdahl's Law states that the speedup gained by parallelizing a task is strictly capped by the fraction of work that must remain serial. Osmani applies this directly to agentic development: agents can run in parallel, but all architectural judgment, conflict resolution, and output verification still route through one human reviewer. That serial fraction sets a hard ceiling on how much value additional agents can add, no matter how many you launch. ### What is the practical rule for avoiding the orchestration tax? The core heuristic Osmani recommends is backpressure: scale your parallel agent count to match your review capacity, not to whatever the tool UI allows. A concrete signal that you have crossed the threshold is review queue depth, if open agent threads outnumber the diffs you can genuinely evaluate in a session, the system is producing faster than you can absorb. Splitting tasks into isolated (background-safe) work versus complex (judgment-required) work, and batching reviews instead of context-switching, are the two structural fixes the essay proposes. ### What is cognitive debt, and why is it a risk in multi-agent systems? Cognitive debt is the accumulated loss of mental model that happens when developers accept agent output without genuinely understanding it, because real review has become too exhausting. Osmani and the Diligesker analysis both flag it as a lagging failure signal: the damage does not show on the day the rubber-stamp happens, but when something breaks in production and no one can explain why the system works the way it does. The more agents run without proportional review quality, the faster cognitive debt compounds. ### Does the orchestration tax only affect developer attention, or does it also drive up compute costs? Both. The human-attention cost is Osmani's primary argument, but the Towards AI breakdown (May 2026) extends the analysis to production infrastructure: every agent boundary creates another opportunity to replay context, supervisor loops add token overhead, tool-call retries multiply model usage, and observability trace storage adds latency and storage cost. A single user request can internally trigger a planning call, multiple specialist calls, memory retrieval, validation, and retries, each one billing tokens. The orchestration tax is therefore both an attention tax and a compute cost tax. ### How does this change how teams should design agentic systems? Osmani frames it as a systems design problem rather than a personal productivity problem: you should architect your own attention the same way you architect any concurrent system with a bounded resource. Concretely, that means keeping agent parallelism proportional to review throughput, separating isolated tasks (which can safely run in the background) from judgment-heavy tasks (where the human review is the actual work), and treating review queue depth as a leading metric for system health. The Towards AI analysis adds a design-level question teams should ask before adding agents: how much useful progress does this component contribute per model call and token consumed? --- [View on Analog](https://analoghq.ai/es/addyosmani/articles/the-orchestration-tax)