I built a multi-agent platform. You probably shouldn't use one.

Put two people on the same task without telling either of them. You get a mess. They both finish, and now there are two versions that dont line up, and someone has to decide whose work to throw out. Nobody chose this. It just happens, the moment two people can change the same thing without checking with each other first. Which is why teams pile up rules about who's allowed to do what. Standups. A lock on the deploy. The one person who's allowed to push the release. It all looks like bureaucracy until the first time you skip it. Theyre the price of letting more than one person touch the same thing.

I went and built the maximal version of this, except with language models instead of people. And then most days I'd turn around and talk you out of needing it. Strange thing to say, I know, given I'm the one who builds it. So let me argue the case instead of just asserting it.

Smart people land hard on both sides. One well-regarded team went and argued, in public, that you shouldn't build multi-agent systems at all. The same week, another shipped a long and frankly proud writeup of one they'd built. Same week. So this isnt something you settle by being smart. It comes down to what you're building, and those two were building very different things.

People reach for more agents for an obvious reason. One model feels limited. Bolt on a second and it feels like adding a teammate, more hands, more output. The intuition is wrong, though, and it's worth being exact about how.

The expensive part of running a pile of agents together isn't the models. Or it is, but not the way you'd guess. Everyone budgets for the model calls. The cost that hurts is getting the agents to agree with each other, and no clever architecture makes it go away. It shows up the second there's more than one of them. And it grows faster than their number does.

Two agents, one relationship to keep straight. Add a third and you don't add one more, you add three. A fourth puts you at six. Every agent you bring in can collide with every agent already there, so it's the pairs that stack up, faster than the head count, and the pairs are the work. You add people hoping for throughput. What you mostly buy is more pairs to keep from drifting apart.

Add one agent. The team grows by one. The lines it has to keep in sync grow by the whole team.

Reads and writes don't work the same way, and that's where it starts. Ten agents can read the same document at once. A hundred. A thousand. Costs nothing but the reading. Two of them writing the same document, though, have to be reconciled somehow, and that reconciling is what costs you. You've watched this in anything you've ever run:

• One job waits on another that's waiting on it, and everything stops.
• A shared login hits its rate limit, and every task using it dies at once.
• A flaky step retries forever, burning money until someone notices and kills it.

None of that is the model failing. The model was fine every time. What broke was the system wrapped around it. The cost comes from how much the agents share, not how clever they are.

People who build distributed systems named these failures a long time ago. The write-write conflict. The lost update, where one change quietly paves over another. The fixes are old, and there are basically two. Funnel every write through a single leader, so one wins and the loser retries. Or use something like a CRDT that merges everyone's writes by a fixed rule. That second road is mostly shut to us. A CRDT can only merge mechanical state. An agent's write is a paragraph of judgment, from a writer that isn't even deterministic, and no rule fuses two of those while keeping what each one was trying to say. So you fall back on the oldest trick there is. Keep two writers off the same thing, push them through one, and let everyone read.

The same fact, drawn out. Two agents write one record as different shapes, a third tries to reconcile them, and the writes break the schema downstream. Reads combine cleanly. Writes don't.

And the bill makes it plain. A multi-agent run can chew through ten times the tokens a plain chat would, sometimes more. That overhead is the coordination cost showing up in the bill. Every agent has to rebuild the context the others already hold, restate what it's up to, and catch up on whatever changed while it was busy. What the user asked for is a sliver of those tokens. The rest is the agents keeping each other current.

Over the long haul it turns into a kind of debt. Not the cost of building the thing. The cost of keeping it coherent for as long as it runs. Every extra agent that can write to shared state is one more thing that can drift, one more road back to two people on one ticket. You pay it daily. Every single day it's up. And it gets worse the more writers you let in.

You can't out-think this with a smarter model. A smarter model doesn't stop the writes from colliding. Two things lower the cost. Fewer agents, or less shared between them. Everything else only shuffles the negotiation around.

That runs backward from how people usually talk, so it's worth sitting with. You split work across agents when one agent can't hold it all. Too much context. Too broad a task. A job that runs longer than one loop can keep in its head. The extra agents were a workaround for a limit, nothing more.

So a better model makes the case for more agents weaker, not stronger. It holds more, reasons further, stays coherent over a longer stretch, and that dissolves the very limit that pushed you to split the work up. The better it gets, the less you need to coordinate at all, because coordinating was a tax on splitting and you're splitting less. Capability points toward fewer agents. Almost nobody reads it that way.

This is why I'm wary of most things sold as multi-agent. A perfectly ordinary program gets dressed up in agent language, because agent language is where the money is this year. Not lying, exactly. Branding. And it's easy to deflate, which doubles as a test you can run yourself.

Take your system and rename every agent a function. Strip the names, the roles, the personas. The planner is now plan. The researcher, research. The writer, write. Now look at what's left. If plan calls research, gets a value back, passes it to write, and you can follow the whole thing as one program with a few slow, unreliable subroutines, you never had a multi-agent system. You had a plain program in a costume. One thing decided what came next and called other things to do small, bounded jobs, and they answered and went away. An orchestrator and a pile of tool calls. Which is a fine thing to be. It's what most systems should be, because we do know how to make plain programs correct.

