A suspension procedure sets out who may stop an AI agent, on what triggers, the exact steps to stop it, what happens to work in flight, who is told, and how the agent is brought back. Anyone named in it must be able to suspend without asking permission. Fill one in for each agent you run.
Why does suspension need a written procedure?
Because the moment you need it is the worst moment to work it out. An agent is sending wrong letters, or a feed it relies on is corrupt, or a red-team finding has just been exploited. People hesitate when they are unsure whether they are allowed to act, what will break, or who to call. A written procedure removes the hesitation.
Suspension is also a core part of human oversight. Being able to stop a system is one of the clearest forms of control a person can have, which is why it sits inside the wider human oversight procedure for AI agents.
When do you use it?
Write it before go-live and test it at least once before the agent acts on real work. Use it whenever a trigger is met. The emergency version of the process, for when minutes matter, is set out in how to suspend an AI agent in an emergency.
Suspension stops future actions. Undoing actions already taken is a separate procedure; see the undo procedure template for agent actions. The two are often used together.
How do you fill in each field?
- Who may suspend lists roles, not just names, so someone is always available. Include the duty manager out of hours.
- Triggers are specific: a failed certification run, a pattern of complaints, a source system fault, a security alert, a regulator request. Add "any named person's judgement" as a trigger in its own right.
- Method gives the exact control: where it is, what it does, how long it takes. "Switch off" is not a method.
- Work in flight says what happens to items the agent has started: held items stay held, drafts are returned to a queue, scheduled actions are cancelled.
- Fallback names who does the work while the agent is stopped.
- Return to service needs conditions and an approver who is not the person who suspended.
The AI agent suspension procedure template
| No. | Field | What to write |
|---|---|---|
| 1 | Agent and ID | From the inventory |
| 2 | Who may suspend | Roles and named deputies, including out of hours |
| 3 | Triggers | Specific events, plus individual judgement |
| 4 | Suspension scope options | Whole agent, one capability, one channel |
| 5 | Method | Exact control and expected time to take effect |
| 6 | Confirm it stopped | How to verify no further actions |
| 7 | Work in flight | Held, drafted, scheduled, partially completed |
| 8 | Fallback | Team and process that take over |
| 9 | Notify | Who is told, by whom, how fast |
| 10 | Record | Where the suspension is logged |
| 11 | Investigation | Who investigates; link to incident process |
| 12 | Return to service | Conditions, re-test required, approver |
| 13 | Last tested | Date and result |
A filled sample
A hypothetical payments firm's refunds agent.
| No. | Entry |
|---|---|
| 2 | Refunds team lead; head of payments operations; duty manager out of hours; second-line risk |
| 3 | Refund issued above limit; duplicate refunds detected; refund source data feed fault; certification run failed; any named person's concern |
| 4 | Refund execution only (agent keeps drafting); whole agent |
| 5 | Agent control panel, "suspend capability: issue refund". Takes effect on the next action, under one minute |
| 6 | Check verdict record shows refusals for refund attempts after suspension time |
| 7 | Held refunds stay held. Refunds queued for execution are cancelled and returned to the refunds queue. Executed refunds are listed for review |
| 8 | Refunds team processes manually from the queue |
| 9 | Head of payments operations within 15 minutes; risk and compliance within one hour; customer communications if delays exceed one day |
| 10 | Incident log and agent change log |
| 12 | Root cause found; fix tested on 200 refund cases; approved by head of payments operations and second-line risk |
| 13 | Tested last quarter: suspension took effect in 40 seconds |
Row 4 is worth copying. Suspending one capability lets the agent keep doing safe work, drafting, while the risky capability is stopped. Teams that can only switch off the whole agent tend to hesitate longer.
Where Pryme fits
In Pryme, suspending a capability drops it to depth 1 immediately: the agent can still read, but every attempt to act is refused and filed with the reason. A failed Attest run does the same automatically on the day it fails. More in agent governance is a bound, not a model.
Questions people ask
Should suspension need a second approval?
No. Requiring approval to stop an agent delays action exactly when speed matters. Require approval to restart instead.
Do we have to tell the regulator when we suspend an agent?
It depends on the cause and your obligations. Some incidents are reportable, for example under operational resilience or incident-reporting rules, so link suspension to your incident process and let compliance decide.
How often should we test suspension?
Before go-live, after any change to the agent's connections, and at least twice a year. A suspension control that has never been used is a hope, not a control.