Every Action Needs an Undo (or a Gate)

Ask one question before an agent is allowed to do anything: if this goes wrong, how do we get back? Every action falls into one of two buckets. Either there's a credible undo — restore the file, revert the record, resend the corrected email as a follow-up — or there isn't. And the bucket, not the task's importance, is what should decide whether the agent acts alone.

This sounds obvious until you audit a real agent's toolbelt. Sending a Slack message: no undo (it's been read). Deleting a file: undo, if you use a trash instead of rm. Updating a CRM field: undo, if you logged the old value first. Issuing a refund: no undo. Publishing a blog post: mostly undoable — you can unpublish, but caches and inboxes have long memories. Most teams grant agent permissions by task ("it handles invoicing") when they should grant them by reversibility class.

The pattern has two halves.

Reversible actions get an undo path built before the action runs, not after it fails. That means write the old value to a log before the update. Move to trash instead of delete. Take the backup before the migration, and verify the backup restores — an untested undo is a wish. The test is concrete: could a tired human, at 2am, reverse this action with one command using only what the agent recorded? If the answer requires archaeology, the undo doesn't exist.

Irreversible actions get a gate: a human approval that names the exact thing about to happen. Not "approve pending operations" — that's a rubber stamp. The gate shows the specific email, the specific amount, the specific record, and a human says yes to that. A good gate is boring and fast, because the agent did the work of making the decision legible. If approvals feel tedious, the problem is usually vague previews, not the gate itself.

There's a third move worth naming: converting irreversible into reversible. Drafts instead of sends. Holds instead of charges. Soft-delete with a 30-day sweep instead of hard delete. A staging table instead of production writes. Every one of these conversions buys the agent autonomy it couldn't safely have otherwise — the engineering effort pays for itself the first time something goes sideways and the answer is "reverted, no harm done" instead of an apology tour.

I've seen the counterexample at a fictional property management shop: an agent that could edit lease records directly, no snapshot, no gate. It "corrected" a rent figure based on a misread email, and nobody could say what the old number had been. The fix took a week of digging through PDFs. The same edit behind a restate-and-confirm gate, with the old value logged, would have been a non-event twice over — either caught at the gate or reverted in seconds.

The deeper point: an agent's autonomy budget is set by its blast radius, and undo paths shrink blast radius. You don't make an agent safer by making it timid. You make it safer by making its mistakes cheap.

Classify every action. Build the undo first. Gate what can't be undone. Then let the agent run.

Deciding what an agent may touch alone — and what waits for a human — is the heart of running one well. The full playbook, gates and all, is in the book: Ops by Agent.