Imagine a research agent finding an old pricing page. It passes the number to a planning agent, which builds a recommendation around it. A third agent writes the report. The report is clear, internally consistent and wrong.
Nothing in that chain requires an especially bad model. The first agent lost the date. The second treated an assertion as evidence. The third made it easier to believe. Adding another reviewer might help, provided it checks the original source. A reviewer reading only the report may approve the same mistake.
That is the part of multi-agent systems I find more interesting than their job titles. Researcher, planner, critic, supervisor: the names suggest an organisation. They tell us very little about what happens when two agents disagree, or when a tool fails halfway through a write.
- A sourceOld price, dated page
- A summaryPrice retained, date lost
- A decisionConfident recommendation
A conversation is a poor database
It is tempting to put everything into a shared transcript. Everyone gets the context. Nobody has to design a schema. Then the transcript fills with abandoned plans, repeated tool output and confident summaries of uncertain results.
An agent reading that history has to reconstruct the current state before doing its own work. Was the booking completed, or merely proposed? Did the user change the date? Is the latest message a correction or a second opinion? These distinctions get expensive when the system is allowed to act.
I would start with a much smaller handoff:
{
"claim": "The listed price is 49",
"source": "pricing-page-snapshot-17",
"observed_at": "2025-07-28T09:30:00Z",
"currency": null,
"status": "needs_verification"
}This is an illustrative record, not a complete schema. Its useful feature is the missing currency. The next agent can see what it does not know. A polished sentence such as “the plan costs 49” would hide the same gap.
Where the failures collect
The 2025 study Why Do Multi-Agent LLM Systems Fail? examined five frameworks across more than 150 tasks. Its taxonomy groups failures around system specification, coordination between agents, and verification or termination. That is evidence about the systems and tasks studied. It does not establish that 90% of production projects fail. Read the paper.
For a system I was about to ship, I would want answers to a few unglamorous questions:
- Who can change the shared state, and how does another agent learn it changed?
- What evidence must accompany a result before it becomes an input to the next step?
- What happens if a tool succeeds but its acknowledgement is lost?
- Who decides that the task is complete, and what do they inspect?
A private scratchpad can help an agent reason without flooding everyone else's context. It also creates another boundary where useful information can disappear. Isolation needs an explicit handoff. Shared memory needs rules about authority and freshness. Neither arrangement removes the need to decide what the system believes.
- Result + evidenceKeep origin and uncertainty
- Independent checkReturn to the source
- State changeRecord what succeeded
Earn the extra agent
My default would be one agent, a small set of tools and an evaluation set built from the work it needs to do. Add a second agent when it buys something specific: parallel research, an independent check against evidence, or access to a different set of permissions.
Then compare the two systems on the same tasks. Count successful outcomes, cost and elapsed time. Read the failures. In particular, replay the awkward cases: an empty search result, a stale document, contradictory instructions, a tool timeout after an action has already happened. An architecture that looks sensible on a whiteboard can behave very differently after that timeout.
Sometimes the second agent will be worth it. Sometimes it will turn one uncertain answer into a meeting about the uncertain answer. The evaluation should be able to tell those apart.