Multi-Agent Systems in Production

Every vendor demo now seems to end the same way: one agent hands work to another, a third checks it, a fourth reports back. It looks like a team. It demo-animates like a team.

Production is less kind. The honest summary of what has actually been measured so far is narrower and, we think, more useful: multiple agents help a lot on one shape of problem, and actively hurt on another. The dividing line isn't the framework you pick or the model you run. It's how tightly the pieces of the work depend on each other.

Where it earns its keep

The strongest published result is a research system, and the shape of the task explains the result. Anthropic's multi-agent research system puts a lead agent in charge of planning and synthesis, with subagents searching in parallel, each in its own context window. On Anthropic's internal research evaluation it outperformed a single agent by 90.2%, and token usage alone explained most of the performance spread the team measured. Research rewards that shape: the question breaks into independent directions, each direction is mostly reading, and a subagent that goes down a dead end doesn't corrupt the others. Its findings come back as text for the lead to weigh.

Notice what the subagents don't do. They don't build on each other's half-finished work. They don't make decisions the others have to live with. They gather, compress and report, and the one agent that decides sees all of it.

That pattern generalises beyond research. Checking a claim against many sources. Reading a large document set where each document can be judged on its own. Triaging a queue of independent items. Fan-out works when the units are separable and the cost of one unit failing is a retry, not a rebuild.

Where it breaks

Split a piece of making in half and the failure shows up immediately. Cognition's widely argued essay, Don't Build Multi-Agents, makes the point with a small example: two subagents building halves of one game, each working reasonably, producing pieces built on conflicting assumptions that no final agent can cleanly merge. Their underlying claim is the one to hold onto: every action an agent takes carries decisions it never stated, and agents that can't see each other's decisions will eventually make incompatible ones.

This isn't only an argument from one team's experience. The MAST study built a failure taxonomy from more than 1,600 annotated traces across seven multi-agent frameworks, found failure rates of 41% to 86.7% across the systems it examined, and sorted the failures into three buckets: system design issues, misalignment between agents, and failures of verification. Read that list slowly. None of the three is "the model wasn't smart enough." They're coordination failures, the same class of problem that makes human projects fail, except that agents hold the misunderstanding silently and execute it at machine speed.

There's a second, quieter cost. More agents means more tokens, and not a little more. Anthropic reports its multi-agent system using roughly 15 times the tokens of a chat interaction, against about four times for a single agent. Fifteen times the spend buys a real gain on the right task. On the wrong one it buys you a faster, more expensive route to an answer one agent would have reached, plus a synthesis step where errors from several threads get averaged into something that reads as consensus.

The test we apply

Before a deployment goes multi-agent, we want four answers, and they have to be yes in the work itself, not in the pitch for it.

Can the task be split into pieces that don't need to see each other working? If piece B changes its mind when it learns what piece A decided mid-flight, you don't have two tasks. You have one task and a coordination problem wearing a costume.

Is the work mostly reading, searching and judging — rather than writing into shared state? Parallel readers are cheap to reconcile. Parallel writers are not.

Can each piece's output be checked on its own, before anything is merged? A verifier that only sees the combined result arrives too late; by then you can't tell which thread introduced the error. Verification belongs at the boundary of each subagent's work, where a bad output is still small.

Is the task valuable enough to pay roughly an order of magnitude more in tokens for a faster or broader answer? Sometimes it plainly is. Often the honest answer is that a single agent, given better tools and a well-built context, gets there for a fraction of the cost.

When those answers are yes, the architecture that holds up is boring in a good way: one lead agent that plans, delegates with written briefs that state the objective, the boundaries and the output format, and synthesises; workers that return findings rather than half-built artifacts; and a check on each return before it enters the lead's picture of the world. Anthropic's team found the briefs mattered more than expected: vague delegation was behind duplicated work and gaps in its early versions. That's familiar to anyone who has managed people. It turns out to be just as true here, and less forgiving, because an agent won't come back and ask what you meant.

What still isn't working

Real-time coordination is the open problem. Agents are poor at renegotiating a plan mid-task, at noticing that a sibling's output invalidates their own, at knowing when to stop. Frameworks will keep adding protocols for agent-to-agent communication, and some of that plumbing is useful. But a message bus doesn't fix a spec problem, and most of the failures in the MAST taxonomy are spec and coordination problems, not plumbing problems.

Our position is simple, and it will probably age: default to one agent. Add a second when the task's shape demands breadth that one context can't cover (not the demo, not the org chart in the slide), and keep the deciding in one place while you do it. The teams publishing the best results are, underneath the diagrams, doing exactly that.

Work with us

Splitting a workflow across agents is easy to demo and hard to keep honest in production. If you're deciding where a single agent ends and a team of them should begin, bring the workflow to Trida AI's intake and we'll work through the shape of the task with you.