On this page 5 sections
Most conversations about agents are about capability. Can it book the meeting, file the refund, update the record? I think the more important question is what happens the 3% of the time it does the wrong thing, and how long it takes a person to put things back.
The arithmetic of almost right
Take a scheduling agent in a pilot we’ll describe in general terms: 400 users, an average of six actions each per day. That is 2,400 actions. At 97% correctness, 72 actions a day are wrong. Some are harmless, like a meeting title phrased oddly. Some are not, like a client invitation sent for the wrong week.
Raising accuracy from 97% to 98% removes 24 of those mistakes. It is valuable and hard work. Making every mistake reversible in one click changes the experience of all 72. In the pilot, adding undo did more for retention than the next model upgrade did, and it cost a fraction of the engineering time.
Sort actions by how they come back
Not every action can be undone the same way. Before giving an agent a tool, put the tool in one of these rows.
| Action type | Example | Undo strategy |
|---|---|---|
| Read only | Search the calendar | None needed |
| Reversible write | Move a meeting | Store the prior state, offer one-click revert |
| Reversible with side effects | Send an invite | Delay delivery for a short window, then revert plus notify |
| Irreversible | Issue a refund, delete data | Stage as a draft and require confirmation |
The third row is where most products fail. Moving a meeting is easy to revert, but the attendees already received an email. A real undo has to cover the side effect, which usually means sending it later or sending a correction.
A small pattern for reversible tools
Every tool an agent can call should describe how to reverse itself. If it cannot, that is a design decision to make explicitly, not a gap to discover in production.
interface AgentAction {
id: string;
describe(): string; // "Move 'Design review' to Thu 14:00"
apply(): Promise<unknown>; // returns the state needed to revert
revert(prior: unknown): Promise<void>;
reversible: 'full' | 'with-notice' | 'none';
}Each applied action is written to a journal with its prior state. The interface shows the journal as a timeline the user can scroll back through, with a revert button on each entry. Actions marked none never execute directly; they become drafts the user approves.
What this changes in the interface
Undo is not just a backend feature. Users have to see it to trust it. Three details mattered in our testing:
- Say what happened in plain words. “Moved ‘Design review’ from Tuesday to Thursday” beats a green checkmark.
- Keep undo available for a reasonable time. A five-second toast is too short when the user is on a call. The journal kept revert available for 24 hours.
- Make reverting cheap socially. If undoing an invite sends attendees an awkward cancellation, people will leave the mistake in place. Write the correction message for them.
Autonomy follows reversibility
Teams often ask how much autonomy to give an agent. My answer is that autonomy should track reversibility. Let it act freely where every action can be walked back. Ask for confirmation where effects leak out to other people. Keep drafts for anything permanent. As the undo path improves, the confirmation steps can shrink, and users will let the agent do more because they are no longer afraid of it.