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.

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.

Anti-patterns

• Undo offered for irreversible actions. If clicking Undo can't restore the state, you have made a promise you can't keep. An undo you can't honour is worse than a confirmation someone resented, because the promise was explicit.
• Confirm dialogs on reversible, frequent actions. Death by a thousand "Are you sure?"
• Committing instantly with no window. Optimistic with no way back is just a delete with extra steps.
• Restoring to the wrong place. Undo that re-adds the item at the bottom of the list breaks the mental model of putting it back.

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.