Reversible by Whom?

A decision may be reversible for the company and irreversible for the people who trusted it.

Title card reading 'Reversible by Whom?' in green type on a cream circle, surrounded by organic blobs in terracotta, sage, dark green, and mustard

The usual test for a fast decision is whether you can undo it. If the answer is yes, make the call quickly. If the answer is no, slow down and gather more judgment.

That test is useful, but incomplete. It asks whether the organization can reverse the decision. It does not ask who absorbs the cost of reversing it.

A feature flag can be turned off. A customer who built a workflow around the feature still has to repair the workflow. A team can cancel a launch. A partner who hired people for the launch cannot get those weeks back. A database write can be rolled back. The person who received the wrong notification may already have acted on it.

One-Way Doors shows how delivery and downstream reliance make a decision irreversible. This post asks who pays when it is reversed anyway. A decision can be reversible for the company while remaining costly for everyone who acted on it.

A rollback leaves downstream commitments in place

Inside a company, a decision often looks like a clean switch: ship or unship, enable or disable, keep or remove. The system has a rollback button, so the decision gets classified as a two-way door.

But other people experience the consequences as a sequence of commitments. They learn the new behavior, change their process, tell a customer, reserve capacity, or make a promise. The rollback reverses the system state without reversing the time and trust spent responding to it.

That gap is where "reversible" becomes misleading. The technical state may be recoverable while the social state is not.

Reversibility has layers

Before an agent or a team treats a decision as safe to make quickly, it helps to separate at least four layers:

  1. System reversibility: can the code or configuration return to its previous state?
  2. Operational reversibility: can the team unwind the work without disrupting other work?
  3. Customer reversibility: can users recover without losing data, trust, or a useful workflow?
  4. Commitment reversibility: can promises, contracts, and expectations be withdrawn without lasting damage?

A decision is only as reversible as its least reversible important layer. A feature that can be switched off in seconds may still deserve careful review if customers will make durable choices based on it.

Not every decision needs a committee. The fast path needs to distinguish a clean rollback from a cost-free rollback.

Agents make the blind spot easier to scale

An autonomous agent is good at finding decisions that look reversible from inside the system. It sees the deploy, the flag, the configuration, and the documented rollback. It may not see the customer who was told the behavior was permanent or the team that reorganized its work around the new assumption.

That is why decision context matters before autonomy. The agent needs to know not only what action is available, but who is relying on the current state and what would happen if it changed again.

The useful question is "Can I undo this, and what remains changed afterward?"

The preview is part of the decision

For a consequential action, a useful preview should name more than the proposed mutation. As a proposal for a stronger review process, it could show the affected commitments: which customers, workflows, deadlines, or dependent decisions will become inconsistent if the action is reversed later. Dry Run describes the existing preview of what an agent would send; this is the additional context that preview could expose for consequential actions.

That preview gives a human a chance to notice a hidden one-way door before the agent walks through it. It also gives the agent a better boundary than a generic rule such as "ask for approval on irreversible actions."

Approval should attach to the cost of reversal, not just the presence of a rollback command.

The question to add to the checklist

When a decision looks like a two-way door, ask one more question: reversible for whom?

If the answer is "the system, but not the people depending on it," treat the decision as consequential. Record the dependencies, preview the effects, and give the people carrying the cost a chance to object before the fast path takes over.

Before taking the fast path, name who would carry the cost of undoing the decision.

Frequently asked questions

Does this make every decision a one-way door? No. It adds a second test to the technical rollback test. Many decisions remain cheap to reverse; the point is to notice when someone outside the system carries a durable cost.

Who decides whether a decision is reversible? The people accountable for the outcome should make that call with input from whoever owns the affected customer, operational, or contractual relationship. The person pressing the button rarely has the full view alone.

What should an agent do when reversibility is unclear? Surface the uncertainty and show the downstream commitments it found. Asking for a targeted review is more useful than silently treating ambiguity as permission to proceed.

Is a rollback plan enough? A rollback plan explains how to restore system state. It does not automatically restore trust, time, data, or expectations. Those costs need their own plan.

GET TLDR FROM:
← Back to Blog