Design a kill switch for a production agent fleet

A **kill switch** lets you disable a dangerous capability fast without taking the whole product down. The trap is treating it as a code change or a prompt rewrite. Both are too slow and too risky in the middle of an incident. The right shape is a config flag. Keep your tool registry (refund, cancel-order, escalate, etc.) in a runtime config store like LaunchDarkly, etcd, or a small KV the orchestrator polls. Each tool gets an enabled boolean. To kill refunds, you set refund.enabled = false. The change propagates to every agent process in seconds because the orchestrator reads the flag each time it dispatches a tool call. The agents themselves keep running. If the model proposes a refund, the dispatcher intercepts the call, returns a templated message back into the conversation (refunds temporarily need human approval, a ticket has been opened), and pushes the case into a human queue. The customer sees graceful degradation, not an outage. Log every blocked call with the user input and the retrieved context so you have evidence for the incident review. Test the switch every quarter so you know it works.

**Kill switch** in production agent terms is a per-tool config flag the orchestrator reads at dispatch time. Not a deploy. Not a prompt edit. A config flip that propagates in seconds. The design: store your tool registry in a runtime config service (LaunchDarkly, ConfigCat, etcd, Consul, or an in-house KV that agent processes poll). Each tool entry carries an `enabled` boolean and optional scope (tenant allowlist, environment, region). The orchestrator checks the flag on every tool dispatch. When the red team finds an exploit on refunds, you flip `refund.enabled = false`. Within a few seconds, every agent in the fleet stops calling refund. **Graceful degradation matters.** Agents stay online. When the model emits a refund tool call, the dispatcher short-circuits it and returns a templated tool-result that explains a human will follow up. A ticket is opened automatically. The customer keeps talking to the agent; the agent picks up the conversation from the new context. **Evidence requirements:** every intercepted call is logged with the original model proposal, the user input, the retrieved context, and the rail decision. That log feeds the incident review and the regression test you write next. And test the switch quarterly in a game-day exercise so you know the propagation latency before you need it.