The interesting case is the one where that rename falls apart. Now research and write are running at the same time, both reaching into the same shared state. Neither waits for the other to return, and each one's behavior bends to whatever the other did a second ago. That's an actual multi-agent system, and it's the only place the coordination cost buys you a thing. Everywhere else, the costume was all there was to it. Good news, really, because a plain program is far easier to keep correct than a standoff between things that don't fully agree.

And it isn't only my read. When people go and catalogue why these systems fall over, it's the same two culprits over and over: bad system design, and agents talking past each other. The model reasoning badly hardly registers. The fix everyone reaches for, a smarter model, isn't aimed where the trouble is.

I owe you the other half of this. The system I built is overkill for almost everyone, me included, most days. I'd rather say that plainly than sell you on it.

There is a band where the extra agents really do pay off. The easy version sits behind most of the impressive demos, and it's work that's mostly reading. The job is to explore a lot of directions at once, the material is bigger than any one context can hold, so you point a dozen agents at it and let them read in parallel. Reads don't collide. Aim a crowd of them at a big research question and they'll crush a single agent, because nobody is stepping on anybody. Even people who'd been skeptical for a year come around on exactly this, and only this: broad, parallel, bigger than one context. It's real, and it works. It also gets there by skipping the hard part, because nobody's writing, so nothing has to stay in sync.

The version worth building for is the hard one, and it's hard for every reason above. Some work is just too big and too tangled for one mind to hold, and not because the context window is small. Many parts that lean on each other. Real division of labor. Specialists you can't squash into a single prompt. And it runs longer than any one session. Less a task than a small organization. Here the rename test snaps. Call them functions and the program stops making sense, because they aren't subroutines. Each one carries context and judgment the others don't have, more than any single one could hold alone. You can't dodge the coordination here, so you build for it on purpose:

• roles with their own context and tools,
• clear ownership of who decides what,
• one layer whose only job is handing out work and reconciling the writes so the agents don't trample each other.

Even the people who first said don't build these have ended up roughly here. The setups that survive keep the writes single threaded and let the extra agents add intelligence, not more hands on the same state. Same superlinear coordination cost I warned about earlier. The difference is you can't do the work without paying it. So you pay on purpose, and what comes back is specialists who together hold far more than one mind could, kept coherent by a structure you designed instead of one that grew by accident. That's the difficult, interesting case, and most of it isn't built yet.

The discipline is knowing which case you're in. Almost everyone who thinks they're in the hard one is in the easy one, or in neither. Build the structure only when the work refuses to get any smaller. Wanting to build it doesn't count. Fits in one prompt? Keep it there. One loop can run it? Use the loop. You reach for the org chart only when the work won't fold into anything simpler, no matter how you push on it.

The one place it was clearly worth it for me was building the thing itself. OpenAcme is partly built and run by agents living inside OpenAcme. One writes code. Another's whole job is releases. A third keeps its own memory of what's half-finished and what's stuck behind something else. It never really settles. A bug gets filed, that turns into a code change, the change ships in a release, the release needs docs, and at the end someone still owes the reporter a reply. I ran it as one careful loop first. It worked badly. I'd braced for slow, thats the failure I expected, but slow was never it. One mind holding all of it averaged everything together. Right after an angry bug report, the code it wrote came out timid and over-defensive. Then it would spend a morning deep in a refactor and start answering users like they were a stack trace, all terse, no read on the person. Splitting the work into separate agents, each with its own memory and its own narrow job, kept the engineering caution and the release discipline and the user's voice from blurring into one gray average, which I cared about far more than throughput. And a bigger model doesn't save you here. Hand one agent ten times the context and it still averages the roles it's carrying. The extra room doesn't separate the roles, it just lets one mind hold more of them at once. I couldnt cleanly cut the work into pieces either, because that one bug report traveled through all of it, and the handoffs between roles were exactly what I couldn't pull apart. So each agent got its own identity, its own workspace, its own memory. The only thing they shared was the code and the tracker, and they reached those through the coordinating agent, one write at a time. The minute the work stops being read only, sharing one identity and one workspace is what makes two writers collide.

How the write-heavy case works. Each agent keeps its own identity and workspace, writes as itself, and reaches shared state one write at a time through the coordinator, while reads go to everyone at once. Permissions keep the writes apart, not trust.

So the engineering splits on which case you're in. For almost every system, the best thing you can do is make the agents behave like one careful person. Push the writes through a single path. Shrink what they share. Let one mind hold as much as it can, and peel off only what it can't. For the rare system that really is the size of an organization, the job flips, and gets harder. You're building the structure that keeps a crowd of specialists coherent without one mind holding the whole thing. That second problem is the one I care about, and it's why I build OpenAcme, a self-hosted platform pointed straight at it.

And if your best design keeps sliding back to a single writer, you probably never needed more than one.