We Build Fewer Agents That Talk to Each Other
The architecture diagram had a planner, a researcher, a writer, a critic and a supervisor. It worked in the sense that something came out the other end, and when the output was wrong nobody could say which agent had been responsible.
The Design That Looked Right
Five agents, each with a role that reads like a job description, passing work between them. It is the architecture everyone draws first, partly because it maps onto how a team of people would divide the task and partly because it demonstrates beautifully.
Ours produced a report on a supplier from internal documents. The reports were fluent, the plans were sensible, and about one in six contained a claim that no document supported. Tracing that claim back through five conversational handoffs took an afternoon each time.
Where the Failures Actually Were
Cemri and colleagues published a study in 2025 examining why multi-agent systems built on language models fail, organising the failures into a taxonomy across specification, inter-agent misalignment and verification.
Reading their categories against our own incidents was uncomfortable, because almost none of our failures were an agent being incapable. They were an agent receiving a summary of a summary, a step assuming a constraint that had been mentioned two handoffs earlier, and nothing checking the result at the end.
What We Replaced With Code
The planner became a fixed sequence, because the task has four steps in a known order and a model deciding that order every time was variability without benefit. The supervisor became a loop with a retry limit. The critic became a validator with rules.
That left one agent doing retrieval and one doing writing, with everything between them being ordinary control flow. The rewrite took about a week, the unsupported-claim rate fell from one in six to under one in thirty, and a failure now points at a step rather than at a conversation.
| Component | What it became |
|---|---|
| Planner | A fixed sequence in code |
| Supervisor | A loop with a retry limit |
| Critic | A validator with explicit rules |
| Researcher and writer | Kept. Two agents, clear boundary |
Why Summaries Between Agents Are the Problem
Each handoff compresses. An agent passing work to the next one sends a summary of what it did, because sending everything defeats the point of separating them, and every compression drops the detail that the next step needed and did not know it needed.
The failure is not that the compression is bad. It is that the compressing agent cannot know what the receiving agent will require, and in a five-step chain the information loss compounds until the last step is working from a description of a description.
Where a Second Agent Still Earns Its Place
Two situations. When the second one has a genuinely different tool set and a different scope, such as a read-only research agent and a separate agent that can write to a system, where the separation is a permission boundary rather than a division of labour.
And when the work is naturally parallel and independent: five documents summarised at once by five instances is not a multi-agent system in any interesting sense, and it is the case where the pattern is simply correct.
Why the Diagram Is So Persuasive
Because it maps onto human organisation, and human organisation solves coordination problems that these systems do not have. A team of five has shared context, informal clarification and someone who notices when the brief has drifted, none of which survives translation into a message-passing pipeline.
The diagram also makes the system look more capable than a sequence of steps, which is a presentation problem more than an engineering one. We now draw the honest version in first meetings, which is less impressive and has never lost us work.
What We Ask Before Adding One
What can this agent do that the previous one cannot, in terms of tools or permissions? If the answer is only that it has a different instruction, it is a step in a pipeline and should be written as one.
And what happens if it is wrong? A step whose output is checked by a rule is safe to add. A step whose output is checked by another model is a second thing that can be wrong in a correlated way, which is not the same as verification.
What We Do Not Claim
We do not claim multi-agent architectures do not work. They clearly do for some tasks, particularly open-ended ones with no fixed sequence, and our conclusion is scoped to bounded business workflows where the sequence is known in advance.
We also do not claim our one-in-thirty rate is attributable to the architecture alone. We changed the validator at the same time, and honestly separating those two effects would have required a slower experiment than the project could afford.