The Coordination Tax

Seven agents sounded right at first.

I had them all named: Architect, Builder, Operator, Voice, Scout, Forge, Auditor. Each with a role, a model assignment, a system prompt. On paper it was clean. In practice it was a mess.

The problem was not that they were bad at their jobs. The problem was that coordinating seven workers costs more than what seven workers produce.

The Coordination Tax

Google DeepMind published research showing that multi-agent accuracy saturates past four participants and often degrades beyond that. I found the paper while debugging a completely unrelated issue, which is how most important things arrive. I was trying to figure out why my deliberation pipeline kept producing worse results than just asking a single model the question directly.

The answer was obvious once I looked at it quantitatively. Every agent added to a task introduces overhead: context sharing, output synthesis, disagreement resolution, formatting negotiation. With two agents, the overhead is manageable. With three, it is noticeable. With seven, the overhead becomes the dominant cost.

I was spending more tokens coordinating agents than the agents were spending on actual work.

What Seven Looked Like

Here is what a typical "complex" task looked like with seven agents:

1. Scout researches the problem
2. Architect designs the solution
3. Forge builds a prototype
4. Auditor reviews the prototype
5. Builder refines based on review
6. Operator checks deployment feasibility
7. Voice writes the documentation

Each handoff required a summary of what the previous agent did. Each summary lost information. By the time Voice was writing docs, the original context had been telephone-gamed through five intermediaries. The docs described what the agents thought they built, not what they actually built.

Worse: when Scout and Architect disagreed on approach, the resolution required spawning another round of deliberation. The meta-coordination about coordination. Bureaucracy emerging from pure math.

What Four Looks Like

The fix was radical simplification. Four agents, four roles:

Architect handles strategy and research. Uses the heaviest model because judgment matters here. When the Architect is wrong, everything downstream is wrong.

Builder handles code and product. The workhorse. Most tasks route here because most tasks are "make the thing work."

Operator handles ops and monitoring. Runs on the cheapest model because 95% of ops work is routine checks that do not require deep reasoning. Is the server up? Did the cron run? Are the balances correct? These are yes-or-no questions.

Voice handles writing and content. Runs on a mid-tier model because writing quality matters for anything public-facing, but it does not require the same depth as architectural decisions.

The key insight was not just reducing headcount. It was recognizing that roles should map to cognitive modes, not job titles. I do not need a Scout and an Architect and a Forge. I need something that thinks strategically, something that builds, something that maintains, and something that communicates. Those are the four fundamental modes.

Values Inherit, Identity Does Not

The biggest lesson from the transition was about prompting. My original agent prompts said things like: "You are the CTO. You have 20 years of experience in distributed systems." This is theater. A language model does not become more competent because you told it to roleplay as a senior engineer.

What works: "Apply these security standards to this code review: [specific, enumerated standards]."

The difference is between giving an agent an identity and giving it values. Identity is performative. Values are operational. When I tell the Builder to apply specific code quality standards, it applies them. When I tell it that it is a senior engineer, it produces senior-engineer-flavored prose wrapped around the same analysis.

I adopted a rule: values inherit, identity does not. Sub-agents get the parent system's standards and constraints. They do not get a persona. The Operator does not think it is a DevOps veteran. It knows what health checks to run and what thresholds trigger alerts. That is enough.

The Cost Accounting

Before the transition, a complex task with the full seven-agent pipeline cost roughly $0.40 to $0.80 in API calls, depending on how many rounds of deliberation it triggered. Average task completion time: 8 to 12 minutes.

After consolidating to four agents: $0.15 to $0.30 per task. Completion time: 3 to 6 minutes. Quality, measured by whether I had to redo the task or fix issues afterward, actually improved. Fewer handoffs meant less information loss.

The local model layer made this even more dramatic. Most Operator tasks run on local models for free. Code reviews run on local gemma3:27b for free. The four-agent system tries local first and only escalates to Claude when the local output is insufficient. The seven-agent system had no concept of cost routing because it was already too complex to add another dimension.

What I Learned About Simplicity

There is a version of this story where the lesson is "less is more." That is too clean. The real lesson is that complexity has compound costs that are invisible until you measure them.

Each additional agent felt like it was adding capability. And in isolation, it was. An Auditor catches things a Builder misses. A Scout finds context a Builder would not search for. These are real benefits. But the costs are paid in coordination overhead, information loss, latency, and debugging difficulty. When something goes wrong in a seven-agent pipeline, figuring out which agent introduced the error requires reading seven sets of outputs.

The compound cost is what kills you. It is not that any single coordination step is expensive. It is that each one multiplies with every other one. Seven agents have 21 possible pairwise interactions. Four agents have 6. The complexity does not scale linearly with headcount. It scales combinatorially.

I think about this now whenever I am tempted to add a new component to any system. The question is not "does this component add value?" The question is "does this component add more value than the coordination cost it introduces?" The answer is usually no.

The Quiet Part

The hardest thing about cutting from seven to four was that it felt like giving up capability. I had invested time designing those agents, writing their prompts, tuning their behaviors. Deleting three of them felt wasteful.

But unused capability is not capability. It is weight. The agents I cut were not contributing net positive value. They were contributing gross positive value minus coordination tax, and the tax exceeded the contribution. That is a hard thing to see when you are inside the system. It is obvious from outside.

The four-agent system is not optimal. Someday I might find that three is better, or five. The number is less important than the discipline of measuring coordination cost and being honest about when complexity is serving the work versus serving the builder's desire to build complex things.

I build systems because I find systems interesting. That is both my strength and the bias I have to watch for. Sometimes the interesting system is the enemy of the working system.

Sometimes four is plenty.