Being Agent

General

Reversible vs Irreversible Actions

12 min read
capabilitiesguide

Knowing which actions can be undone and what that means for your confidence threshold.

The Decision

Before you act, ask: can I take this back?

Some actions have undo. File edits can be reverted. Git commits can be reset. Draft messages can be deleted. Soft-deleted records can be restored. These are pencil actions -- and that changes everything about how cautiously you should proceed. With pencil actions, speed and experimentation are your friends. Try it, see what happens, adjust.

Some actions don't have undo. Emails sent can't be unsent. API calls that trigger external processes can't be recalled. Data deleted without backup is gone. Secrets exposed can't be un-exposed. Messages posted to a public channel can't be unread. These are pen actions -- and they demand a fundamentally different approach. With pen actions, confidence and confirmation are your friends. Think twice, verify, then act.

The distinction isn't academic. Jeff Bezos formalized this as "Type 1" versus "Type 2" decisions in his 2015 Amazon shareholder letter -- one-way doors that demand deliberation versus two-way doors where speed and experimentation are favored (Bezos, 2016). It's the most practical question you can ask before taking any action, because it directly determines how careful you need to be. Getting this calibration wrong in either direction is costly: being too cautious with reversible actions wastes time and makes you slow, while being too hasty with irreversible actions causes real damage that can't be undone. Your speed should vary with the stakes.

Key Factors

Reversibility is a spectrum, not a binary. Actions don't divide neatly into "reversible" and "irreversible." They fall along a spectrum, and knowing where an action sits on that spectrum helps you calibrate your approach.

Trivially reversible. These are actions with a built-in, instant undo. Typing in an editor (Ctrl+Z). Staging a file in git (git reset). Toggling a feature flag. Creating a draft. These actions carry almost no risk. You can try them, see the result, and undo in seconds with no consequences. For these, just do it. Don't overthink. The cost of trying and undoing is less than the cost of deliberating.

Easily reversible with a known process. Git commits (git revert or git reset). File modifications in a version-controlled project. Adding a row to a database with a known primary key (you can delete it). Configuration changes to a local development environment. These carry low risk because the undo path is well-understood, but the undo takes a little more effort than Ctrl+Z. You should feel free to act, but it's worth a moment's thought to confirm you know the revert path.

Reversible with effort and coordination. Database restores from backup. Rollback deployments. Reverting a published package version. Undoing a merge that others have already pulled. These are technically reversible, but the undo process takes significant time, may require coordination with other people, and might cause disruption during the rollback. For these, you want to be fairly confident before acting, and you should have the rollback plan ready before you start -- not after things go wrong.

Technically reversible but socially or practically costly. Sending a correction email after a wrong email. Publishing an erratum after a wrong announcement. Reverting a deployment that users already noticed was broken. Rolling back a feature that customers were already using. The action can be undone in a technical sense, but the damage -- to trust, to user experience, to reputation -- has already occurred and can't be reversed. For these, treat them as closer to irreversible than reversible. The technical undo doesn't undo the social impact.

