The Circuit Breaker Pattern for AI Agents

Consider an illustrative incident, assembled from patterns that platform teams describe again and again. A billing agent is asked to correct a customer's tax code. It calls a lookup tool, which returns a timeout. The agent does what it was built to do: it keeps working toward the goal. It retries with a broader query. It receives a partial result. It decides the partial result means the field is missing across the account, and it begins writing a default value to every invoice it can find.

Four minutes later, twelve hundred records carry the wrong code, the session has consumed several hundred thousand tokens, and nobody was paged, because no single call failed. Every step returned success. The failure lived in the sequence, not in any one request. Traditional monitoring watches requests. Agent failures happen between them.

The lesson is not that the model was weak. A stronger model makes the same move faster and more convincingly. The lesson is that the system had no point at which ordinary code was allowed to say: stop. That is a Control problem, and it is the gap that Chapter 13 describes when it argues that governance built for humans does not cover software that acts on its own.

Michael Nygard popularised the circuit breaker in Release It! for a simple reason: when a downstream service is failing, hammering it with retries turns one outage into two. The breaker counts failures, trips open, fails fast for a cooldown period, and then lets a single trial request through to see whether the service has recovered. The pattern has protected distributed systems for nearly two decades.

Agents need it more, and need a different version of it. A conventional retry repeats the same request. An agent never repeats the same request. Given an error, it reasons about the error, and that reasoning produces a new plan: different arguments, a different tool, or a confident assumption that fills the gap. Each attempt is plausible on its own. Together they drift away from the original intent while appearing productive.

Three things compound at once. Error traces pile into the context window and crowd out the instructions that mattered, a decay that Chapter 36 treats as a budget problem. Token spend climbs with every reflective turn. And side effects accumulate, because a read that failed is often followed by a write that succeeds. Exponential backoff solves none of these. It only spaces them out.

A useful agent breaker does not wait for an exception. It watches behaviour and trips on patterns that predict harm. Four conditions cover most real incidents, and each can be measured without asking the model anything.

The first is velocity without progress: many tool calls in a short window while the task state does not change. A sensible starting threshold is something like four calls in ten seconds with no new fact recorded, tuned per workflow. The second is intent drift: the arguments and tools the agent is now using have moved outside the scope of the original request, measured by comparing the current action against an allowlist derived from the task, or by a similarity check against the opening instruction.

The third is sensitivity escalation: a write, delete, payment, or external message issued directly after a failed or empty read. This is the single most dangerous sequence in agent systems, because it means the agent is acting on information it does not have. The fourth is budget velocity: context or spend growing sharply across consecutive turns without an answer being produced, for example forty percent context growth in two turns. These figures are starting points, not benchmarks; the discipline is having thresholds at all.

Notice what these conditions share. They are deterministic. They are computed by plain code from logs the platform already has. Chapter 14 makes the case that agents need action control rather than access control alone; tripping conditions are action control expressed as numbers.

Closed is normal operation. The agent acts autonomously within its permissions, and every tool call is logged with its arguments, result, cost, and the task state before and after. Closed does not mean unwatched; it means the watching has not yet found a reason to intervene.

Open is the hard stop. When a condition trips, the breaker refuses further tool calls from that session, cancels pending actions, runs compensating steps for any reversible writes, and freezes the context exactly as it stood. The user receives an honest message rather than a fabricated answer. This connects directly to the guardrails and approvals in Chapter 15: an open breaker is an approval gate that closed itself automatically.

Half-open is where agents differ most from services. A service breaker lets one trial request through. An agent breaker should run in shadow mode: the agent proposes its next actions, but nothing executes until a person or a stricter policy confirms them. If the proposals look sound for a defined number of steps, the breaker closes. If not, it reopens. This is the human-in-the-loop principle of Chapter 17, applied only when the evidence says it is needed instead of on every call.

A breaker that trips without evidence produces an argument, not a fix. The moment it opens, the platform should write an incident freeze packet: the full system prompt and its version, the tool catalogue version, the user request, every tool call with arguments and responses, the token and cost curve, the condition that tripped and its measured value, and the list of side effects with their rollback status.

That packet makes the incident reproducible. An engineer can replay it against a fixed model version, find the turn where reasoning went wrong, and turn the case into a regression test. Over time, the packets become the most valuable evaluation set the team owns, because they are drawn from real failures rather than imagined ones. Chapter 16 argues that trust is designed, not assumed; the freeze packet is the design artifact that lets trust be rebuilt after it breaks.

Keep the packet scoped. It will contain customer data and prompts, so it belongs under the same retention and access rules as any other audit log, not in a public channel.

In a multi-agent system, a confused agent does not only damage its own task. It hands bad output to the next agent, which treats it as fact. A planner that drifted sends a researcher off course, and the researcher's findings mislead a writer. Chapter 34 explains why multi-agent systems fail at the seams; breakers belong at those seams.

Give every agent its own breaker, and give every handoff one too. When an upstream breaker opens, downstream agents should receive a typed failure signal, not a partial result dressed up as success. Shared resources, such as a database or an outbound email tool, deserve a global breaker that counts actions across all agents, because ten agents each acting slightly too often can produce the same damage as one agent acting far too often.

Finally, isolate budgets. A tripped agent should not be able to drain a shared token pool and starve healthy agents. Per-agent and per-task budgets, the approach set out in Chapter 20, turn a runaway loop into a contained, inexpensive event.

The breaker must sit outside the model. A system prompt that says stop if you are confused is a request, not a control; the model that is confused is the one deciding whether it is confused. Put the breaker in the tool-execution layer, the gateway every tool call passes through, where it can count, compare, and refuse with ordinary code.

This is the architecture of Chapter 30: a trusted agent is a probabilistic reasoner wrapped in deterministic boundaries. The model chooses. The boundary decides whether the choice is allowed to happen. Teams that separate those two responsibilities can adopt stronger models with less fear, because their safety does not depend on any one model behaving well.

Start in observe mode. Compute the four conditions on existing logs for two weeks without tripping anything, and look at which sessions would have tripped. Most teams find a small number of sessions responsible for a large share of cost and incidents, which makes the case for the breaker better than any argument.

Then enable the hard stop for the riskiest actions first: deletes, payments, external messages, and bulk writes. Leave read-only tools in observe mode longer. Review every trip in a weekly meeting, adjust thresholds, and add each freeze packet to the evaluation set. The goal is a breaker that trips rarely and is right when it does.

Measure two numbers: the trip rate, and the share of trips that a reviewer agrees were justified. A high trip rate with low agreement means thresholds are too tight. A low trip rate combined with incidents found later means they are too loose. Both numbers belong on the same review page as quality and cost, because Control is a peer of the other three C's described in Chapter 4, not an afterthought to them.