Editor's Note: As AI Agents become cheaper and easier to invoke, software development is entering a new phase: the problem is no longer whether we can launch more Agents, but whether humans still have enough attention to manage, judge, and integrate their outputs.

This article introduces a very thought-provoking concept—"orchestration tax." The cost of launching an Agent is low, requiring just a prompt or a click. But the subsequent steps are truly expensive: checking if the result is correct, understanding its impact on the system architecture, handling conflicts between different Agents, and finally deciding which code can be merged into the main branch. This work cannot be simply parallelized; it still returns to the same serial resource: human judgment.

The author compares developers to the "GIL" in an AI Agent system—the single-threaded lock that ultimately limits the throughput of a concurrent system. Multiple Agents can run simultaneously, but as soon as they enter phases like architectural judgment, code review, and conflict resolution, they must pass back through the developer's brain. Thus, more Agents don't necessarily mean higher output; they may just create a longer queue of tasks awaiting review, pushing the developer into more frequent context switching and cognitive fatigue.

This is also a point easily overlooked in the current wave of AI programming tools: a sense of efficiency is not always synonymous with real productivity. A dashboard filled with running Agents creates an illusion of "high productivity"; but if the developer doesn't truly understand, review, and integrate these changes, what the system ultimately accumulates may not be productivity, but technical debt and cognitive debt.

Therefore, the real discussion here is not "how to use more Agents," but "how to redesign workflows around human attention." In the age of Agents, the key skill is not just knowing how to ask questions or delegate tasks, but knowing which tasks can be handled in parallel by machines and which must be reserved for human judgment; knowing when to batch reviews and when to stop orchestrating to refocus on a core problem.

AI is expanding software production's concurrency capacity, but human attention remains the system's most scarce, non-replicable resource. A truly mature Agent workflow doesn't throw all tasks at the machine, but seriously designs its own attention architecture, much like designing a production system.

Here is the original text:

It's now very easy to launch more AI Agents. But having more Agents running simultaneously does not mean "you" have multiplied. Your cognitive bandwidth cannot be parallelized. All the judgment truly needed to guide them, evaluate results, and merge changes must ultimately pass through the same serial processor—you yourself.

The so-called "orchestration tax" is essentially the price you pay for forgetting this. And the only real solution is to start designing your own attention, just as you would design any concurrent system.

I recently participated in a roundtable discussion at Google I/O with Richard Seroter, Aja Hammerly, and Ciera Jaspan, talking about the current state and future evolution of software engineering. Near the end, Richard asked us: What's the one thing developers should take away from this and change?

I shared a point I've been pondering repeatedly these past months: Feeling busy is absolutely not equal to being productive. You can run 20 Agents simultaneously and feel incredibly busy. But that doesn't mean you've delivered the workload of 20 Agents.

Earlier in that conversation, Richard gave this problem a name. He said, "What you're describing is essentially the orchestration tax. You cannot successfully manage 20 Agents in your own head."

He was absolutely right. I want to unpack this concept more fully because this isn't a discipline problem; it's an architecture problem.

There was a line I almost casually uttered during that roundtable that has stuck with me since: Running multiple Agents does not mean there is another you in the world.

The Unaccounted-For Asymmetry

There is a hidden asymmetry in Agent workflows.

Launching an Agent is very cheap. You just press a key or write a prompt. But closing the loop on an Agent is not cheap at all. Someone must check if its returned result is correct and reconcile it with changes made by other Agents.

That someone is you. And there is only one of you.

Last month, I wrote about part of this problem in "Your Parallel Agent Limit," mainly discussing the ambient anxiety of not knowing which parallel thread is quietly failing. This article aims to discuss the structure behind this cost.

When you start viewing Agent development as a concurrent system, you realize that the human is just a component in that system. A very slow, serial component.

You Are the Single-Threaded Resource

If you've written concurrent code, you already possess the intuition to understand this problem. You've just been applying this intuition in the wrong place.

Python has the Global Interpreter Lock, or GIL. You can create as many threads as you want, but only one thread can execute Python bytecode at any given time because they all must acquire this lock first.

You are the GIL for your AI Agents.

They can all run concurrently. But whenever their work requires a genuine understanding of system architecture or needs to resolve merge conflicts, they must acquire that lock first. And there's only one of that lock, held by you.

Amdahl's Law states this very precisely: The speedup limit from parallelization depends on the portion of the work that must still be done serially. If a large part of your process cannot be parallelized, then no matter how many cores you throw at it, you'll eventually hit a hard ceiling.

In Agent development, that serial portion is judgment.

Launching 8 Agents does not accelerate your judgment time. It only makes the queue waiting for you longer.

