An undo procedure for agent actions is the written runbook a person follows to find what an AI agent did, stop it doing more, and reverse or compensate each action in turn. It names who may invoke it, how affected actions are identified from the record, how each one is undone, and how the work is checked and filed.
What is the procedure for?
Every business that lets agents act will at some point need to take actions back: a wrong rule, a stale source, a misunderstood instruction applied many times. The question is whether that day runs from a tested procedure or from a group call. The short answer to whether you can undo what an AI agent did is "often, if you prepared", and this template is the preparation.
The procedure is different from suspension. Suspension stops the agent; undo deals with what it already did. You will usually run both, suspension first, using the AI agent suspension procedure template.
When should someone invoke it?
Invoke it when a person finds that one or more agent actions were wrong and the effect has reached customers, accounts or records. Do not wait for the cause to be understood; the cause explains the error, but the undo limits the harm.
Write one procedure per agent capability that writes to a system, because the undo steps differ by action. A shared front section, covering roles and records, can be reused. The capability-specific part depends on how each action is classified; which AI agent actions are irreversible helps you set that in advance.
How do you fill in each section?
- Trigger and authority. Who may start the procedure. Make it a role that is staffed every hour the agent works.
- Containment. The exact step that stops further actions of this kind.
- Identification. The query against the verdict record that lists affected actions: agent, capability, time range, any distinguishing input.
- Classification. For each action: reversible, compensable, past its window, or irreversible.
- Undo method. The operation for each class, who performs it, and whether the agent may help.
- Customer handling. Who contacts affected customers and what they are told.
- Verification. A second person checks a sample, or all, of the reversals.
- Closure. What is filed and who signs off.
Keep the procedure tied to your oversight arrangements, as set out in the human oversight procedure template for AI agents.
The undo procedure template
| No. | Step | Fields to complete |
|---|---|---|
| 1 | Invoke | Name of person invoking; time; description of the suspected error |
| 2 | Contain | Capability suspended or reduced; time; who did it |
| 3 | Identify | Record query used; number of actions found; time range |
| 4 | Classify | Count by class: reversible, compensable, window closed, irreversible |
| 5 | Prioritise | Order of work: actions with closing windows first, then by harm |
| 6 | Undo or compensate | For each action: method, performer, time, result |
| 7 | Handle customers | Who is contacted, channel, message reference |
| 8 | Verify | Checker name; sample size or full check; exceptions found |
| 9 | Record | Reversal entries filed against each original verdict |
| 10 | Close | Sign-off by capability owner; link to incident record |
Step 5 is easy to skip. If some actions are still inside a reversal window, they must be handled first, before the window closes and they become harder to fix.
A worked sample: fee refunds applied to the wrong accounts
A hypothetical bank's support agent refunded a monthly fee to customers who asked about it. A change to the fee table caused it to refund customers who had been correctly charged.
| No. | Step | Sample entry |
|---|---|---|
| 1 | Invoke | Support team leader, 10:15, refunds seen on accounts outside the eligible group |
| 2 | Contain | Fee refund capability reduced from depth 3 to depth 2, 10:20 |
| 3 | Identify | Record query: fee refund verdicts since the fee table change; 140 actions |
| 4 | Classify | 140 compensable (fee can be re-applied) |
| 5 | Prioritise | None in a closing window; worked oldest first |
| 6 | Undo or compensate | Decided not to re-apply fees to 140 customers; refunds left in place as goodwill |
| 7 | Handle customers | No contact needed; no customer harmed |
| 8 | Verify | Finance checked total against record |
| 9 | Record | Each verdict annotated with decision and approver |
| 10 | Close | Head of Support signed off; incident linked |
The decision at step 6 is worth noticing. Undo does not always mean reversing. Here, clawing back 140 small refunds would have harmed customer trust for little gain, so the business chose to absorb the cost and record why. The procedure still did its job: every action was found, classified, decided and filed.
Where Pryme fits
Pryme files every verdict in an append-only record, so step 3 is a query by agent, capability and time. Reversals are filed as new entries against the original verdict rather than edits, which keeps the history whole. Deciding which actions may run without a person in the first place is covered in how to decide which actions an AI agent may take without a person, and the wider principle in the guide to regulated autonomy.
Questions people ask
Can the agent undo its own mistakes?
It can help: listing affected actions, drafting reversals and customer messages. Whether it executes reversals should follow the same depth rules as the original action, and a person should decide the approach.
How often should the procedure be tested?
Run a test on a non-production system at least twice a year, and after any change to the capability. A procedure nobody has run will fail at step 3.
What if an action cannot be undone at all?
Record it as irreversible, decide on any remedy for the customer, and feed it into the incident review so the action's depth can be reconsidered.