Build the Undo First
Software spent forty years teaching us that almost nothing is permanent. Undo is one keystroke away. Deleted files sit in a trash folder for a month. Documents keep their version history. Email services let you unsend a message for a few seconds after you regret it. A whole generation learned to work quickly and boldly on screens because the screen forgave them. Make the change, look at it, take it back if it is wrong.
That habit was one of the quiet gifts of personal computing. It lowered the cost of trying things. It made experimentation cheap and mistakes survivable. And it trained an expectation so deep that most of us no longer notice it: if something goes wrong, there is a way back.
AI agents are now leaving the screen. They are being built to send the email rather than draft it, to book the flight rather than suggest it, to move the money, cancel the subscription, delete the old files, accept the terms of service, reply to the customer. Each of those is an action in the world rather than a change in a document. And the world, unlike a word processor, does not keep a version history.
The asymmetry nobody designs for
Every action an agent can take falls somewhere on a line between fully reversible and permanent. Renaming a file is at one end. Sending a message to your whole contact list is at the other. Most of the interesting actions sit in between: a purchase that can be returned within a window, a booking with a cancellation fee, a payment that can be disputed but not easily recovered, a deleted record that exists in a backup somewhere if anyone thinks to look.
The trouble is that agents are mostly being designed around what they can do, and very little around where each action sits on that line. A capable agent that treats sending a reply and wiring a deposit as the same kind of step is not a capable agent. It is a confident one. The distinction that matters most, between the things that can be taken back and the things that cannot, is often not represented anywhere in the system at all.
People make this distinction without thinking about it. You draft an angry message freely and then hesitate over the send button. You browse a hundred listings and pause before the one that says nonrefundable. That pause is not inefficiency. It is the most important judgment in the whole sequence, and it is exactly the judgment we are most eager to automate away.
What payments learned
I spent much of my career in payments, and payments is an industry built around the problem of irreversible action between strangers. Money moved in error is very hard to get back. So over decades the industry built windows into the process on purpose. A charge can be voided before it settles. It can be held when something looks wrong. It can be disputed after the fact, with rules about who carries the loss. None of these exist because bankers enjoy friction. They exist because, without them, nobody would have trusted the system enough to use it at the scale it now runs.
The lesson I took from that work is simple: speed is only safe when there is a way back. The faster and more automated a system becomes, the more deliberately its reversal paths have to be designed, because a fast system that cannot be corrected does its damage before any person has time to notice.
Four questions for any agent
If I were reviewing an agent before it shipped, these are the questions I would ask before anything about its capabilities.
First, which of its actions can be reversed, and for how long? Not in theory, in practice, by an ordinary user who is upset and in a hurry.
Second, which actions cannot be reversed, and does the agent behave differently around them? An agent should slow down at exactly the points where a careful person would, and it should say so plainly.
Third, is there a window between deciding and doing? A short delay, a summary, a chance to say stop. The best reversal is the one that happens before the action lands.
Fourth, when something irreversible does go wrong, does anyone find out quickly enough for it to matter? Many of the worst failures are not the mistake itself but the hours or days in which nobody knew it had happened.
More capable is not more careful
It is tempting to think that better models will make all of this unnecessary, that a smart enough agent simply will not make the mistakes that need undoing. I do not believe that, and I do not think the people building these systems believe it either. Today's AI wants nothing. It does not intend its mistakes and does not feel them afterward. Nobody knows what self-improving systems will be able to do, but more capable is never more human, and capability alone does not supply the hesitation a person feels in front of something permanent. A more capable agent mostly makes its mistakes faster, more fluently and further from anyone watching.
That is why the way back matters more as the systems improve, not less. Intelligence raises the stakes of every action. It does not lower the need to recover from the bad ones.
So here is the order I would build in. Before the agent learns to book, buy, send or delete, build the path that undoes each of those, and mark clearly the actions that have no such path. Make the permanent things slow and visible. Make the reversible things fast. Then, and only then, make the agent clever.
Software taught us that we could be bold because the screen would forgive us. The world will not. The most important feature an agent ships is not what it can do. It is what happens when it was wrong.