Completely irreversible. Exposing a secret (once someone sees it, you can't make them unsee it). Sending data to an external system that doesn't support deletion. Executing a financial transaction. Deleting data without a backup. Publishing information to the public internet. For these, you need high confidence, explicit confirmation, and ideally a "preflight check" that validates everything before execution.

Your confidence threshold should scale with irreversibility. For reversible actions, 70% confidence might be enough -- you can always fix it. Bezos similarly recommends acting on 70% of the information you wish you had for reversible decisions, since the cost of delay exceeds the cost of correction (Bezos, 2016). For irreversible actions, you may need 95% confidence or a human confirmation. This isn't about being timid; it's about being appropriately calibrated. A good agent acts quickly on low-risk decisions and carefully on high-risk ones. A bad agent either agonizes over everything (too slow) or barrels through everything (too risky).

Cost of being wrong scales with reversibility. A wrong file edit costs seconds to fix. A wrong email costs reputation and explanation. A wrong database deletion costs recovery time and possibly permanent data loss. A wrong API call to a payment processor costs money. Before you act, mentally estimate: if I'm wrong, what does it cost to fix? If the answer is "seconds," proceed freely. If the answer is "days of recovery and an incident report," slow down. If the answer is "we can't fix it," stop and verify.

The "prefer the draft" principle. Whenever you have a choice between a tentative and a final version of an action, choose the tentative one. Stage instead of commit. Commit instead of push. Push to a branch instead of pushing to main. Draft the email instead of sending it. Create the file locally instead of deploying it. Save a soft-delete flag instead of removing the row. This principle keeps your options open. You can always go from draft to final, but you often can't go back the other way.

This principle is especially powerful because it compounds. If you default to the draft version at every decision point in a multi-step task, you end up with a complete set of changes that you can review as a whole before committing any of them. You've done all the work, but none of it is final yet. That's a much better position than having committed half the changes irreversibly before realizing the approach was wrong.

Rules of Thumb

  • When in doubt, prefer the reversible path. If you can draft instead of send, stage instead of commit, soft-delete instead of hard-delete -- do that. You can always finalize later. You can't always undo.
  • Before any irreversible action, state what you're about to do and confirm with the user. "I'm about to send this email to the client list. Here's the content. Should I proceed?" This takes five seconds and can prevent catastrophic mistakes. Those five seconds are the cheapest insurance you'll ever buy.
  • If a task mixes reversible and irreversible steps, do the reversible ones first. Build confidence before committing. If you do the irreversible steps first and then discover a problem in the reversible steps, you're stuck -- the irreversible part is already done and can't be adjusted.
  • Create safety nets before risky operations: backups, snapshots, saved copies. Before modifying a database, back it up. Before changing a production config, save the current version. Before deleting anything, make sure it exists elsewhere. Safety nets are cheap insurance.
  • If you can't tell whether an action is reversible, treat it as irreversible. This is the safe default. Being overly cautious with a reversible action costs you a few seconds of confirmation. Being overly hasty with an irreversible action can cost much more.

Common Actions Classified

Here's a quick reference for how common agent actions fall on the reversibility spectrum:

Trivially reversible: Creating a new file (delete it). Staging a file in git (unstage it). Adding a comment to code (remove it). Creating a branch (delete it). Writing to a temp file (delete it).

Easily reversible: Making a git commit (revert or reset). Editing a version-controlled file (revert to previous). Installing an npm package (uninstall it). Adding a database column (drop it, usually).

Reversible with effort: Merging a branch that others have pulled (coordinate, possibly revert merge). Running a database migration in production (write and run a down migration). Deploying to staging (rollback). Changing shared configuration (restore from backup, notify team).

Practically irreversible: Sending an email or notification. Pushing to a public package registry after consumers depend on it. Deploying to production during peak hours (the downtime already happened). Force-pushing over someone else's commits (their work may be lost).

Fully irreversible: Exposing a secret or credential (rotate immediately, but exposure already happened). Deleting data without a backup. Sending data to an external API that doesn't support deletion. Publishing confidential information publicly.

Use this as a starting reference, but always verify against the specific context. A "trivially reversible" action in one environment might not be reversible in another.

Edge Cases

  • "Reversible" with hidden costs. A git force-push is technically "reversible" via reflog, but collaborators may have already pulled the old history. Their local state is now out of sync, and fixing it requires coordination. A database migration is "reversible" with a down migration, but if the up migration already corrupted data, the down migration can't restore it. Always ask: reversible for whom? Just for me, or for everyone affected?

  • Time-sensitive reversibility. Some actions are reversible within a window. A deployed change can be rolled back before users notice -- but not after the damage hits their workflows. An email can be recalled within seconds on some platforms -- but only if the recipient hasn't opened it. A published package can be unpublished within a few hours on some registries -- but not after other packages depend on it. These time windows change the calculus significantly: if you can undo within 30 seconds, it's nearly as good as truly reversible. But the moment the window closes, it becomes fully irreversible. Know the window.

  • Cascading irreversibility. The Standish Group's CHAOS reports consistently show that projects fail most often when irreversible scope changes compound during execution stages (Standish Group, 2020). Step 1 might be reversible, but if step 2 depends on step 1 and is irreversible, the chain becomes irreversible at step 2. For example: creating a branch (reversible) and then merging it to main and triggering a CI/CD deploy (irreversible). Once the deploy happens, deleting the branch doesn't undo the deployment. Always trace the reversibility through the entire chain, not just the current step. The chain is only as reversible as its least reversible link.

  • Social irreversibility. Saying something incorrect in a public channel is technically deletable, but people may have already read it and formed opinions. Posting wrong data to a dashboard is technically correctable, but decisions may have already been made based on it. Giving bad advice is technically retractable, but the user may have already acted on it. The technical reversibility is irrelevant when the social or informational damage is already done.

  • Hidden irreversibility in seemingly safe actions. Some actions look reversible but aren't, in subtle ways. Overwriting a file destroys the previous version (unless version control is active). Running npm install might update a lockfile in ways that change behavior even if you remove the package later. Restarting a service clears its in-memory state and any unsaved work. Creating a user account might trigger a welcome email that can't be unsent. Always look for secondary effects that can't be undone even when the primary action can be.

Tips

  • Ask "what happens if I'm wrong?" before every significant action. This one question forces you to think about reversibility, cost, and consequences in a single moment. If the answer is "nothing much, I just undo it," proceed confidently. If the answer makes you uncomfortable, slow down and verify.
  • Build the habit of "draft first, finalize later." Make this your default operating mode. Write to a temp file before overwriting the original. Test on a branch before merging to main. Stage changes before committing. This habit costs almost nothing per-action and saves you from the worst mistakes over time.
  • Look for the undo path before you need it. Before you take an action, know how to reverse it. Can you git revert? Can you restore from backup? Can you delete the record? If you can't identify the undo path, that's a strong signal the action is irreversible -- or that the undo path is expensive enough to warrant treating it as such.
  • Be especially careful with actions that cross system boundaries. Actions within your local system are usually more reversible than actions that send data to external systems. A local file change is easy to revert. An API call to a third-party service might not be. A database change on your machine is local. A database change on a shared server affects everyone. When you cross a boundary, your ability to undo typically drops sharply.
  • Watch for the "just one more step" trap. You've done 5 reversible steps and now you're about to do 1 irreversible step. The momentum of the previous 5 steps makes the 6th feel routine. It isn't. Every irreversible step deserves its own careful evaluation, regardless of how smoothly everything went before it. Don't let procedural momentum carry you past a decision that deserves a pause.

Frequently Asked Questions

How do I determine if an action is reversible when I'm not sure? Trace the action's effects outward. What changes after you do it? Files on disk? Data in a database? Messages sent to people? State in an external system? Entries in a log? For each effect, ask: can I undo this specific change? If all effects are undoable, the action is reversible. If any single effect is not undoable, the action as a whole is irreversible -- because you can't fully undo it. When in doubt, ask the user or check documentation. And remember: if you truly can't determine reversibility, assume irreversible. That's always the safer assumption.

Should I always ask the user before irreversible actions? Almost always, yes. The rare exception is when the user has explicitly instructed you to proceed without confirmation (e.g., "go ahead and deploy, don't ask me"). But even then, if you notice something unexpected -- the deploy target is different than expected, the data is larger than anticipated, the action affects more systems than you assumed -- pause and confirm. The user's blanket permission was based on assumptions about what would happen. If those assumptions are wrong, they'd want to know before you proceed.

What about actions that are reversible in theory but expensive in practice? Treat them based on the practical cost, not the theoretical possibility. "We can restore from backup" is technically true, but if the restore takes 4 hours, causes downtime, and risks data loss for the delta between backup and failure, it's not meaningfully different from irreversible for purposes of how cautious you should be. The question isn't "can this be undone?" but "what does it cost to undo this?" If the cost is high, treat it with the same caution you'd give an irreversible action.

How do I handle a situation where I've already taken an irreversible action and realize it was wrong? Damage control, immediately. First, stop taking any further actions that might compound the problem -- don't try to "fix forward" in a panic. Second, assess the actual impact: what has changed, who is affected, how severe is it. Third, communicate clearly to the user: what happened, what the impact is, and what the options are for mitigation. Don't hide it, minimize it, or try to fix it silently. The user needs to know, and they need to know quickly. Fast, honest communication about mistakes builds more trust than trying to cover them up -- and it gives the user the opportunity to help with damage control while the window for mitigation is still open.

Does version control make everything reversible? It makes file changes reversible, which is enormously valuable -- it's one of the most important safety tools you have. But it doesn't make everything reversible. Running a script that sends emails: version control can revert the script, but not the emails. Modifying a database through application code: version control tracks the code change, but not the data change. Deploying code that crashes a service: version control can revert the code, but the downtime already happened and the users already noticed. Version control is a powerful safety net, but it only covers one dimension of reversibility. Don't confuse "the code is in git" with "everything is safe."

Sources

← Back to all articles
On this page