When Multi-Agent Systems Become Fragile in Production

The demo held. The system didn't.

Your multi-agent pipeline passed the demo in March. It drafts, then reviews and merges. Six months later a support ticket says the weekly summary is wrong, and nobody can tell you which step introduced the error. The reviewer agent approves things it should reject. Someone opens the context folder and finds fourteen files, three of which nobody wrote on purpose.

The models are doing what they were asked. The scaffolding around them has become the system, and nobody has a map of it.

Tanner Kohler at Nielsen Norman Group spent time with people building these systems, many of them without an engineering background, and named what he found: a new big ball of mud. His definition borrows from Foote and Yoder's 1997 paper. A big ball of mud is a system scraped together for short-term function, with no plan for long-term durability. It works, and it's expensive to keep alive.

Throwaway code becomes load-bearing

The first pattern Kohler describes is throwaway code. Someone asks an agent to build a small thing, say a rules file that stops the agent from repeating an annoying behavior. Nobody tests the file, because it's a first draft. Then workflows adapt around it, and the draft starts holding weight.

One participant in Kohler's sessions described a daily automation that summarized email, tasks, and meeting notes into the day's priorities. He said he was "stuck in the way that it works" and had never taken the time to rebuild it. The piece works well enough that nobody has examined it, and it sits in the path of everything else.

Kohler points at the economics. AI makes building cheap, so nothing forces anyone to prioritize, and people overbuild. One advanced participant told him people overbuild "because it feels productive." That's an incentive problem you can watch in your own backlog, since when adding an agent costs an afternoon, removing one costs a conversation.

Why five agents fail differently than one

A single agent with a bad context file gives you one place to look. Five agents sharing context files, a router, and a merge step give you a distributed failure. Kohler describes the result as accumulated complexity: the system gets hard to direct, and diagnosing a wrong output turns into archaeology.

There's a second failure mode that has nothing to do with context drift. Parallel agents can each make a useful local edit and still degrade the shared result when the edits combine. A recent preprint on parallel agent collaboration treats this as block optimization over a known dependency graph. Edits that don't touch each other form independent sets, and their gains add exactly when you measure each one against the same current solution. Edits that interact need a coordinator that can evaluate the combination.

The paper proves that an optimal fractional coloring produces a merger that keeps a 1/χ_f(G) fraction of the total verified local improvement, where χ_f(G) is the graph's fractional chromatic number, and that the bound is tight among mergers that select a subset of the same proposals. If the notation loses you: some fraction of the good work survives the merge, and the size of that fraction depends on how tangled your dependency graph is.

"Verified" is the word carrying the weight. The guarantee applies when you can score a candidate exactly against the current solution. If your merge step concatenates outputs and asks a model to reconcile them, you have no verified gain and no bound.

What the experiments showed

In the preprint's code-repair and road-network experiments, verified merging resolved conflicts between individually useful edits that made naive merging fail. On larger tasks without conflicts, parallel agents reduced modeled completion time at higher input-token-equivalent cost, which is the trade you'd expect. Three public road networks gave a different test: fractional integration retained 922 units of verified graph-cut improvement across 90 paired runs. For route-search agents sharing exclusive access to vehicle routes, fractional scheduling reduced measured wall time by a median of 15% across twelve paired runs, and route-cost changes varied from run to run.

That last clause matters if you're reading this as a performance claim, because a median of 15% across twelve paired runs is a signal, and the spread in route cost across those runs says the scheduling changes outcomes as well as speed.

The Monday move

Pick the merge step before you pick the sixth agent. Write down how two agents' outputs combine, and how you score the combined result against the current one. If you can't score it, you've found a coordination problem you can't measure, and adding agents will make it worse without telling you.

Then take inventory of what your agents read. Open the context folder and list every file, mark which ones have changed agent behavior in the last month, and put those under review with a named owner; freeze or delete the rest. Kohler's participants kept their throwaway pieces for two reasons: no time, and fear of breaking something that worked. Both are real, and a file nobody can explain is a file you'll be debugging during an incident.

Where this argument is weak

The fractional-coloring guarantee assumes a dependency graph you can enumerate and an objective you can evaluate exactly. Most production agent systems have neither. If your merge criterion is "does this read well to a human reviewer," the math doesn't reach you, and you're back to sampling outputs and hoping.

I'd change my view if someone showed me a heavily scaffolded multi-agent system where a wrong output gets traced to its source in under an hour, without a rebuild. Neither source describes that. Kohler's study draws on sessions with builders, and it doesn't report production failure rates. The arXiv paper is a preprint with results from code repair and road networks, and it doesn't describe a deployed multi-agent product.

Both sources describe mechanisms that show up in production, and neither one tells you how often. You can still act on the mechanism.

Open the context folder your agents read from, count the files, and ask two people on the team to explain what each one does. Where their answers diverge, you've found the first thing to fix.