Reverting safely

By the end, you can

• Distinguish what "revert" means for a file or workspace change, a sent message, and an external action already taken, and identify which of the three genuinely admits a full revert (LA-5).
• Choose between rollback and revision for a given run, and explain why Module 1's authority boundaries, Module 3's dedicated workspace and Module 4's captured diffs are what make a clean rollback possible in the first place (LA-5).

Before you start

This is Module 5, Lesson 1 — the start of the last module in the Local AI Agents course. It assumes Module 4 Lesson 3's disposition decision (accept, revise or roll back) and, further back, Module 1's authority boundaries and Module 3's dedicated, disposable workspace. This lesson does not re-decide disposition — it picks up once "roll back" has already been chosen, and asks a question that decision alone does not answer: revert what, exactly, and is that actually possible?

"Revert" means something different for a file, a sent message and an action already taken

Rollback is often talked about as one thing. It is really three different situations, and only one of them behaves the way "undo" suggests.

Google's Site Reliability Engineering practice frames rollback, for the reversible category, as a planned strategy rather than an emergency improvisation: release engineers and SREs "work together to develop strategies for canarying changes, pushing out new releases without interrupting services, and rolling back features that demonstrate problems." Rollback sits alongside canarying and staged rollout as one of several strategies decided on in advance — not a thing invented after something has already gone wrong.

• A file or workspace change is reversible if a prior state was preserved. Reverting means restoring that prior state — not a vague sense of "putting it back," but the literal earlier content, recoverable because something kept a copy of it.
• A sent message or published content is not reversible in the same sense. Deleting or retracting it is a mitigation, not a true undo — a recipient may already have read it, acted on it, or forwarded it before the retraction happens. The action's effect on another person's knowledge or decisions cannot be pulled back the way a file's content can.
• An external action — an API call that changed another system, a payment, a comment posted to a shared record, a third-party service updated — is the category most likely to be only partially reversible or not reversible at all. Undoing it, if possible, usually needs a second, different action (a compensating action), and that second action needs the same scrutiny the first one should have had.

Rollback is possible because of decisions made earlier, not because of luck

A clean rollback does not happen by chance. It happens because something earlier in the process made it possible, and two things this course has already covered do exactly that.

Module 1's authority boundaries decide, before a run starts, which actions an agent may take automatically and which need a person's approval first. An action classified approval-required gets a pause before it happens — Anthropic's engineering guidance describes this directly: "Agents can then pause for human feedback at checkpoints or when encountering blockers." That pause is what catches a problem before it becomes the kind of action Lesson 1's second category describes — a sent message, an external change — that no rollback can cleanly undo. The boundary decision is what makes prevention possible; rollback is what happens when a reversible action still needs fixing.

Two other earlier decisions do the equivalent work for the first category, file changes: Module 3's dedicated, disposable workspace preserves the prior state, and Module 4's captured diff records exactly what changed against that state. The Site Reliability Workbook makes a directly transferable point about why a smaller, tightly scoped change is easier to walk back: "Smaller, self-contained release artifacts make it cheaper and easier to roll back any given release artifact in the event of a bug." A bounded local task, scoped to one named file inside Module 3's disposable workspace, with its diff captured as it happens per Module 4's evidence discipline, is cheap to roll back for the same reason a small release artifact is — the scoping and capture decisions were made before and during the run, not improvised once something looked wrong.

Choosing rollback vs revision

Module 4 Lesson 3 introduced the accept / revise / roll-back split. Once roll back has been chosen as the right disposition, a further choice remains: does rolling back mean restoring the prior state entirely, or is the actual defect narrow enough that a targeted revision is the safer, more proportionate move? Two questions decide it:

For the second category from Lesson 1 — an action already taken outside the workspace, like a sent message — a true rollback is not available at all. Once that has happened, the honest response is a correction plus an accurate record of what occurred, not a claim that the action was "rolled back." What belongs in that record is the next lesson's subject.

• Is the specific defect in the current change unsafe or wrong to leave live, or is it a narrow, addressable gap sitting inside an otherwise sound change? A defect that threatens correctness or safety broadly across the change points toward rollback. A narrow, nameable gap — one wrong entry among many correct ones, one config value that needs adjusting — points toward revision instead.
• Is a clean prior state actually available to revert to? A rollback is only a rollback if there is a real prior state to restore — preserved by Module 3's workspace design, with Module 4's captured diff recording exactly what changed against it. Without that, "roll back" is not an option, whatever the defect looks like.

A worked example: a config rollback and a notification that cannot be unsent

A local agent's task was to update one value in a feature-flag configuration file and, once the change was live, to post a notification in the team's status channel confirming the flag was enabled. Posting the notification was classified approval-required in advance, per Module 1, so a person reviewed and sent it themselves after seeing the config diff.

Shortly after, the new flag value caused an error. Rolling back the config file is straightforward: Module 3's disposable workspace preserved the prior value, and the diff captured at the time of the change, per Module 4's evidence discipline, shows exactly what to restore. The config is reverted, and the diff confirms the restoration matches the prior state exactly — a clean rollback of the first category from this lesson.

The notification is different. It was already read by the channel before the error was found. Deleting it does not undo that people saw it and, in this case, one teammate had already referenced it in a separate message. The correct response is a follow-up message correcting the record — not a silent edit, and not a claim that the earlier notification was "rolled back," because it was not: it was corrected after the fact, which is a different and weaker thing.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Site Reliability Engineering, Chapter 8: Release Engineering — Google SRE Book. Names rolling back a change as one of the coordinated release strategies a team plans for in advance — rollback as a designed part of the release process, not an improvised response to trouble.
2. Canarying Releases — Google - The Site Reliability Workbook. States that smaller, self-contained release artifacts are cheaper and easier to roll back — the same discipline this lesson builds from Module 3's tightly scoped workspace and Module 4's captured diffs, applied to a single bounded task.
3. Building effective agents — Anthropic Engineering. Describes agents pausing for human feedback at checkpoints — the same authority-boundary habit this lesson applies to catching a problem before an action becomes irreversible.
4. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Recommends human-in-the-loop approval before high-impact actions — the safeguard for the category of action a rollback cannot undo after the fact.