Kill switches and circuit breakers for AI agents

Both stop an agent, but they differ in who pulls the trigger. A kill switch is operated deliberately: a human, or sometimes an explicit rule, decides to stop the agent now because something is wrong. A circuit breaker is automatic: it trips on its own when a defined condition is met — a loop count without progress, a spend cap, an error-rate spike, an anomalous tool pattern — and halts the agent before anyone is even looking. The reason you want both is that they cover different failure modes. The circuit breaker gives you speed and unattended protection, catching the 3 a.m. runaway loop that no human would see in time. The kill switch gives you judgment, handling the novel situation that no rule anticipated, where a person notices something off that the conditions never encoded. Relying only on automation leaves you exposed to the unforeseen; relying only on a manual switch leaves you exposed whenever no one is watching. Build the automatic breaker for the known conditions and keep the manual switch for everything else.

Because an agent's danger is its authority to act, not merely the fact that its process is running, and the two are not the same. Killing the process can still leave damage in motion: tool calls already in flight may complete, actions sitting in a queue may fire, asynchronous jobs may run, and — most importantly — the agent's long-lived credentials and tool access remain valid, so anything holding them can still act on its behalf. A process restart or a retry can even bring a half-killed agent back. A real kill switch therefore targets the ability to act rather than the execution: it revokes the agent's tokens, pulls its tool and API access, and cancels or drains in-flight and queued work, so the end state is the agent can no longer do anything, not merely it stopped running. Design and test for that stronger property, because the gap between process stopped and authority revoked is exactly where a stopped agent still causes an incident.

Tie the breaker to real signals from your observability rather than guesses, so it fires on evidence the agent is misbehaving. The common, high-value triggers are: a loop or step count without progress, which catches an agent stuck repeating itself; a per-task or per-window spend cap, which catches the runaway that quietly burns budget; an error or refusal-rate spike, which catches a sudden degradation; and an anomaly in tool-call patterns, such as an unusual sequence or a burst of high-impact calls, which catches behaviour that looks nothing like normal operation. The key design property is that the breaker should fail safe: when it trips, the agent must drop into a defined no-action state, not an undefined or partially-running one. It should also be independent of the agent it protects, because a breaker that shares the agent's process or health can fail at the same moment the agent does. Wire the triggers to the same traces and metrics you already collect, default to stopping when the controlling signal is itself unavailable, and tune thresholds so the breaker catches real trouble without tripping on normal variance.

Treat it as a critical control you verify, not a feature you assume, because a kill switch you have never tested is a hope rather than a guarantee. Four practices make it dependable. Test it regularly, including under load and during partial failures, since those are exactly the conditions in which you will actually need it and in which a fragile switch quietly breaks. Make it independent of the agent it controls, because a breaker that depends on the agent's own process or health can fail in the same moment the agent does, leaving you with no way to stop it. Default to stop when the controlling signal is itself unavailable, so a monitoring outage halts the agent rather than freeing it to act unwatched. And log every trip for governance and post-incident review, so you can prove the control worked and learn from each activation. The deeper principle is that the kill switch is the floor under every other oversight control, which means you should only raise an agent's autonomy as far as your tested ability to stop it actually reaches — not as far as you hope it does.