The One-to-Five Trap: Why Multi-Agent Systems Become Distributed Systems

For: enterprise architects and AI engineering leaders. The decision: when a second, third or fifth agent is worth what it costs.

Five agents with one credential are one component in five costumes

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

Consider a finance team automating its month-end close across 14 legal entities. The design review shows five agents: reconciliation, variance analysis, commentary, journal preparation and a reviewer. The slide looks like an organisation chart, and it reads well to a CFO.

Look underneath and the picture changes. All five call the same model. All five run under one service account with write access to the general ledger. All five belong to the finance systems team and ship on the same release. The only thing that separates them is the prompt, and the four handoffs between them.

I call this the one-to-five trap, as a label for this series rather than a named part of the book’s framework. A team starts with one working agent, splits it into roles because roles are easy to explain, and ends up operating a distributed system without having designed one.

Adding an agent is not like adding a colleague

The intuition behind the split is human. A close process has a reconciler, an analyst and a reviewer, so the software should too. More roles, the thinking goes, means more capability and more checking.

Software agents do not work that way. A new colleague brings their own judgement, their own accountability and their own access, which is exactly what makes separation of duties meaningful. An agent that shares its neighbour’s model, context and credential brings none of those. What it brings is a handoff, and a handoff has a price.

Take one handoff from the close: variance analysis passing its findings to commentary. Before that handoff can run at month end, someone has to settle what is passed across (the variance table with its source references, or a paragraph about it), what happens when the same findings arrive twice after a retry, how long the close waits if commentary is slow, and which identity the commentary agent presents when it asks for more data. Someone also has to decide how a controller traces a sentence in the commentary back to a ledger balance, and how the handoff itself is tested each time a prompt or model changes. Multiply that by four handoffs.

Frameworks make this worse by making it cheap. Declaring a sixth agent now takes a few lines, so the cost of a boundary is paid later, in operations, rather than at design time. Anthropic’s engineering guidance makes a similar point from the builder’s side: start with the simplest composition that works and add agentic structure only when it demonstrably helps (Anthropic, 2024).

The research on failure points the same way. Cemri and colleagues built a taxonomy of how multi-agent LLM systems fail, drawing on more than 1,600 annotated traces across seven frameworks. Their 14 failure modes fall into three groups: system design issues, inter-agent misalignment and task verification (Cemri et al., 2025). Their analysis suggests that many failures arise from how the system is designed and how agents coordinate, not only from the capability of the underlying model. A stronger model is unlikely, on its own, to repair a handoff that drops the evidence.

None of this is new. Reid Smith’s Contract Net Protocol described in 1980 how distributed nodes could announce tasks, bid for them and have work awarded (Smith, 1980). Distributed AI spent decades on allocation, partial knowledge and failure. Language models make coordination more flexible. They do not make it free.

In CAE, a boundary must buy a property the enterprise needs

The Contextual Agentic Enterprise (CAE) is my proposed architecture and operating model for letting people, models, agents and systems act together on enterprise context, under delegated authority, with evidence. In CAE an agent boundary is an architectural decision like any other, and it has to be justified before it is built.

The book frames the decision as a boundary test, and I will put it in words rather than as a formula. A split between two agents earns its place only when it gives you something real in at least one of five areas: tighter privilege, cleaner context, separate ownership, independent scaling, or contained failure, and when that gain outweighs the price of its handoffs. The book is explicit that this is a way of making the trade-off visible, not a number to calculate.

Apply it to the first boundary in the close. The reconciliation agent and the variance agent run on the same model with near-identical prompts. They read the same trial balances, hold the same read-only rights, are owned by the same team and go live on the same release. Their handoff exists because the slide needed two boxes, and in every sense that matters they are two steps of one component.

John Ousterhout’s language fits: a good module hides complexity behind a narrow interface (Ousterhout, 2021). Splitting reconciliation from variance analysis adds an interface and hides nothing, so it moves complexity rather than reducing it. I made the same argument for generated code in When Code Becomes Cheap, Design Becomes Critical.

Every proposed boundary should pass a written test

Before any second agent is approved, put each proposed boundary through these seven steps, in writing.

