Your Multi-Agent System Has No Brakes

You designed which agents exist and how they connect. You did not design the thing that decides when they stop. In most systems, nothing does.

You can draw your multi-agent system on a whiteboard. Boxes for the agents, arrows for who calls whom. That drawing is the architecture, and it is static. The system that runs in production is not static. It is a loop, and that loop has to decide, over and over, what runs next and whether to stop. In most multi-agent systems, no single component owns that decision. Control is emergent: it falls out of agents choosing to call each other. And emergent control has no brakes.

A single model call stops by construction. You send tokens, it returns tokens, it is done. The moment you wrap that call in a loop that can invoke other agents, you give up that guarantee. The system now terminates only if something makes it terminate. If you did not build that something, your system's real stopping condition is whichever runs out first: the model's willingness to keep going, your token budget, or your patience at 3am watching a run that will not end.

TL;DR

In a multi-agent system, no single component owns the decision of what runs next and when to stop, so control is emergent, and emergent control does not reliably halt. It breaks four ways: non-termination (agents loop or ping-pong forever), premature termination (the system trusts an agent that said "done" when it only meant "I stopped"), mis-routing (a dynamic router sends the task in circles), and no global budget (the median run is fine while the tail run costs 20 to 50 times more). The repair is not a smarter agent or a better prompt. It is explicit control: a termination predicate the system checks instead of the agent's self-report, a hard global budget on steps and tokens and time, one controller that owns routing, and loop detection that reads the shared store. Architecture is the engine. Control is the brakes. Most teams ship the engine and forget the brakes.

Architecture is a diagram. Control is what happens at runtime.

The previous chapter on how to wire a multi-agent system was about shape: which agents exist, and which one is allowed to talk to which. Shape is necessary, and shape is not control. A supervisor-and-workers diagram tells you the supervisor can route to any worker. It does not tell you when the supervisor should stop routing, how it decides who is next, or what happens when a worker hands the task straight back. Those are runtime questions, and runtime is where the system actually lives or dies.

Think of it as the difference between a wiring diagram and a driver. The diagram is fixed the moment you draw it. The driver makes thousands of decisions while moving: accelerate, turn, and above all, brake. Nobody would ship a car as a wiring diagram and hope the braking emerges from the parts. Multi-agent systems get shipped exactly that way, and then the team is surprised when the thing accelerates into a wall.

The four ways control fails

Every runaway multi-agent system I have taken apart failed through one of four control gaps. None of them are exotic. They are the default behavior of a loop that nobody is steering.

Non-termination. Two agents ping-pong. A writer produces a draft, a reviewer asks for a change, the writer changes it, the reviewer finds something new to change, and the pair orbit each other until something external kills the run. It is not always two agents; a single agent stuck calling a tool that keeps returning "not quite, try again" loops just as hard. The reason frameworks ship a default recursion limit at all (LangGraph, for example, stops a graph at 25 steps unless you raise it) is that this happens constantly. Hitting that limit is a symptom that your system had no real stopping condition, not proof that it has one.

Premature termination. The mirror image, and it inherits the semantic drift from the last chapter on hand-offs. An agent emits "done" or "final answer," the orchestrator halts, and the goal was never actually met. "Done" meant "I ran out of ideas," or "I hit my own limit," not "the task is complete and correct." A system with no explicit goal check is trusting a self-report, and a self-report is the one signal an agent has every incentive to produce whether or not it earned it.

Mis-routing. A dynamic router, the supervisor that reads the state and picks the next agent, is a classifier, and classifiers are wrong some fraction of the time. Send the task to the wrong specialist and it comes back unfinished, gets routed again, and orbits without converging. The error compounds per hop. If a router is right 90 percent of the time on a single decision, a task that needs four correct routing hops lands cleanly only 0.9 to the fourth, about 66 percent of runs. At five hops it is 59 percent. Every added hop multiplies the chance the task never reaches the agent that could have finished it.

No global budget. Each agent step is locally cheap and locally reasonable. The failure is that there is no system-level ceiling on steps, tokens, tool calls, wall-clock, or dollars. The median run is fine. The tail run, the one in 50 that catches a loop, is what pays you back with a latency-SLA breach and a line on the invoice you cannot explain. You budgeted for the median and the tail is what ships to production alongside it.

