Glossary
Circuit breaker (AI agents)
A circuit breaker in an AI agent system is a control that stops the orchestrator from calling a tool or sub-agent once that dependency's failures cross a stated threshold, holds the calls off through a cooldown, then admits a few probe calls before resuming.
A circuit breaker in an agent pipeline is a rule that watches one downstream dependency, a tool or a sub-agent, counts its failures over a window of recent calls, and cuts the orchestrator off from it once the count crosses a set threshold. Calls then fail fast through a cooldown, sparing every other caller from rediscovering the same broken dependency one timeout at a time, and a few probe calls afterwards decide whether the breaker closes again. It shuts traffic off from one dependency entirely, while bulkhead isolation keeps traffic flowing and caps how much of a shared pool any single agent may hold.
Every breaker is a decision rule sitting on top of a failure signal, so the first design question on an agent system is where that signal is supposed to come from. A service dependency hands one over for free: a timeout, a refused connection, a 5xx. Agent dependencies mostly return success, whatever the body actually carries. A pre-registered sweep we ran across two model tiers recorded safety refusals coming back as an HTTP 200 with an empty content array on a benign, machine-checkable task set, 21 refusals across 28 low-effort trials, and a dashboard reading that response files it under success.
A breaker wired to error counts would have sat at zero through all 28.
That places the breaker inside the containment layer rather than beside it. Each hop in an agent graph either holds a fault or passes it on as trusted input, which is how one agent’s error becomes another’s premise. A tripped breaker is one of the gates that holds, so what it stops feeds containment rate, and the ground a fault covers when no gate holds is propagation radius. The pattern is borrowed, and the audit of which resilience moves survive the port from microservices rates the breaker among the cleanest, since a tool call is structurally the same object as a remote dependency. Borrow it for failures you can already detect, and treat the detector as the part you have to build.
How to set a circuit breaker threshold for agents
The threshold is three numbers and a signal. Pick the failure the breaker will count, which on an agent dependency usually means a schema rejection, a verifier declining the output, a stop reason that is not a normal completion, or a latency past a stated bound. Count those over a sliding window of the last n calls, trip when the count reaches k, hold the breaker open for a fixed cooldown, then admit m probe calls and close only if all m come back clean. Martin Fowler describes the same self-reset for services: “We can implement this self-resetting behavior by trying the protected call again after a suitable interval, and resetting the breaker should it succeed” (Circuit Breaker, primary, as of 2026-08).
Choosing k and n is a bet on a proportion, because a healthy dependency still fails from time to time. Take a tool that fails independently on 2% of its calls and a window of the last 20: three or more failures land in that window about 0.7% of the time from chance alone, roughly one spurious trip every 140 windows. Those inputs are schematic and the figure is a binomial tail computed on them, rather than a measurement of any real tool. Your threshold carries a false-trip rate whether or not you went looking for it. Report that rate beside the trips themselves, each with its denominator and an interval, and measure it against a dependency you have reason to believe is healthy.
Instrument the count where the calls already converge. In a fan-out topology that is the orchestrator; where every tool sits behind a single MCP gateway with a central kill switch, the gateway is the natural seat, since it brokers the calls and can refuse them without any agent’s cooperation. Test the breaker by injecting the exact fault it is meant to catch, because a breaker that never fires looks identical to a dependency that never fails. To price what the guarded hop buys end to end, the system reliability calculator multiplies the per-step rates along the chain.
Circuit breaker vs bulkhead isolation
A bulkhead partitions a shared resource so one agent’s consumption cannot starve the others: separate connection pools, worker slots, token budgets, rate-limit quotas per agent or per tenant. Traffic keeps flowing inside each partition, and the partition is a failure domain you drew on purpose. A circuit breaker answers the same exposure differently, stopping calls to one dependency outright once its failures cross the threshold.
Run only one of the two and each leaves a specific hole. A breaker without bulkheads still lets the failing dependency consume the shared pool for as long as detection takes, so a tool that hangs can occupy every worker slot before the count reaches k, and agents that never touched it starve anyway. Bulkheads without a breaker keep the rest of the system upright while the agents inside the affected partition go on calling a dependency that cannot serve them, spending their token budget on returns nobody can use. The bulkhead bounds what a slow failure consumes while the breaker is still counting, and the breaker ends the spending the bulkhead only fenced.
Circuit breaker vs graceful degradation
Graceful degradation is what the system does on the far side of a trip: carry on serving a reduced but still correct result instead of failing the whole request. The breaker is the decision to stop calling, and degradation answers what the caller does with the calls it no longer gets to make. Ship a breaker with no degradation path and the trip turns a slow dependency into a hard error the user sees, buying an outage with the latency you saved. Run a degradation path with no breaker in front of it and every caller pays the full timeout before falling back, so the dependency gets no relief and that cost repeats per request. One concrete degradation path is the ordered list of models tried once the first one refuses, and an open breaker is also what ends a retry storm, since retries against it return at once. Settle what the degraded response says before you settle the threshold that triggers it.
Circuit breakers in electrical engineering trip on a quantity agents never emit
The electrical meaning came first and remains the canonical one: a switch that interrupts current once it exceeds a rated limit, protecting the wiring behind it. Exchanges borrowed the word again for the halts that suspend trading when an index moves past a set percentage. Both trip conditions are quantities fixed before the device is installed, an ampere rating and a price move, read by an instrument that cannot be argued out of its reading.
Software inherited that clean signal from HTTP, and the agent case never inherits it, because an agent hands you a well-formed paragraph. The pattern ports with one part missing: the trip condition. That condition has to be constructed per dependency before the breaker means anything at all. Marc Brooker sharpens the cost of getting that wrong: “Circuit breakers are designed to turn partial failures into complete failures” (Will circuit breakers solve my problems?, 2022, primary). An agent tool that is wrong on one class of input and reliable on the rest is exactly that case, so scope the breaker to the input class it was measured on, and prove the count moves before anyone trusts the trip.
How a single wrong-but-plausible return becomes a system failure, and which gate bounds it at each hop, is the subject of how a fault cascades across agents. Installing the breaker takes an afternoon, and deciding what counts as a failure on an agent dependency takes a great deal longer.