The
Coordination Tax.

Working alone has an underrated advantage: the distance between a decision and its execution can be almost zero.

I can look at a problem, choose a direction, change my mind, and keep moving. I don't have to explain every decision before making it. Nobody needs to translate my thinking into another person's task.

But that's also the danger. When one person makes every decision, that person can become the only place work is understood, approved, or recovered when something breaks.

Teams are supposed to solve the capacity problem. More people bring more skills, viewpoints, attention, and available hours. Yet they also introduce a strange new kind of work: explaining the work, dividing the work, confirming who owns it, checking it, integrating it, and sometimes doing it again because everyone understood the same sentence differently.

The invisible work around the work

I want a name for that overhead: the coordination tax. Not because collaboration is bad, but because collaboration has a cost that a project plan rarely makes visible.

It's tempting to count people's hours and assume they add together. The actual outcome depends on how much meaningful work can happen independently—and how much must happen between people before the result is usable.

More capacity is not the same as more throughput.

Once AI agents join the picture, the question gets more interesting. A solo operator may now direct several automated workers. Does that mean the operator has a team? Or has the coordination tax simply changed its form?

The contradiction

More people can help. More people can also slow things down.

I don't think there's a magic team size. A 2023 meta-analysis covering 208 studies found essentially no overall association between team size and team task performance. The picture changed with the work: larger teams tended to help more with complex tasks, while coordination demands could work against performance on relatively simple ones.

That's a much more useful result than saying small teams always win. A difficult project may need people with different expertise, independent judgment, and enough time to investigate problems in parallel. But a straightforward task can become absurdly complicated when everyone needs to stay informed.

Communication itself is not the enemy. A meta-analysis of team communication found that communication quality had a stronger relationship with team performance than communication frequency. Better conversations are not necessarily more conversations.

That suggests a different optimization goal: minimize unnecessary coordination while protecting the conversations that improve the result.

A meeting that prevents a serious mistake is not the same kind of meeting as one that exists only because ownership is unclear. Treating both as identical overhead would be its own systems-design failure.

The AI complication

A person with five agents is not automatically a five-person team.

AI changes how much work one person can attempt. I can imagine a single operator asking one agent to research, another to draft, a third to test, and a fourth to compare the output against requirements. That resembles delegation. It also creates a new supervisory job.

Someone still needs to decide what success means, which sources can be trusted, what may be changed, what requires approval, and who owns the consequences of an error. If the agents disagree or produce incompatible work, the human does not escape integration; they inherit it.

AI assistance has measured benefits. In a 2025 published study of 5,172 customer-support agents, access to an AI assistant increased issues resolved per hour by 15% on average, with gains concentrated among less-experienced workers. That's evidence for augmentation in one workplace setting—not a universal productivity multiplier for autonomous agent teams.

The results can also go the other way. A 2025 randomized study of 16 experienced developers and 246 tasks found that early-2025 AI tools increased completion time by 19% on familiar open-source projects. Importantly, METR's February 2026 update cautioned that its newer measurements were too biased to establish a reliable contemporary speedup. So I would not present the earlier slowdown as a prediction for today's models.

What happens when the agents coordinate with each other?

Google Research evaluated 180 agent configurations in 2026. On a parallelizable financial reasoning benchmark, centralized multi-agent coordination improved performance by 80.9% over a single-agent baseline. On a sequential planning benchmark, multi-agent variants performed 39–70% worse. Those figures describe particular controlled benchmarks, not business-wide ROI.

That distinction matters. Some tasks are naturally separable. Several sources can be researched independently; multiple test cases can be run at once. Other tasks depend on a shared interpretation of what has already happened. Splitting those into agents creates more interfaces where context can be lost.

Anthropic's account of its multi-agent research architecture describes another tradeoff: more parallel breadth, but far more tokens and coordination work. Its reported multi-agent runs used roughly 15 times the tokens of ordinary chats in that product context. More agents can buy better work; they don't necessarily buy cheaper work.

So I don't want an army of agents because it looks impressive. I want the smallest arrangement that can reliably produce and verify the intended result.

A working decision framework

The Delegation Threshold

Instead of asking whether solo work or teamwork is better, I want to ask how the task behaves. Can I define it clearly? Can independent parts proceed without waiting? Can I verify the result? If something goes wrong, is the mistake reversible?

Notice that these are operating modes, not fixed identities. A person can work solo on Monday, use agents for research on Tuesday, and bring a human team together for a production release on Wednesday. A human team can also use agents internally. The boundaries are fluid.

The threshold rises when the outcome is hard to evaluate or expensive to reverse. It falls when a task can be specified in a sentence, independently tested, and safely thrown away if it fails.

That's why the first question shouldn't be, Who else can I assign this to? It should be, What part of this work is actually ready to be delegated?

Four situations where I'd choose differently

These are illustrative decisions, not case studies from projects I'm claiming to have delivered. The point is to test the framework against real kinds of work rather than turn it into a motivational diagram.

The limit of optimization

A team is not just a throughput machine.

Here's where the tax metaphor becomes dangerous if I take it too far. It can make collaboration sound like a penalty and independence sound like virtue.

People are not interchangeable workers in a queue. A teammate can disagree with my assumptions, see a risk I missed, hold context when I'm unavailable, develop expertise over time, or build trust with another person. Those benefits may not appear in this week's shipping numbers.

And a solo operator who must inspect every agent result can quietly become an approval bottleneck. If the only way to make the work safe is to personally re-do all of it, how much did the delegation accomplish?

Sometimes coordination is the work. Teaching someone, negotiating a difficult decision, or reconciling competing needs cannot always be compressed into an efficient handoff. The goal isn't to remove the human relationship. It's to stop wasting that relationship on avoidable confusion.

I think that requires distinguishing coordination that creates understanding from coordination that compensates for a poorly designed system.

Measure the result, not the headcount.

If I wanted to know whether adding a collaborator or agent actually improved a workflow, I wouldn't start by counting prompts, people, meetings, or tasks completed. Those are activity measures.

I'd watch the time between a request and a verified outcome. I'd count reopened work and errors caught after delivery. I'd notice how much review time the owner spent, whether another person could take over, and whether we could reverse a bad decision without losing data or trust.

1. What is the smallest deliverable? Define something a real person can review or use.
2. Which parts are truly independent? Parallelize those; keep tightly dependent reasoning together.
3. Who can tell whether it's right? If verification is unclear, delegation isn't ready.
4. What happens when it fails? Specify a recovery path before granting autonomy.
5. Who owns the final judgment? Tools and colleagues may contribute; accountability still needs a name.

This leaves me with a less fashionable ambition than building the biggest team or deploying the most agents: design work so that adding capability genuinely helps.

Am I adding someone because the work needs another mind—or because I haven't made the work clear enough to do?