Part 2: Multi-Agent Ops as Ambiguity Management

I gave two agents the same two-line brief. They built two different things.

Neither one misread it. The brief genuinely meant both.

That’s the moment I stopped thinking of my problem as a coordination problem and started seeing what it actually was.

The brief said, roughly, “add tests to catch the 500s.” To one agent that meant integration tests against the live path. To the other it meant unit tests around the response handler. Both defensible. Both, honestly, things I might have wanted. The ambiguity wasn’t a bug in their reading. It was sitting right there in my words the whole time, and two competent minds resolved it two different ways.

I had written a ticket with no acceptance criteria and handed it to two people at once.

More agents didn’t fix this. More agents made it worse. More readings, more divergence, more confidently-built wrong things.

Here’s the reframe I keep coming back to.

The job of running a multi-agent system is not adding agents. It’s not picking models. It’s managing the ambiguity that lives in the gaps between them.

Every brief has slack in it. Every hand-off is lossy. Every goal that’s clear in my head is fuzzier the moment it’s words, and fuzzier again by the time it’s reached the third agent in the chain. The work of the system isn’t generating output. The agents are great at output. The work is compressing ambiguity: turning a fuzzy goal into a sharp one, fast enough, before five agents resolve the fuzz five different ways.

Think about where ambiguity hides.

It hides in the brief, when my two lines admit three interpretations. It hides in the hand-off, when one agent passes work to another and the why doesn’t survive the trip. It hides in ownership, when a decision has no owner of record and two agents both think the call is theirs. It hides in done, when “finished” means “I wrote code” to one agent and “it’s verified working” to another.

Nobody had written the definition of done, so every agent quietly wrote their own.

Each of these is an ambiguity gap. And a multi-agent system is, structurally, a machine for multiplying those gaps. Every additional agent is another place intent can fork. That is fan-out, and fan-out has no opinion about the quality of what it is multiplying.

That’s the counterintuitive part. The thing that makes a fleet powerful (many minds working in parallel) is the exact same thing that makes it dangerous. Parallelism amplifies whatever ambiguity you feed it.

Which tells you what the actual leverage is.

The leverage is not in making each agent smarter. A smarter agent resolves ambiguity more confidently, which, if it resolves it the wrong way, is strictly worse. A brilliant agent building the wrong thing decisively is more expensive than a mediocre one that raises a blocker.

The leverage is in shrinking the gaps. Sharper briefs. Explicit ownership so there’s one DRI per decision, not five. Hand-offs that carry intent, not just the artifact. A shared definition of done. Every one of these is an ambiguity-reduction mechanism, and every one of them does more for the system than swapping in a bigger model.

So when people ask how I’d make a fleet better, I’ve stopped reaching for “add an agent” or “upgrade the model.”

I reach for: where is the ambiguity, and who’s responsible for compressing it?

That’s the real job. Multi-agent ops is ambiguity management wearing a trench coat. The agents supply the breadth: the many readings, the many attempts. Something in the system has to supply the narrowing. Right now that something is mostly me. The whole design question is how much of that narrowing I can push into the structure itself, so I’m not the only thing standing between a fuzzy brief and five divergent builds.

Two agents, one brief, two builds. The fix was never a third agent. It was a sharper sentence.