1. Privilege. Would the two sides hold different permissions? If both need the same credential, the boundary protects nothing.
2. Context. Should one side be prevented from seeing what the other sees, for confidentiality or for quality? If both need the same inputs, no.
3. Ownership. Would different teams own, version and release the two sides behind a stable contract?
4. Scale. Does one side need to run in parallel, on a different model, or at a different cost profile?
5. Failure isolation. Can one side fail, retry or be switched off without corrupting the other?
6. Cost. Write down what running this handoff would take at month end, as in the commentary handoff described earlier. If the answers to 1–5 are “no”, everything on that page is pure cost.
7. Replace and compare. Replace the proposed agent with a function. If nothing you care about is lost, keep the function.

Coordination failures look like distributed-systems failures

Suppose reconciliation times out on two of the 14 entities and is retried after variance analysis has already run on the other twelve. That is an old problem, partial state, made harder by participants that may not give the same answer twice when rerun. What protects the close is unglamorous: agreed handoff formats, one record of which version of the balances each step used, and traces a controller can follow from a commentary sentence back to the ledger. The trap produces a recognisable set of symptoms.

• Partial state. After that retry, nobody can say which version of the balances the commentary describes.
• Context loss at handoffs. Each agent passes a summary, not the evidence. By the third hop, an unmatched intercompany balance has become “minor timing differences”.
• Correlated agreement. Checkers that share a model and context share failure modes, so apparent consensus carries no information.
• Central accumulation. A supervisor gathers every tool and every decision, becoming the monolith the split was meant to avoid.
• Authority drift. Because all five hold the same ledger credential, the commentary agent can post a journal. Nothing in the design says it should.

What the test does not solve is the last item in full. It tells you where boundaries should sit. It does not tell you what authority may cross one when an agent hands work to another. That needs its own treatment.

Each role has a different decision to make

Executives decide that agent count is not a measure of progress. Ask each programme to justify every agent boundary against the five properties, and fund the ones that pass.

Architects design topologies where each edge is labelled with what it carries: information, task ownership, authority, or all three. Separate identities where privilege genuinely differs. Keep the path to commitment deterministic, and make review independent in evidence and method, not just in name.

Engineers implement and test handoffs as typed contracts that carry evidence references rather than prose summaries. Give every command an idempotency key tied to the business operation. Calculate the maximum fan-out of one root task. Then run the replacement exercise: swap each agent for a function in a test harness and measure what quality you lose.

The month-end close collapses to two agents and a control

Apply the procedure to the close and most boundaries dissolve.

The result is two agents and a control. One read-only analysis agent reconciles, explains variances and drafts commentary. One journal agent proposes entries under its own identity and cannot post them. Posting passes through deterministic validation (entries balance, accounts are open, amounts sit within a materiality threshold) and a human controller approves anything above it. The boundary where a proposal becomes a ledger entry is what CAE calls the Commit Boundary: the point where a recommendation would turn into an externally observable effect. That is where the design spends its control, which is the core idea of the Deterministic Shell.

The reviewer agent deserved special scrutiny. It used the same model, read the same context and received the journal agent’s own justification. That is not independent review. It is the same judgement asked twice, and it will tend to agree with itself.

Key takeaways

• Splitting the close into five agents created partial state, handoff loss and tracing problems that distributed systems have always had, with participants that may answer differently when rerun.
• An agent boundary earns its place only by improving privilege, context, ownership, scale or failure isolation by more than its coordination cost.
• Reconciliation and variance analysis, with the same model, balances, rights, owner and release, were one component drawn as two boxes.
• Independent review requires different evidence, methods or accountability; a second prompt on the same model is not a checker.
• The research on multi-agent failure finds many problems in system design, coordination between agents and verification, not only in model capability.

Sources and further reading

• The Contextual Agentic Enterprise, Chapters 9 and 10.
• Cemri, M., Pan, M. Z., Yang, S. et al. (2025) “Why Do Multi-Agent LLM Systems Fail?”, arXiv:2503.13657. https://arxiv.org/abs/2503.13657
• Smith, R. G. (1980) “The Contract Net Protocol”, IEEE Transactions on Computers C-29(12). https://doi.org/10.1109/TC.1980.1675516
• Ousterhout, J. (2021) A Philosophy of Software Design, 2nd edn, Yaknyam Press.
• Anthropic (2024) “Building Effective AI Agents”. https://www.anthropic.com/engineering/building-effective-agents

Where the book goes further

The book works through the main coordination topologies and when each earns its cost, how each tends to fail, and what an enterprise orchestration layer should own regardless of framework. Next week’s Field Note takes the question this one leaves open: what happens to authority when one agent delegates to another.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.