This is a very old fact in performance engineering, yet many are still surprised by it: Optimizing a non-bottleneck part does not increase overall throughput. You're just piling up more unfinished work in front of the bottleneck.

Adding Agents optimizes the part that was never the constraint. The real constraint is the review phase, and the system's overall throughput is exactly equal to that phase's throughput.

The orchestration tax is the structural gap between Agent production capacity and what you can actually merge. It happens when you task a single-threaded resource with managing a concurrent system.

Pushing Harder Doesn't Solve Structural Limits

During that roundtable, I said something: I have never felt my tools so efficient, yet I have never felt so exhausted.

Both feelings are completely real, and they stem from the same reason.

This exhaustion has a very specific source: it's the feeling of keeping a serial processor at 100% utilization with no slack.

Every time you check back on an Agent that has left your sphere of attention, you pay a context-switching cost. You must flush your brain and reload another context from scratch.

A CPU can do this in microseconds, and architects still try to avoid frequent switching. It takes you minutes, and you can never perfectly restore context.

Five Agents are not 1x the workload repeated five times. It's five cold-start context reloads, plus a background brain process constantly worrying about which Agent you should be checking now.

You cannot solve a structural limit by "trying harder." This tax will always be paid.

If you try to brute-force it, it will eventually manifest in another form: either code reviews become increasingly shallow, or you enter a state of "cognitive surrender"—because forming your own judgment is too taxing, you simply accept whatever code the Agent wrote.

You either pay this tax consciously, or you let it slowly erode your understanding of your system in the dark.

Design Your Attention Like a System

So, you must treat your attention as a scarce serial resource.

You wouldn't design a distributed system without considering bottlenecks. Give your brain the same respect.

Here are some methods that have genuinely worked for me:

Scale your Agent team according to review capacity, not UI capacity.

A good concurrent system uses backpressure mechanisms to prevent queues from growing indefinitely. Producers must slow down to match the consumer's processing capability.

Your number of Agents is the producer; your review capacity is the consumer. The correct number of parallel Agents is the number you can seriously perform code reviews for. For most people, that's typically a low single-digit number.

AI tools will happily let you launch 20 Agents, but that's a UI feature, not an indication of your actual management capacity.

Categorize tasks.

When Richard asked me how I handle this, I mentioned this method. I separate tasks into two piles.

The first pile is relatively independent work I'm willing to delegate to Agents running in the cloud background. These tasks can be executed asynchronously and usually only require a final check from me.

The second pile is complex tasks where the real work *is* judgment. Like a weird bug or an architectural design.

The biggest mistake is trying to parallelize this second category as well. Parallelizing multiple complex tasks doesn't expand your output; it just causes that lock to be heavily contended for, ultimately degrading all results.

Batch reviews.

Each context switch costs you dearly. Sitting down to review results from 4 Agents in one go is much cheaper than checking one, doing something else, and cold-starting again for another.

Give your Agents a longer leash. Let work accumulate a bit, then process it as a batch.

Use that lock only for judgment.

Don't waste your brain on things a machine can verify on its own. Let Agents write tests that pass, or generate screenshots.

Let them prove the 80% of dull but verifiable aspects themselves. Then, your scarce attention only needs to focus on the 20% that truly requires human judgment.

Protect your serial time.

The bottleneck needs your best time, not the leftover scraps between Agent checks.

Sometimes, the highest-leverage action is to completely stop orchestrating: turn off the computer filled with Agents, focus solely on thinking about one problem, and hold that lock firmly throughout the entire process.

Orchestration is not the real work. It's just the overhead generated around the work.

Aja pointed out that architectural ability has become the most urgent skill now: you need to know what tasks fit into an Agent and what tasks are too big for it.

I'd add: You yourself are also a component in this system. Your attention has a known, low serial throughput. The system either respects this number, or it will bypass it by quietly lowering your standards.

Busy Does Not Equal Productive

This point is crucial because this failure mode is almost invisible to you personally.

Twenty running Agents give you a feeling of "productivity explosion." The dashboard is full, everything is moving. But this feeling has become decoupled from actually merging high-quality code into the main branch.

You can be busy to the limit yet produce almost nothing real. From an internal experience, these two states feel almost identical.

Ciera mentioned Margaret-Anne Storey's research on debt. We talked about technical debt and cognitive debt.

Unpaid orchestration tax makes you accumulate both simultaneously.

You merge things you haven't read carefully. Your mental model of the codebase becomes completely outdated. These problems won't appear on the dashboard today. They'll surface when production breaks—when you look at the system and suddenly realize you no longer understand how it actually works.

So, the real conclusion is: Launching Agents is not a capability. Anyone can run 20.

The real capability is designing the system around that resource which cannot be cloned, cannot be parallelized.

That resource is your attention.

Design it as you would design any key component your production environment depends on.