Orchestrating Multiple Agents Without the Coordination Tax

Running one agent is simple. Running three agents at once is where developers abandon the approach. The coordination tax: merge conflicts, duplicated work, agents stepping on each other's files, eats the speed gains they promised. After eight months of daily multi-agent work, I have a pattern that survives real projects.

The Folder Boundary Rule

Each agent owns a folder. Not a branch, not a feature flag, a folder. If agent A is editing src/api/, agent B cannot touch any file under that path until A's work is committed. This sounds primitive. It works because filesystems enforce it without any tooling.

I hand each agent a prompt that explicitly lists its folder and a list of folders it must not read or write. When I run three agents in parallel, their scopes never overlap. Merge conflicts drop to zero because the agents are never touching the same files.

The Shared-Interface File

When agents need to coordinate, they share one file: a types file or an API schema. The orchestrator (me) edits that file first, commits it, then spawns the agents. Each agent treats the interface as frozen input. No agent rewrites the shared contract.

src/
  shared/types.ts      <- orchestrator owns, frozen during sprint
  api/                 <- agent A scope
  frontend/            <- agent B scope
  workers/             <- agent C scope

Serialization Over Communication

Agents do not talk to each other. They talk to the filesystem. Each agent writes its outputs and a short status note. The orchestrator reads notes at the end of each wave and decides the next wave. No chat between agents. No shared memory. Just artifacts on disk.

This pattern is what Git's design document calls content-addressed storage applied to agent work. Agents produce artifacts; artifacts compose.

What Scales and What Does Not

Three to five parallel agents is my ceiling. Past that, the orchestrator (me) becomes the bottleneck. I cannot verify ten agents' output in the time it takes them to produce it. That is the real limit: verification capacity, not agent capacity. Plan around the human in the loop, not the machines.

The Wave Model

Each sprint runs in waves. Wave one: three agents working in isolated folders on independent tasks. Wave two: review, merge, update the shared interface if needed. Wave three: next batch of agents kicks off with the updated interface as frozen input. Waves make the dependency chain explicit and keep the merge cost bounded. Attempts to run everything at once have always ended worse than a clean wave schedule, even when the work looks independent at first glance.