Boring patterns that keep multi-agent systems up

Multi-agent systems break in boring ways. The interesting ways have been written about — coordination failures, deadlocks, infinite loops between agents asking each other for clarification. Those are real, and the literature handles them. The boring ways are what kills cutover, and they are five.

Pattern one — scoped context

An agent that can see everything will use everything. An agent that can see only what it needs will do better work, faster, with smaller failure modes.

Each agent should be given a scoped view of the system's data. Take a credit-intake design as the worked shape: the intake agent sees the application form and nothing else; the bureau agent sees the bureau interface and the identity fields it needs, nothing else; the synthesis agent sees the upstream agents' outputs and nothing else. None of them sees the full customer record.

The discipline is uncomfortable when you start. Every new agent feels like it would be more useful with more context. Resist it. The cost of debugging an agent that did the wrong thing because of context bleed is higher than the cost of building a slightly smaller agent.

Pattern two — explicit handoffs

When one specialist's work feeds another, the internal handoff is a typed event, not a shared variable. A typed handoff has a contract. A shared variable does not. A2A is reserved for interoperability with an independently operated agent system at the deployment boundary.

The typed contract means the failure mode is “the message did not arrive” or “the message did not validate”, both of which are observable. The shared-variable equivalent is “the variable was the wrong type” or “the variable was overwritten between read and use”, both of which are silent.

Shared variables tend to appear in the second or third agent of a prototype, written quickly to get something running. Converting one to a typed handoff is a reliable way to surface a class of bug that was previously invisible: the type boundary forces the question of what the message actually contains.

Pattern three — failure budgets

Each agent has a failure budget. When the budget is exhausted, the agent stops, and the orchestration layer routes around it. The budget is per-deployment, per-agent, per-window.

The budgets are small — a fraction of a percent of calls within a short window. The budget is set so that it is rarely consumed by genuine background error and consumed quickly when something is wrong; the exact figure belongs to the deployment and its tolerance, not to a general rule. When an agent exhausts its budget, the orchestration layer pauses it, alerts the on-call engineer, and either falls back to a less-capable backup or routes to human review. We do not auto-restart.

The budget exists because agents are systems with non-deterministic behavior, and the question “is this agent broken right now” is not always answerable. The budget makes the question concrete: if it is over budget, the answer is yes.

Pattern four — observability

Every agent emits a structured event for every call: input, output, latency, model used, tokens, the agent's own confidence in the output. The events go to the same observability stack that the customer's other systems use, not to a parallel one.

The discipline is to make agents look like services, not like AI magic. A service has logs, traces, and metrics. So does an agent. When an agent is misbehaving, the path to diagnosing it is the same path the on-call engineer would take for any service: read the trace, look at the inputs, check the metric.

The tendency worth fighting is logging the model's intermediate reasoning. It is verbose, expensive to store, and rarely informative. The final input and output, the latency, and the confidence are enough.

Pattern five — a shutdown switch

A system needs a single switch that turns the agents off and routes traffic to an existing fallback. Sometimes the fallback is the workflow that ran before the system arrived; sometimes it is human review. There is no version of this where the fallback is optional.

The switch is wired before any of the agents are wired, and a system whose shutdown switch has not been tested is not ready to cut over. The test belongs in the runbook tabletop exercise.

The honest answer to “will the switch ever be used” is that the likeliest reasons are upstream — a connector outage, a warehouse migration — rather than the agents misbehaving. That is what the design should optimize for: when something upstream breaks, operations continue on the fallback while it is resolved.

What the patterns are not

The five patterns are how a multi-agent system is kept from collapsing into itself. They are not how agents are made smarter, faster, or more capable. Those are different problems with different literature. The patterns above are the boring half. The boring half is what makes the interesting half ship.

The next dispatch is on retrieval versus fine-tuning, framed as four questions about your data — not your model.