Rolling Back What an Agent Did: Deciding What Must Be Reversible

The question to ask about any AI agent action is not whether the agent is good at it. It is what happens when it is wrong. Rolling back what an agent did is easy for some actions, expensive for others and impossible for a few, and the sensible way to design an agent workflow is to sort every action into those three groups before you switch anything on.

The rule that falls out of the sorting: reversible actions can run with a light touch, expensive ones need a person who checks properly, and permanent ones need two people or no agent at all.

Group one: reversible

An action is reversible if one person can undo it in a few minutes and nothing outside the team saw it in the meantime.

Editing an internal draft. Reordering a backlog. Adding a comment. Tagging items. Producing a summary that lives in a document. Creating a task that can be deleted. Flagging a risk that turns out not to be one.

These are where agents earn their keep. A wrong output costs a few minutes of annoyance. You can run these with a person approving in the ordinary way, and you can accept a lower hit rate because the cost of a miss is small.

One caveat: reversible actions stop being reversible when they pile up. An agent that renames two thousand records is technically doing a reversible thing two thousand times, and undoing that is a project. Volume changes the category.

Group two: expensive to reverse

These can be undone, but undoing them costs money, time or credibility.

Sending an internal message that a hundred people read. Changing a due date that other teams have planned around. Updating a record that downstream systems have already copied. Assigning work in a way that changes what somebody did with their day. Publishing to an internal site.

The undo exists but the effect does not disappear. You cannot unsend the confusion.

Rules that work for this group:

• One named person approves, and the approval is a real read rather than a click
• The agent must show what it used and what it was unsure about
• The action is logged with the approver's name, which is the point of keeping a record of who approved what
• There is a documented way to reverse it, tested at least once

That last point is the one teams skip. If nobody has ever run the rollback, you do not have a rollback. You have a plan for one.

Group three: permanent

Some actions cannot be walked back at all, or can only be walked back by admitting a mistake to someone outside the organisation.

Anything that reaches a customer. Anything with a price attached. Deleting records. Closing an account. Anything touching somebody's pay, their leave balance or their employment. Anything reported to an outside body.

For this group the position should be blunt. Either two people approve, or no agent goes near it.

Two people is not bureaucracy for its own sake. The value of a second approver is that they were not the one who read the draft first and started nodding. Make them independent: the second person should not be the one who set up the workflow.

How to do the sorting

Sit down with the person who does the work and list every action the agent could take. For each one, answer three questions.

• Can one person undo this in under ten minutes
• Did anyone outside the team see the effect before it was undone
• If we did this wrong a hundred times, how bad is that

The third question moves more actions into group two than people expect. Small actions at scale become large ones.

Write the result down as a table with three columns and keep it where the workflow owner can find it. Review it whenever the agent's scope changes, because scope creeps quietly, and fold it into a quarterly audit you can run without a consultant.

Building for rollback rather than hoping

A few things make reversal practical rather than theoretical.

Keep a log of what the agent did, not just what it produced. You cannot reverse what you cannot identify, and reading that work log is a short Monday morning job.

Make the agent's changes identifiable, so you can find everything it touched in a given window rather than hunting record by record.

Prefer actions that add over actions that replace. An agent that adds a suggested date next to the existing one leaves you with both. An agent that overwrites the date leaves you with a guess.

Practise the rollback once, in a quiet week, on a real workflow. The first time you do it should not be the day it matters.

The uncomfortable conclusion

Do the sorting honestly and you will usually find that the actions you most wanted to automate sit in group three. That is not a reason to weaken the rule. It is a reason to automate the preparation and keep the decision.

An agent that gets a permanent action ninety nine times right and once catastrophically wrong has not saved you anything. Systems built so a human approves output before it ships, SicherOne among them, are designed around exactly this, and the design only works if you are honest about which group each action belongs to.