How do you shut down an AI agent quickly?

Build the switch before you need it, and put it where the agent cannot reach. A suspension set in the enforcement layer stops every action at the next check, in seconds, without waiting for anyone to redeploy anything. Give named people the right to pull it, decide in advance what happens to work in flight, and rehearse it so the first real use is not the first use.

Why is stopping an agent harder than it sounds?

Because agents are spread out. An agent may be running dozens of conversations, have actions queued for tonight, hold tokens to several systems, and hand work to other agents. Stopping the process that runs the model may leave queued actions to fire, tokens valid, and other agents continuing the work.

An agent that holds broad administrative rights is harder still, because it may be able to undo the stop. That is one reason we argue against giving AI agents admin rights.

Which levels of stop should you have?

Graded stops matter because a full shutdown has costs: customers waiting, work piling up. Stop as much as the risk requires and no more.

What are the practical steps?

1. Put the switch in the enforcement layer. Every action is checked there, so a suspension applies at the next attempted action. Nothing depends on the agent noticing.
2. Name who can pull each level. A short list, reachable at all hours.
3. Decide what happens to in-flight work. Queued and scheduled actions are rechecked when they run and refused while suspended. Drafts awaiting approval stay held. Conversations get a handover message.
4. Route work to people. A fallback queue, staffed, with the context the agent had.
5. Revoke tokens if compromise is possible, not just suspend.
6. Record the stop. Who, when, which level, why.
7. Require review before restart. The person restarting should not be the one who caused the problem, and the cause should be understood.
8. Drill it. Pull the switch in a test environment, and occasionally in production on a low-risk capability.

What if the model provider fails instead?

That is a different kind of stop: the agent cannot think, rather than you choosing to stop it. The same fallback queues apply, and the enforcement layer should refuse actions if the agent's outputs are missing or malformed. Our answer on what to do if your model provider goes down covers that case.

A worked example

Take a bank's customer servicing agent. At 18:10, the complaints team notices the agent telling several customers their direct debits have been cancelled when they have not. The on-call operations lead suspends the agent's direct debit capability at 18:12. The agent keeps answering balance questions, but any direct debit request now gets a message that a colleague will call back, and the case goes to the servicing team's queue.

Investigation shows a change to the direct debit system's response format that the agent misread. Because the cause is narrow, the rest of the agent never stops. The capability restarts the next afternoon after a fix and a retest, approved by the process owner. The record shows every refused action between 18:12 and restart.

When agents keep doing things outside their role, rather than misreading a system, the fix is different; see how to stop an AI agent from going beyond its role.

Which controls make the answer hold?

• The switch outside the agent.
• Graded levels, so people are not reluctant to use it.
• Named people with the right to pull it.
• A plan for queued, held and scheduled work.
• Review before restart, recorded.
• Regular drills.

The topic guide, agent governance is a bound, not a model, explains why every stop belongs in the bound, not in the agent.