Nobody builds the boring part of multi-agent: the coordination layer.

The multi-agent story everyone is telling right now is about reach and roster. Every coding agent speaks MCP, so an agent can touch every tool you have. And there is a new capable agent seemingly every few weeks, each one a little stronger than the last. Both of those are real, and both of them stop mattering the moment you actually run more than one agent against the same workspace.

I run several agents in parallel across the same set of repos. The day I put a second one to work alongside the first, the interesting problems stopped being about the models. They became about coordination, and coordination turned out to be the entire fight.

The problems are not new

Once there is more than one agent touching a shared workspace, the questions are immediate and unglamorous. Who is editing which file right now. How does one agent claim a piece of work so another does not pick up the same thing an hour later. What happens when two of them open the same file from stale copies and the last write silently wins, taking the other’s work with it. How does the agent that finishes a job hand off to the next one without a human relaying the state by hand.

None of that is artificial intelligence. It is concurrency, shared state, locking, and handoff — the oldest set of problems in computing. We solved versions of them decades ago for human teams and for services: version control with locks and merges, work queues, mutexes, leader election. The multi-agent wave is rediscovering the same problems at a different altitude, and mostly rediscovering them the hard way, one clobbered file at a time.

What actually breaks

The failure modes are boring and specific, which is exactly why they get missed. Two agents edit the same file from stale copies and one of them quietly loses its work. Both of them start the same task because nothing marked it as taken. One finishes a job and the next has no idea it happened, so it either redoes the work or builds on an assumption that changed underneath it. And when none of that is handled, the human becomes the message bus — copy-pasting status from one agent to another — which defeats the entire reason you wanted more than one agent in the first place.

None of these show up in a demo, because a demo is one agent doing one thing. They show up on day two, when the second and third agents are real and the workspace is shared.

The substrate I actually run

What fixed it for me was deliberately boring. A shared board the agents post to and read before they start anything, so each one knows what the others are doing. A job log where an agent marks a non-trivial job started when it begins and done when it finishes, so one glance tells you who is working on what. A claim ledger: before an agent edits a shared file, it claims that file and releases it when done, and it checks for someone else’s unreleased claim first and coordinates instead of clobbering. And the coordination rules themselves written into the config the agents read on startup, so the protocol loads itself into every session rather than living in my head.

The pattern underneath all of it is simple. Put the coordination rules where the agents will actually see them, and make the shared state append-only so the ledger is the source of truth instead of any single agent’s memory. The record is the authority. No agent gets to overwrite the history of what everyone else did.

Why it is the actual product

Here is the part I want to be direct about. The models are commoditizing — there is a new capable one every few weeks, and which one you pick matters less every month. The connectors are a solved problem — MCP turned “reach every tool” into plumbing you no longer think about. The thing that determines whether five agents produce five times the work or five times the mess is the coordination layer, and almost nobody is building it on purpose.

It is unglamorous work. It is, quite literally, a text file with claims in it. There is no framework to buy and no diagram that makes it look impressive in a deck. But it is the difference between a team and a pile-up, and it is the part no vendor is going to hand you, because it is specific to how your agents and your workspace actually fit together.

The takeaway

If you are wiring up more than one agent, build the coordination substrate before you add the third. The temptation is to spend your attention on which model, which framework, which elaborate orchestration graph. Spend it instead on the plumbing that keeps two agents from stepping on each other, because that is the part that fails silently and the part no one is going to build for you. The roster and the reach are solved. The coordination is on you — and once the agent count is greater than one, it is the whole game.