Quick answerA kill-switch runbook is the manual, human-initiated procedure for taking an AI agent completely offline during a live incident — not a slow rollback, not a partial throttle, but a full stop. It needs four things written down in advance: a named list of people authorized to pull the switch without further approval, the exact technical mechanism that actually removes the agent from the live traffic path (not just disables one feature flag), a pre-built fallback so customers land somewhere other than a dead end, and a verification step that confirms the agent is truly down rather than just returning errors while still consuming requests. Treat this as incident-response infrastructure, built and rehearsed before you need it, not documentation written after the first bad outage.
Why "pause the feature flag" usually isn't a kill switch
Most teams believe they have a kill switch because they have a feature flag that disables the agent's UI entry point. That stops new conversations from starting. It does nothing for conversations already in flight, background jobs the agent kicked off, or scheduled actions it queued before someone noticed it was misbehaving. A real kill switch has to answer three questions your flag doesn't: what happens to conversations already open, what happens to actions the agent already initiated but hasn't completed, and what happens to any autonomous write access it holds to other systems. If the agent can write to a database, send emails, or trigger payments, the kill switch has to be able to revoke that write path specifically, independent of whether the chat UI is showing the agent as "unavailable."
Who is authorized to pull it, and what they need to see first
Emergency authority causes hesitation if it's ambiguous. Name the roles (not individuals, since people rotate) who can execute a full stop without waiting for sign-off from someone else, and give them a single dashboard view that answers the two questions they'll actually ask in the moment: is this agent behavior actually anomalous relative to its own baseline, and is the anomaly severe enough that being fully offline is safer than staying up in a degraded state. A self-imposed circuit breaker that automatically throttles high-risk actions when the agent's own error signals spike is a different, narrower mechanism — it's the agent policing itself in real time before a human is even paged. The kill-switch runbook is what a human does once they've been paged and decided automated throttling isn't enough.
What "offline" has to mean technically
Write the actual technical steps, not just the intent. At minimum: remove the agent from the load balancer or router so no new requests reach it, revoke or rotate any API keys and write-scoped credentials the agent uses to act on other systems, and force-close or hand off any conversations currently in progress rather than letting them silently time out. If your infrastructure spans multiple regions, the runbook needs to name how you confirm the stop applied everywhere, not just in the region where the incident was first noticed — the same operational discipline used for regional infrastructure failover during a cloud outage applies here: a stop that only works in one region isn't a stop.
Verifying it actually worked, not just declaring it
The most dangerous failure mode is believing the agent is offline when it's actually still processing a backlog of queued requests or retrying failed calls in the background. Build a verification check into the runbook itself: query the system that would show live agent activity (request logs, active session count, queue depth) and require a human to confirm zero before declaring the incident's first phase closed. Once you do bring it back, don't declare full recovery the moment it's technically reachable again — the same discipline used for setting a realistic recovery-time expectation after an outage ends applies to a self-inflicted stop too: tell customers what's restored, what's still catching up, and when you expect full normal service.
FAQ
Does a kill switch replace a circuit breaker? No. A circuit breaker is automated and narrow — it throttles specific high-risk actions the moment the agent's own error signals cross a threshold, without a human involved. A kill switch is manual and total — a human decides the agent needs to be fully offline, not just throttled. Mature setups have both: the circuit breaker buys time and limits damage; the kill switch is what a human reaches for when the circuit breaker isn't enough.
How fast should the runbook get the agent offline? Fast enough that the technical steps, not approval-seeking, are the bottleneck. If your authorized responders have to escalate to get permission before acting, the runbook has already failed its main design goal. Pre-authorize the roles, not the individual incident.
What should customers see while the agent is offline? A working fallback path, decided in advance — not a generic error page. At minimum, a route to a human channel or a clear status message with an honest estimate, not silence.
Should this be rehearsed, not just documented? Yes. A runbook nobody has executed under pressure will have gaps you only find live. Run it as a drill on a non-production environment at least once before you need it for real.