Do the math on the tail

Put numbers on the last one, because the tail is where the money is and the average hides it. Say a healthy run is 6 agent steps at roughly 1,500 tokens each, about 9,000 tokens. A run that catches a review-loop and rides the 25-step limit is about 37,000 tokens, roughly 4 times the healthy cost, and it produced a worse answer than it had at step 6. Suppose only 2 percent of runs do this. The effect on your average bill is small, about 6 percent, which is exactly why it hides. But your p99 is now 4 times your median. The tail does not move the average enough to notice on a dashboard, and it moves the worst-case enough to wake you up.

The clean way to see why a budget is not optional: with a hard cap of N steps at per-step cost c, the worst a run can cost you is N times c. Remove the cap and the worst case is unbounded, because the loop has no reason of its own to end. A step ceiling is not a tuning knob. It is the single thing that turns "unbounded" into a number you can put on a slide.

The fix is explicit control, not a smarter agent

You cannot prompt your way out of this. "Please stop when you are done" is not a control system; it is a wish addressed to the same agent whose judgment about "done" you already could not trust. Control has to live outside the agents, in a component that owns it. Four mechanisms, in rough order of how much they save you.

A termination predicate the system checks. Replace "the agent said done" with a goal check the controller evaluates against state: are the required fields present in the shared store, validated, and above the confidence threshold you set? A predicate is a fact the system can verify. A self-report is a vibe the agent can fake. The predicate reads the shared store rather than asking the agent, which is the whole reason the store from the last chapter exists.

A hard global budget. Cap steps, tokens, tool calls, wall-clock, and dollars, at the system level, not per agent. When any ceiling trips, stop and escalate; do not silently keep going. This is the circuit breaker that bounds worst-case cost from unbounded to N times c, and it is the difference between a bad run that costs 4 times the median and a bad run that costs 50 times the median because nothing was counting.

One controller owns routing. Give a single supervisor an explicit policy or state machine for who runs next, instead of letting agents freelance calls to each other. And prefer the least dynamic control that still does the job. If the flow is known, a static directed graph is the most reliable thing you can ship, because it cannot route in a circle. If it branches, a bounded state machine. Reserve free-form, agent-decides-the-next-agent control for the genuinely open-ended tasks that need it, and even then, run it inside the budget above.

Loop and progress detection. Hash the shared state; if the same state appears twice, you are in a cycle, so break out and escalate rather than paying to discover it again. Track whether any new information was written across the last K steps; if nothing changed, the system is stuck even though it is still busy. This is what converts an infinite loop from a runaway bill into a caught, logged, recoverable event.

Control needs the shared store from the last chapter

None of this works without somewhere to look. The termination predicate and the loop detector both read the shared, typed store that fixed the communication problem in chapter 3. That is the pattern worth holding onto across both chapters: state and control are two halves of the same machine. Shared state without a controller loops forever, because nothing decides to stop. A controller without shared state is blind, because it has nothing trustworthy to check its termination predicate against. You need both, and they are cheaper to build together than to bolt on separately.

There is a debugging payoff too. A run that never terminates is a run you cannot evaluate, which is why the question of which agent broke starts with being able to end a run and read its trajectory. Loop detection and a recorded store give you exactly that trajectory. The same machinery that stops the system is the machinery that lets you explain what it did.

A single model call terminates because it was built to. A multi-agent system terminates because you built it to. If you did not, it does not.

When you do not need any of this

The honest caveat: the reason a single agent so often feels more reliable is not that it is smarter. It is that a single model call has a trivial, guaranteed control loop, it returns once, and that is a feature you give up the moment you add a second agent. This is the same argument as the case for keeping it to one agent. If your task fits one agent, the cheapest control system is no control system, and you should take it. Add agents only when the task genuinely needs them, and when you do, treat control as a first-class part of the build with its own budget and its own tests, not as something you will add after the demo works. The demo always works. The demo is a single happy path with no loops in it.

We build production multi-agent systems for document-heavy work in legal, finance, and insurance, where a run that loops for an hour or halts on a stale guess is not a curiosity, it is a bill and a liability. If your agents are wired but you are not sure what actually stops them, the missing piece is almost always control, not intelligence. Talk to an engineer or see how we work.