Agent networks fail in the handoff, not in the model

There is a reliable sequence in multi-agent projects. The prototype works. A researcher orchestrates four agents, they hand work between one another, and the demo is genuinely impressive. It goes to production and the failure rate is somewhere north of forty percent. The team responds by upgrading the models.

It does not help, and the reason it does not help is now reasonably well documented. Studies of production multi-agent LLM deployments put failure rates across a wide band— roughly forty to eighty-five percent depending on task and architecture— and attribute close to eighty percent of those failures to coordination and specification problems rather than to model capability. The models are mostly doing what they were asked. The asking is the problem.

Two protocols, two trust boundaries, usually one security model

The stack that has emerged distinguishes two kinds of connection. Agent-to-tool, where an agent invokes a capability— the space the Model Context Protocol occupies. And agent-to-agent, where an agent delegates a task to another agent, which is what Agent-to-Agent style protocols address. Most serious deployments now use both.

They are not the same kind of relationship, and treating them as one is where a good deal of trouble originates. When an agent calls a tool, it is issuing an instruction to something that will do exactly what it is told, and the risk is that the instruction is wrong. When an agent delegates to another agent, it is handing an objective to something that will interpret it, and the risk is that the interpretation diverges. The first is an API call. The second is closer to giving instructions to a colleague who will not ask clarifying questions and cannot tell you they were confused.

The practical consequence shows up in permissions. A specialist agent invoked over A2A typically executes with its own tool credentials, not the caller’s. So authority accumulates along the chain: an agent with deliberately narrow permissions delegates to one with broader permissions, and the effective privilege of the request is the union of everything in the path. Very few teams can produce, on request, the effective permission set of a multi-agent workflow. Fewer still have a mechanism that would stop it growing.

Semantic intent divergence

The most distinctive failure mode in agent networks has no analogue in conventional distributed systems, and it is worth naming precisely because it is so easy to miss in testing.

Each agent reasons inside its own context window, with its own system prompt and its own retrieved material. Given a shared objective expressed in natural language, each constructs a slightly different understanding of it. Not a wrong understanding— a different one. An orchestrator asks a research agent to “check the customer’s recent activity” and it examines ninety days. It passes results to a risk agent for which “recent” means since the last review. Neither is incorrect. Together they produce a conclusion supported by no coherent reading of the data, delivered with complete confidence and a clean execution trace.

This is what makes these systems difficult to test. There is no error. Every component behaved reasonably given its interpretation. The failure lives in the space between interpretations, which is exactly the space that unit tests, and most integration tests, do not cover.

Reliability does not add. It multiplies.

The arithmetic here is unforgiving and routinely ignored at design time.

Suppose each agent completes its step correctly ninety-five percent of the time— a figure most teams would consider strong. A six-step chain, if the steps were independent, succeeds about seventy-four percent of the time. Ten steps gets you to sixty. Nobody designed for a forty percent failure rate; it emerged from composing components that each looked acceptable in isolation.

And the steps are not independent, which makes it worse rather than better. Errors propagate as context: a mistake in step two does not merely fail, it becomes an input that later agents reason over faithfully. The system does not degrade gracefully toward a wrong answer— it builds an increasingly confident case for one, because each subsequent agent is doing competent work on corrupted premises.

How do you test for a disagreement?

The hardest question in this area is what a test suite even looks like when the failure is interpretive. Conventional testing asserts that a component returns an expected value for a given input. Semantic divergence produces no wrong values— every agent returns something defensible— so assertions at the component level pass while the composed system is wrong.

Three things work in practice. The first is asserting invariants on the composed output rather than on individual steps. You may not be able to specify the correct answer, but you can almost always specify properties that must hold regardless: the total refunded never exceeds the transaction, the risk score references only accounts belonging to the customer, the time window used by every agent in the chain is identical. Those are checkable by ordinary code, they run in production as well as in test, and they catch divergence precisely because divergence violates consistency rather than correctness.

The second is adversarial ambiguity. Deliberately hand the network objectives containing terms that admit more than one reading— the underspecified requests real users send constantly— and inspect what each agent concluded. If two agents in the chain resolved “last quarter” differently, you have found a class of defect, not an instance, and the fix is a shared definition rather than a prompt edit.

The third is replaying production traces against a modified network. When you change one agent’s prompt, the question that matters is not whether that agent still passes its own tests but whether the handoffs downstream still receive what they expect. Without trace replay, every prompt edit is an untested change to a distributed system— which is what most of them currently are.

What actually helps

The remedies are unglamorous, and almost all of them amount to restoring contracts that were removed when prose replaced interfaces.

Make the interface between agents typed and validated, not conversational. If a research agent hands a risk agent a set of transactions, that payload should have a schema, a version, and explicit units and time bounds— and it should be validated at the boundary by ordinary code, not by a model reading it sympathetically. Natural language is an excellent interface between a human and a system. It is a poor interface between two components that must agree precisely.

Make shared vocabulary data rather than prose. If “recent”, “active customer” and “material exposure” matter to more than one agent, they belong in a definition every agent resolves against, not in each agent’s prompt where they will drift independently as prompts are edited.

Bound the authority of each hop explicitly. Delegation should narrow permissions, never widen them. If a downstream agent needs authority the caller does not have, that is a design decision requiring a human, not a default that emerges from how credentials happen to be provisioned.

And apply the distributed systems playbook, because that is what this is. Idempotency, so retries do not double-charge. Timeouts with defined fallback behaviour rather than indefinite waits. Compensating actions for partially completed workflows. Circuit breakers when a downstream agent degrades. These problems were solved over decades of building systems where unreliable components had to produce reliable outcomes. Nothing about a language model at the node repeals any of it.

Fewer agents than the diagram suggests

A last observation, offered from having reviewed a number of these architectures. The number of agents in a design is frequently a reflection of how the building team is organised rather than of what the problem requires. Conway’s law arrives in agent architecture on schedule.

Every additional agent adds a handoff, and handoffs are where these systems fail. A single agent with five well-specified tools is usually more reliable, cheaper, and dramatically easier to debug than five agents delegating among themselves, and it fails in ways that show up in a trace. Multi-agent architecture earns its cost when components genuinely need separate context, separate permissions, or separate lifecycles— not because the diagram looks more sophisticated with more boxes in it.

Before adding an agent, the question worth answering is what contract it will honour, what happens when it misinterprets its objective, and how anyone would find out. If those answers are not available, the additional agent is not adding capability. It is adding a seam.