Undo was simple while the person did the thing themselves. They acted, they regretted it, they pressed the other thing. The stack lived in their head as much as in the software.
An agent that works overnight puts entries in that stack the user never made. So undo stops being one feature and becomes three, and the three fail independently.
The reversal. Can it be taken back, by whom, at what cost. Two rules worth writing into the spec: reversal costs no more actions than the original did, and partial reversal is possible when the action was a batch. Undoing forty changes because one was wrong is a punishment for using the feature, and people only need to be punished once. Also make it available to someone other than the original user when the account is shared or managed, because admins will need it, and they will need it on a bad day.
The notification. How they find out. It carries the change, not the fact of a change, and it carries the undo control itself. There is one place that lists everything done on the user's behalf, reachable at any time. That list is the thing people ask for immediately after the first incident, and building it before the incident is cheaper in every sense.
And the window. How long they have and what happens when it closes. Nobody names this one.
Ask your team what the window is for your most common autonomous action. If the answer takes more than ten seconds or comes back as a question, that is the finding, and the number is currently being set by a cache expiry rather than by a design decision.
Sort every autonomous action into one of four classes before designing any of it.
Reversible and private: undoing restores the previous state and nobody outside saw it. Drafted, sorted, tagged, organized.
Reversible and witnessed: the state restores but somebody already read the original.
Irreversible and contained: cannot be undone, the effect stays inside the account. Data permanently deleted, a credit consumed.
Irreversible and external: cannot be undone, the effect left the building. Payment sent, email delivered, permission granted, external write.
Which gives the rule everything else hangs off. Irreversible external actions do not run autonomously. A human confirms in-session. That is the one place where "the agent handled it" costs more than it saves, because there is no interface that recalls a sent payment.
Three properties the window has to have. Stated in the interface before the action runs. Stated again in the notification in the user's own terms, so "until Friday morning" rather than a timestamp. And it survives the user being away, since a window that expires overnight for an action taken overnight is a window in name only.
Then something visible has to happen when it closes: a summary, a confirmation, a state change. Silence at the close is how people learn the window existed only on the day it mattered.
One test catches bad classification. Write three sentences per autonomous action: what the product will do and how long it can be taken back, what it did and the control to take it back, and that the window has closed and what the state is now. If you cannot write the third one without it sounding alarming, the action belonged in a class that needed confirmation. The copy just told you what the design review did not.
This week: list every action your product takes without a human in the loop and assign each a class. The irreversible external ones are Thursday's conversation, and that list is almost always longer than anyone expects.
The full checklist is The Undo Checklist, and the argument behind it is in Undo Is a Design Primitive.