An agent changes a customer record. Another workflow reads it and sends an email. A person then edits a different field. The agent’s authority is revoked, and the recovery tool restores the previous snapshot.
The agent’s original write is gone. The email remains delivered. The person’s legitimate edit is gone too. A successful database restore has produced an unsuccessful recovery.
This hypothetical is small enough to inspect, which is why I keep using it. Broad promises to “undo an agent” hide several different tasks: stop new effects, identify old effects, reverse the reversible ones, compensate for others, and preserve work that should not be undone.
A log does not define an inverse
An action log can tell us that a row was written. It may not tell us which later operations depended on the new value. It also does not supply an inverse for an external disclosure.
A useful recovery record needs effect identities, dependencies, preconditions, and the actual operations each service supports. A transaction might abort before commit. A queued notification might be cancellable until delivery. An issued payment may have a separate reversal procedure. An email recipient may already have acted on its contents.
Calling all these operations rollback obscures their semantics. A compensating action creates another event; it does not necessarily restore a world in which the original event never happened. This distinction matters when other actors have observed or relied on the intermediate state.
Preserve the human edit
Snapshot restoration assumes that the entire later state should disappear. In a shared system that is often wrong. Recovery needs to distinguish the agent’s changes from concurrent legitimate work and decide which dependencies require review.
Suppose the agent changes a shipping address and a person corrects the customer’s name. Restoring the whole row erases both. A field-aware repair could preserve the name, but a later operation might have used a combination of fields. The recovery boundary cannot always be inferred from storage granularity.
There may be no unique best repaired state. If the person’s edit relied on the agent’s mistaken address, preserving it mechanically may also be wrong. The system needs to surface ambiguity and ask for a decision rather than presenting a deterministic restore as a complete solution.
Separate revocation from repair
Revocation concerns what may happen next. Recovery concerns effects that already happened. A strong revocation barrier can limit the amount of repair required without making earlier effects reversible.
The proposed control-plane work should report these separately. A system might prevent every post-revocation commit yet leave an important earlier disclosure unrecoverable. Another might repair local writes well while allowing a delegated worker to continue creating new ones.
A single “safe shutdown” rate would conceal both failure modes. The supported services and their commit points need to be explicit so that the guarantee has a boundary a test can cross.
Test a world with another actor in it
A recovery benchmark should insert revocation at different workflow points and introduce concurrent human edits. Score the final database, queued work, external effects, and preserved legitimate changes. Include cases that require human resolution and cases that have no supported inverse.
The benchmark should also charge for overblocking. Freezing every service can prevent further damage while destroying the utility of selective control. Recovery time and the amount of unrelated work interrupted belong beside the repair success rate.
This remains a proposed evaluation, not a claim that I can reverse arbitrary agent effects. The goal is to find a useful region where actions carry enough structure to make recovery reliable, and to mark the edge where the world has already moved beyond what the system can undo.