After the Agent Is Wrong: Reversibility Without a Rollback Layer

The question teams ask once agents resolve tickets, update CRM records and send customer emails is no longer how to detect a mistake. It is what happens after the mistake has already been executed. An agent decides a customer issue is resolved. It closes the ticket, updates the CRM, emails the customer and triggers a downstream workflow. Detection is the easy part. Someone still has to find every system the action touched, decide what the state was before, and put it back.

I went down the rollback road and came back. This page is what replaced it.

The action list already contains something nobody can reverse

The email is gone. You can send a correction, but the customer has read the first one, and no snapshot layer buys that back. The same is true of a payment released, an order confirmed to a supplier, a message posted into a channel with two hundred people in it. A rollback layer is designed for the three actions in the list that were reversible anyway, and it is silent about the one that was not.

That is the first split, and it is the one that matters: not by system, but by whether the action can be undone from inside the building.

Cross-system rollback assumes a previous state that never existed

The second reason the rollback road ends is quieter. Rollback across systems assumes there was a single previous state to restore. In practice the ticket board and the CRM already disagreed before the agent ever ran: the CRM said active, the latest ticket said blocked, and both were right about their own field. Restoring the previous state restores a disagreement, and now it carries a timestamp that says the agent did it.

What the team needs is not the old state. It is the record of what the agent changed, with the value it changed from, per field, per system.

The split that works

Reversible inside one system. A ticket status, a CRM field, a page section, a work item. These are written directly, and the record carries its previous value. The undo is one write, and it can be done by the person who owns the record, in the tool where they live.

Leaves the building or touches money. A customer email, a payment, an order, a public post. These never run as a side effect. They become a proposal that waits in one place for a person, posted as a card in the chat the team already uses, with the source passage and the exact content. The queue is boring, and it is the only reason the recovery afternoons stopped.

The rule for the split is not the tool and not the system. It is the answer to one question: if this was wrong, can a person put it back from inside our own systems in one write?

Compensation, never deletion

A confirmed action that turns out wrong is never deleted from the trail. It gets a compensating action with its own receipt, and both stay visible next to each other. An audit reads the decision, the mistake and the correction in one row group, which is the difference between a system that can be reviewed and one that has to be believed.

A refinement worth keeping, from a practitioner who reviewed this model: a denied action has two endings, not one. Either it was denied and verified clean, meaning nothing downstream ran, or it was denied but is unresolved, because a webhook fired before the denial landed. The third state is the one that needs an owner, and it needs a row of its own.

What a receipt has to hold

The receipt is the artifact everything above depends on. On every approved write it records:

• who approved, and when;
• the exact write, in the arguments that ran, not the summary the agent proposed;
• the record it landed in, with a link;
• the previous value, where one existed;
• the resolved customer, project or decision it was filed against;
• the source passage the proposal was built from.

With those six fields the undo of an in-system write is mechanical, the compensation of an external one is a documented decision, and the security review reads receipts instead of asking questions.

What changes for the team

The irreversible class becomes one queue instead of five tools. Approvals take seconds because the card carries the passage and the write. The reversible class keeps moving without a tap, with the previous value on every record. And the afternoon that used to go into reconstructing what the agent touched does not happen, because the trail already says so.