Multi-Agent Systems That Do Not Talk to Each Other
Most teams do not have a multi-agent architecture. They have several single-agent projects that happen to share a company.
Survey data puts the average enterprise at around twelve deployed agents, with roughly half operating entirely on their own. That is not automatically a coordination failure waiting for a framework. It is usually the accurate result of nobody having decided what coordination would actually be for.
The default should be one agent
Splitting work across agents adds a message boundary, and every boundary adds latency, cost, and a place for context to be lost. Reach for a second agent when there is a concrete reason a single one cannot do the job.
- genuinely different permissions — a research agent that must never be able to write
- genuinely different context — a codebase and a support inbox do not belong in one window
- genuine parallelism — five independent lookups with no dependency between them
- genuinely different models — something cheap for classification, something expensive for the hard step
"It feels more modular" is not on that list. Modularity expressed in prompt space costs considerably more than modularity expressed in code.
Orchestration patterns that hold up
- supervisor — one agent owns the plan and delegates. Easiest to reason about, single point of contention
- pipeline — fixed stages, each output feeding the next. Predictable, poor at branching
- blackboard — agents read and write shared state instead of messaging each other. Good for long-running work, harder to trace
The supervisor pattern is right far more often than its reputation suggests. Peer-to-peer negotiation between agents demos beautifully and becomes very difficult to debug when a chain of six delegations produces a wrong answer with no obvious owner.
Handoffs lose information
Passing a summary between agents is lossy compression performed under time pressure. The receiving agent gets a confident paragraph and no way to know what was dropped on the way.
# lossy: the summary is all the next agent will ever see
agent_a -> "customer is unhappy about delivery" -> agent_b
# recoverable: pass a reference alongside the summary
agent_a -> {summary, thread_id, order_id, confidence} -> agent_b
agent_b can fetch the original when the summary looks thin
Give the downstream agent a route back to the source. It costs one tool call and removes an entire class of confidently wrong answers.
Make the trace the primary artefact
With one agent you can read the transcript. With six you cannot, and the failure you are chasing is usually a handoff rather than a completion. Trace every delegation with its parent span, arguments, token counts and wall time, and make it searchable before production rather than during the first incident.
- record which agent decided what, not only what the system finally output
- attribute cost per agent — a single runaway loop can dominate the bill
- cap delegation depth and total calls; recursive delegation is a real failure mode
- decide what happens when a sub-agent fails, because the default is the supervisor inventing an answer
If you cannot answer "which agent decided this, and on what evidence" in under a minute, you have built a distributed system without the tooling that makes distributed systems survivable.
When to stop adding agents
A useful test before adding another one: write down what it can do that the current agent cannot, in a single sentence, without using the word "specialised". If that sentence is hard to write, the honest answer is usually a better tool rather than another agent.