L4.05.2executed steps must be reversibledesignresearch

Steps already executed must be rollable back

Aliases: agent rollback · compensating actions · undo executed steps

What it is

Abort blocks future steps; steps that already crossed a world boundary need a separate way back. Executed steps must be reversible requires the agent to keep a compensating action for each kind of act it has performed — unsend, restore a file, close a permission it just opened — and for a person to be able to fire that compensation, without defusing each system by hand.

After a stop the world still sits in its changed shape, and only stops changing further. That is not rollback.

Why it happens

A long task strings reversible and irreversible acts together. When a person aborts, they usually do not want the whole chain kept, nor the whole chain erased: the first two steps may be right and the drift starts at the third. Rollback has to be addressable by step, not one “undo the task.” If automation only stored “task succeeded / failed” and not an inverse per step, the person is left doing archaeology on the outside world.

Irreversible acts have no technical inverse; rollback fails there and they must be gated by confirm before they run — that is another entry’s work. This one treats steps that could still be reversed, which the product forgot to offer a reverse for.

Studying it

A task with several reversible steps (draft, tag, local file edit) and at least one irreversible (outbound send). After abort, offer: no rollback, whole-task rollback, per-step rollback. Dependent variables: whether people can reverse only the wrong steps, how often a correct step is reversed by mistake, whether rollback actually takes effect in the external system. Independent variables: whether steps have inverse records, granularity of rollback, how irreversible steps are marked.

External effect must be checked in the real system (test inbox, test disk), not only a product badge that says “undone.”

Where it stops holding

Steps never executed have nothing to roll back. What kind of intermediate the world sits in after a partial, and whether a person must clean it, is a state-explicitness question. Outward acts that are socially irreversible can only become apology and correction; do not pretend that equals never happened. Being able to stop at any time is not already having rolled back.

Applying it

  • For every world-changing tool call, implement the inverse at the same time, and bind that inverse to the step’s identity.
  • After abort, give a per-step rollback list, with a default selection of reversible steps before the abort point that the person has not confirmed they want to keep. Mark irreversible steps as “cannot reverse”; do not ship a fake button.
  • Check: let the agent change three local objects and send one test mail, abort mid-way, roll back only the second object. The second must revert, the first and third must remain, the test mail must still be marked irreversible. If the product badge and the external system disagree, rollback is fake.

Related

  • Same group: L4.05.1 Long tasks must be stoppable at any time · L4.05.3 A partially completed state must be made explicit
  • Nearby: L4.07 Pre-action Confirmation · L4.11 Pre-action Confirmation and Irreversible Operations · L4.13 Agent Failure Reporting and Escalation
  • Search terms: rollback · compensating action · undo

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L4.05.2