Undo over confirm, and why AI products need it more

August 16, 2026 · Alex Zapadenko

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. The common case — the user meant it — costs nothing, and the rare mistake costs one click. 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?

Reversible and frequent — archive, remove a row, mark done — takes Undo. Irreversible, or rare and consequential, takes a confirmation: you cannot offer to undo something you can't take back. Rare and harmless can go either way and isn't worth the argument.

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. That erodes the guard for the actions that genuinely needed one, which are 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 to build.

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're not unpicking a completed operation, you're declining to start one.

That reframing changes what's feasible. Reversing a committed delete is a data problem; not committing yet is a scheduling problem, and scheduling problems are much easier.

Two details that decide whether it feels right. Restore to the exact prior state — the same position in the list, the 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

Three reasons, and they compound.

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. The value of delegation is not having to be in the loop for every step, so the recovery has to sit after the action rather than in front of it.

There's a fourth, quieter reason. Confirmation asks the user to predict whether an outcome will be right. 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 a much easier task than authorising one you can't, so moving the decision after the action also moves it to the point where the user can actually make it.

The harder problem with agents

The classic rule takes reversibility as a given: check whether the action is cleanly reversible, then pick. 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 design 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. Where that isn't possible, you're back to a confirmation, and it should be a real one rather than a reflex.

This is the same move as the deferred commit above, applied to side effects rather than to a database write. 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.

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.

The failure mode of this whole argument is a product where nothing ever stops you, and some of what it did quietly cannot be recovered. An undo you can't honour is worse than a confirmation you resented, because the promise was explicit.