Undo over confirm
Tags: agents, destructive, recovery
For an action that is genuinely reversible and happens often, don't interrupt with a confirmation. Apply it immediately and offer Undo for a few seconds. In products where a model acts on your behalf this stops being a preference and becomes the only workable option.
Anatomy
- 01
Immediate apply
The change happens on screen the moment the action fires.
- 02
Undo offer
"Done. Undo", visible for a few seconds.
- 03
Deferred commit
The irreversible write waits until the window closes, so Undo cancels rather than rolls back.
- 04
Exact restore
Undo puts things back where they were: same position in the list, same selection, same scroll.
- 05
One window
A second action commits the first, rather than stacking pending undos.
- 06
Staging point
For an agent, the window sits before anything leaves: the email, the charge, the API call.
The ordinary version of the rule
Two questions decide it. Can the action be cleanly reversed? And does it happen often?
The cost of getting this wrong is not symmetrical. A confirm dialog on a frequent reversible action doesn't just annoy people, it trains them to dismiss dialogs without reading — which erodes the guard for the actions that genuinely needed one, usually elsewhere in the same product.
The mechanism that makes undo cheap
This is the part usually left out, and it's why undo has a reputation for being expensive.
Undo doesn't have to reverse anything. Apply the change in the interface immediately, and defer the irreversible commit until the undo window closes. The item leaves the list at once, the toast appears, and the real write happens a few seconds later if nobody objects. Undo is then a cancel rather than a rollback — you are not unpicking a completed operation, you are declining to start one.
Reversing a committed delete is a data problem; not committing yet is a scheduling problem, and scheduling problems are much easier.
Two details decide whether it feels right. Restore to the exact prior state — same position in the list, same selection and scroll — because undo that re-adds the row at the bottom breaks the promise of putting it back. And keep one window at a time: if a second action fires, commit the first rather than stacking pending undos into ambiguity.
Why AI products need it more
- The frequency changes. A model that drafts, edits, tags, files and rewrites produces far more state-changing actions per session than a person clicking through a UI. Confirmation cost scales linearly with that volume; undo cost does not, because the overwhelming majority of actions are never undone.
- The user didn't initiate them. When a model does something unasked, a confirmation dialog is asking permission for something the user didn't request and may not have understood yet. Undo is the honest shape: the system acted, here is what it did, here is how to take it back.
- Confirming each step defeats the point. If an agent takes twelve actions and each needs approval, the user has done the work with extra clicks.
- Confirmation asks for a prediction. It asks the user to judge whether an outcome will be right, and with a probabilistic system they often can't — they don't know what the model is about to produce. Judging a result you can see is much easier than authorising one you can't.
The harder problem with agents
The classic rule takes reversibility as a given. For an agent that touches the outside world, reversibility is not a property you discover — it's something you design for, and mostly you get it by choosing where the commit boundary sits.
An agent that sends an email, charges a card or calls a third-party API has crossed a line you cannot pull back across. So the work is arranging for the undo window to sit before that boundary: stage the outbound action, hold it briefly, and let the window elapse before anything leaves. If you want a product that can act on someone's behalf without asking permission constantly, the thing to build is a staging point, not a better dialog.
Grounded in
The two questions above, and the deferred-commit mechanism, come from the interaction patterns behind this site's own design system — where the same rule is documented for ordinary destructive actions. What changes in an AI product is not the rule but the volume and the authorship: far more actions, most of them not initiated by the person who has to live with them.
Do and don't
Do
Confirm before an action that cannot be taken back.
Don’t
Offer Undo for something Undo cannot restore.
An undo you can't honour is worse than a confirmation someone resented, because the promise was explicit.
Do
Apply frequent, reversible actions at once and offer Undo.
Don’t
Ask "Are you sure?" before every one of them.
Dialogs on frequent actions train people to dismiss dialogs without reading, which wears down the guard on the actions that needed one.
Do
Hold the real write until the undo window closes.
Don’t
Commit the moment the action fires.
Optimistic with no way back is just a delete with extra steps.
Do
Restore the exact prior state: same position, same selection, same scroll.
Don’t
Re-add the item at the bottom of the list.
Undo promises to put it back, and putting it somewhere else breaks that promise.
Do
Stage an agent's outbound action and let the window elapse before it leaves.
Don’t
Answer an agent's volume with a better confirmation dialog.
Past the commit boundary there is nothing to undo, so the boundary is where the design work goes.
Where confirm still wins
Permanent deletion. Anything that spends money. Anything that leaves the building — a message to a customer, a filing, a publication. Actions that are rare and consequential, where friction is the point and nobody is doing it forty times an hour.
Related patterns
- Design the failure state first — "did more than asked" is the failure this pattern answers.
- Wizard or conversation — the review step is where an agent's commit boundary belongs.
The full argument: Undo over confirm, and why AI products need it more.