At the beginning of my career as a developer in the 2000s, software shipped as a single application, deployed as one piece, failing as one piece. When the cloud arrived I did what nearly everyone did – I lifted a monolith into it, and then, along with the rest of the industry, I broke it apart into microservices. The decomposition taught a lesson no book had managed to: once an application becomes many small parts talking over a network, the hard problems stop living inside the parts and start living between them. Two decades later, watching teams chain agents together, I keep seeing that same moment arrive. A chain of agents is not a collection of individual agents. It is a complete system built from small services that happen to reason, and it has to be engineered like one. An agent is not a clever prompt. It is a distributed system.
Most agent development still treats the model as the system. The prompt is tuned, the tools are wired in, the demo runs clean, and the thing is declared built. That framing survives exactly as long as one agent runs one task once. Put several agents in a workflow at real volume and the behavior stops resembling a language problem and starts resembling every hard problem in distributed computing: state that goes stale, calls that fail halfway, work that duplicates, steps that arrive out of order. The model is one component. The system is everything else.
The Failures Are Systems Failures
The evidence is now empirical rather than anecdotal. In a study presented at NeurIPS 2025, researchers traced a large set of failed multi-agent executions and found the breakdowns clustered not in the models’ reasoning but in the system around it (Cemri et al., 2025). The largest share arose from specification and design, the next from coordination between agents, and the rest from inadequate verification of the work produced. Agents did not fail because they were not intelligent enough; they failed because the system was never engineered as a system.
Three problems account for most of the breakage, and anyone who lived through the microservices years would recognize all three on sight.
- State and consistency – An agent’s state is scattered across context windows, memory stores, and shared scratchpads. When two agents read that shared state at different moments, one acts on information the other has already made obsolete (Redis, 2026). Stale reads are among the oldest problems in concurrent systems.
- Partial failure – In any system of many parts, some parts fail while others keep running. An agent whose tool call times out, repeats a step that had already succeeded, and books the same order twice has not hallucinated; it has hit the failure behavior distributed systems spent decades taming. The old rules of unreliable networks did not stop applying because the caller is a model.
- Coordination – Handing work across agents introduces ordering, delegation, and consensus, and coordination is never free. Controlled studies of agent scaling show that adding agents adds overhead and amplifies errors unless the topology is designed to contain it (Google DeepMind, 2025). More agents is not more capability. Past a point, it is more ways to disagree.
The Industry Has Seen This Problem Before
That precedent deserves more than a mention, because the industry did not simply adopt microservices; it survived them. Breaking large applications into small services over a network rediscovered every hard problem the single deployment had been hiding: unreliable calls, inconsistent state, cascading failures, outages no single team could explain (Rotem-Gal-Oz, 2006). The response was not better services. It was better engineering around the services: circuit breakers, safeguards that make repeated actions harmless, compensating transactions, and tracing (Fowler & Lewis, 2014). A multi-agent workflow is the same decomposition with one difference that changes everything: the endpoints are no longer deterministic. An agent is a microservice that improvises.
A Walkthrough: One Invoice, Four Failures
The abstraction becomes concrete in a workflow any enterprise could deploy this quarter. An accounts-payable system runs three agents: an intake agent that parses invoices and writes vendor details to shared memory, a validation agent that checks each invoice against policy, and a payment agent that executes the transfer through a banking API.
The first failure arrives before any agent has done anything wrong. The intake agent writes the vendor’s bank details, then receives a corrected invoice and updates the record. The validation agent, which began its check between the write and the update, approves the payment against the original details. Nothing hallucinated; the system permitted a stale read, and each agent behaved correctly on the state it saw.
The second failure is a partial one. The payment agent calls the banking API, the call times out after the transfer has already posted, and the agent does what any reasonable planner does with an apparent failure: it retries. The vendor is paid twice. What was missing was an idempotency key – the simple safeguard that makes a repeated request harmless – because a timeout does not mean the action failed; it means the caller does not know.
The third failure is coordination. The orchestrator, having received no confirmation, re-dispatches the task to the validation agent, which dutifully re-approves an invoice it had already approved and reports success. The workflow now shows a completed validation and no completed payment, the mismatch between reasoning and action the failure research documents as one of the most common coordination breakdowns (Cemri et al., 2025). Work was repeated; the work that mattered was not.
The fourth failure is that nobody inside the system notices the first three. No trace spans the workflow, so the duplicate payment surfaces the way failures surface in unobservable systems: the vendor calls. Four failures, not one of them a model failure, each with a decades-old remedy: versioned state, operations safe to repeat, compensating steps that undo half-finished work, and tracing that follows a task end to end. The fixes were never AI research problems. They were sitting in the microservices playbook the whole time.
Build the System, Not the Agent
Distributed systems were hard even when every node behaved deterministically; agents place a probabilistic component at every node. The network was already unreliable. Now the endpoints improvise. Charles Perrow argued in 1984 that tightly coupled, complex systems produce failures as a structural property rather than a series of correctable mistakes (Perrow, 1984), and a workflow of agents calling tools and each other is exactly such a system.
Building a dependable agent therefore looks less like refining a prompt and more like engineering a system to survive its own components: tools defined as strict contracts that state what they accept, what they return, and how they fail; actions safe to repeat and retries that know when to stop; durable state, so a failure mid-workflow resumes rather than restarts; verification gates that treat an agent’s output as untrusted until checked; and tracing that follows a task across every agent it touches. Reliability does not live in the model. It lives in everything wrapped around it.
The agent will keep getting the attention, because the agent is the part that demos. The system is the part that ships. The teams that put dependable agents into production will be the ones who stopped treating an agent as a model with tools attached and started treating it as what it already is. Build the system, and the agent becomes reliable. Build only the agent, and the system fails around it.
References
Cemri, M., Pan, M. Z., Yang, S., et al. (2025). Why do multi-agent LLM systems fail? Advances in Neural Information Processing Systems (NeurIPS 2025).
Fowler, M., & Lewis, J. (2014). Microservices: A definition of this new architectural term. martinfowler.com.
Google DeepMind. (2025). Towards a science of scaling agent systems. arXiv.
Perrow, C. (1984). Normal accidents: Living with high-risk technologies. Princeton University Press.
Redis. (2026). Why multi-agent LLM systems fail and how to fix them.
Rotem-Gal-Oz, A. (2006). Fallacies of distributed computing explained.
