The worst microservices system I ever saw was one program cut into twenty, where every service still had to be deployed with all the others, in the right order, or nothing worked at all. I have written before about that trap, the distributed monolith: you paid the full price of a distributed system and got none of the independence you split it up to buy. I am watching the same mistake queue up again, one field over, every time a team splits a working single agent into a fleet of them because a diagram with more boxes feels more serious. The boxes are not free. Each one is a node in a distributed system now, and distributed systems keep their own counsel.
A multi-agent system is a distributed system with language models for nodes, which means the day you split one agent into many, you stop debugging a loop and start operating a network, with every failure mode the word network has always carried.
- Where a single loop ends and a network begins, and the exact line that separates a pattern from a fleet.
- Four ways to draw the org chart for machines, and what each topology buys you and costs you.
- The fallacies of distributed computing, back for a second helping, and why you earn the second agent the way you earned the second service.
The loop dive ended its autonomy dial at a level it called the fleet: many agents coordinating, with message-passing and failure isolation, and it named that a different discipline and a dive of its own. This is that dive. It assumes the loop entirely, spends no words re-deriving it, and owns only the plural.
One Loop, or a Network of Them
A single agent is one think-act-observe loop: one brain, one context, one place where the state lives. The moment there are two agents that must coordinate, you no longer have a bigger loop. You have a network, and the difference is not cosmetic. It is the same difference between a method call and a remote call, and it changes everything about how failure, latency, and truth behave.
This is exactly where the patterns dive drew its line, and it is worth holding from this side too. Orchestrator-worker, reflection, planning, routing: those are patterns, moves inside a single control loop where the workers are sub-calls under one brain. A topology begins only when the workers are independent, long-lived, separately deployed agents that own their own state and can fail on their own. Patterns are that dive. Topologies are this one. Keep the line bright, because most of the trouble in this field comes from calling a pattern a system and inheriting a network you did not mean to build.
Four Ways to Draw the Org Chart
A topology is an org chart for machines: who reports to whom, who may talk to whom, where a decision is made. Four shapes cover most of what gets built, and each is a genuine trade.
The frameworks you have heard of each pick a default shape, and it is worth naming them only as examples: supervisor graphs, role-based crews, group-chat rooms, explicit handoffs between peers. The Route's own counsel holds here as everywhere: the loop matters more than the library, and the topology matters more than the framework that renders it. Choose the org chart on purpose, not because a tool made one shape the path of least resistance.
The Fallacies Come Back
A generation of engineers learned the fallacies of distributed computing the hard way: the assumptions that feel safe on one machine and turn lethal across many. Split one agent into a fleet and every one of them comes straight back, wearing new clothes. They are not a metaphor for the agent problem. They are the agent problem.
Nothing Fails Alone
The last row is the one the agent era adds to the classic list, and it is the dangerous one. A crashed node is honest. A sub-agent that confidently returns a wrong answer keeps the whole fleet moving in the wrong direction, and nobody gets paged, because from the outside everything is still responding. I have argued elsewhere that in a connected system nothing fails alone, and a fleet of agents is nothing if not connected. So the disciplines are the ones you already run on distributed systems: timeouts so a stalled agent cannot freeze its caller, circuit breakers so a failing one is cut out rather than retried into a storm, and the standing assumption that a peer agent's output is a claim to be checked, not truth to be absorbed. How those messages actually travel on the wire is its own dive: the topology decides who talks to whom, and the protocol decides how. This dive is the who.
Earn the Second Agent
Which lands where the microservices decision always lands. You add the second service from strength, never from fashion, and only once a real seam in the domain forces the split; add it any earlier and you have bought every distributed-systems problem in exchange for a diagram that looks busier. Agents inherit the law unchanged. One agent with good tools and a clear loop beats a fleet that usually coordinates, and the honest first question when someone proposes a multi-agent architecture is not which topology. It is whether the second agent has been earned at all. A fleet you did not earn is just a distributed monolith with a language model in every box, and now it hallucinates too.
The topology chose who talks to whom. The wire is how they actually talk. One Contract, Every Agent opens the protocol agents from different builders use to collaborate. Or step back onto the Route at Stage 04.