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.
O que faz
The orchestration tax is the hidden cost developers pay when AI agents produce work faster than one human can review it. Coined by Addy Osmani at a Google I/O panel, the concept uses Amdahl's Law and Python's GIL as analogies: no matter how many agents run in parallel, all judgment, conflict resolut
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.
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.
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.
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 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?
Notas de campo
Revisado em Jun 26, 2026
Ideal para
Resultados para quem cria
Ferramentas para experimentar
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.
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.
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.
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.
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.
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?
Research synthesis covering two 2025 papers on recursive multi-agent systems: RecursiveMAS and RAH, for developers building agentic pipelines.
Best for Developers designing or evaluating multi-agent orchestration architecturesA viral breakdown of AI agent loops, how Claude, ChatGPT, and Mira implement Plan-Execute-Verify cycles and when to actually build one.
Best for Builders who run the same AI task weekly or more and want compounding results instead of one-shot promptsA technical argument for replacing text chunks with structured QA packets in RAG pipelines, for ML engineers and data architects building production retrieval systems.
Best for ML engineers and data architects who own a RAG ingestion pipeline and want to fix retrieval at the sourceA curated breakdown of the Claude skills ecosystem, what skills are, how they work, and the handful worth installing first.
Best for Knowledge workers who need reliable document format conversions, such as PDF, DOCX, PPTX, and XLSX, on a daily basisA Claude skill is a folder of instructions that teaches Claude your team's way of doing a recurring task. Most are easy to build but quietly fail because Claude never reaches for them or the output is wrong. This guide shows you the few habits and the one testing loop that fix that.
How to turn Claude into a structured adversary by assuming your plan already failed, and a ready-to-upload skill that automates the pre-mortem for any decision.
Best for Builders who need adversarial critique before committing budget or time to a plan