How do you undo something an AI agent did?

Sort the actions first, because the sorting is the whole answer. A reversible action can be put back exactly as it was: a field edited, a record updated, a file changed where the previous version exists. A compensable action cannot be undone but can be answered by another action with roughly the opposite effect: a payment refunded, an order cancelled, a booking released. An irreversible action has already reached somebody: a message sent, a public post published, a document shared, a record deleted from a system with no history. Only the first has an undo, and treating all three as one category is why recovery is usually improvised.

The practical consequence is that permissions should be granted by category rather than by system. Give an agent reversible actions freely, because a mistake costs a restore. Give it compensable actions with a ceiling, because the compensation has a cost and the cost is what needs bounding. Give it irreversible actions only through a hold — a queue where a person releases the item — or not at all. This is a more useful frame than trusting a system more as confidence grows, because the categories do not change as confidence does.

Restoring requires a before-state that somebody actually kept, and this is the step most often missing. An agent that updated a field can only be undone if the previous value was captured, and most systems overwrite. Capturing the before-state at the moment of the write — not from a nightly backup, which loses everything since — is the difference between an undo that takes seconds and a reconstruction that takes a day. It is cheap to build at the start and awkward to add afterwards.

Blast radius matters more than correctness for the same reason it does in any automated system. One wrong record is a correction. Four thousand records updated by a loop that ran overnight is an incident, and the difference is not the error rate but the absence of anything that stopped it. A rate limit and a cap on the number of items a single run may touch are the two controls that keep a mistake in the first category, and they cost almost nothing until the day they are the only thing that saved you.

Detection is the other half and it is usually the weaker one. An undo you cannot trigger because nobody noticed for three weeks is not a control. The realistic mechanisms are a log somebody reads, an alert on volume rather than on error, and a check that compares what the agent changed against what it was asked to change. Volume is the more useful signal: agents fail by doing a great deal of something, and a run that touched ten times its usual number of records is visible without anybody understanding what it did.

Finally, the irreversible category is where the design should be attacked rather than defended. Most workflows have an irreversible step because nobody separated the composing from the sending. An agent that drafts every reply and a person who releases them has a workflow with no irreversible agent action in it at all, and it captures most of the time saving. Moving an action out of the third category is almost always cheaper than building a way to survive it.