How it works
Rollback restores a system to a state it held before an action ran. The mechanism has two halves: capture and restore. Before a mutating step, the harness records enough state to reconstruct the prior world — a snapshot, a versioned commit, a transaction boundary, or a compensating action registered against the change. After the step, a check decides whether to keep the result or revert it.
A workable rollback path looks like this:
- Capture a restore point before the mutation (snapshot, commit SHA, DB transaction, or a recorded inverse action).
- Execute the action inside a boundary you can abandon.
- Verify the result against a check — a test, an eval, a diff review, or a human gate.
- On failure, restore the captured state or run the compensating action.
- Confirm the system is actually back — re-read state, don't assume the restore worked.
Not every effect is reversible the same way. Filesystem and version-controlled changes revert cleanly. Database writes need transactions or compensating writes. External side effects — a sent email, a charged card, a posted webhook — cannot be un-sent; the best you get is a compensating action, not a true undo. Designing rollback means classifying each effect by how reversible it is before the agent touches it, and treating the irreversible ones with more care than the rest.
Why it matters in an agent harness
Agents act stochastically. A loop that mostly works still produces the occasional wrong tool call, bad edit, or confidently incorrect change. Rollback is what keeps that expected failure rate cheap. Without it, a single bad step is permanent; with it, a bad step is just a recoverable event.
Concretely, rollback:
- Bounds blast radius. The cost of a mistake is capped at "restore the checkpoint," not "clean up production by hand."
- Raises the autonomy ceiling safely. You can let an agent proceed without a human on every step precisely because a wrong step is reversible.
- Makes evals actionable. When a trajectory fails its check, you revert and retry instead of shipping the failure.
- Supports fan-out. Isolated worktrees or branches let parallel subagents work without colliding; you keep the winner and discard the losers.
Reversibility changes the risk math of delegation. The operating question shifts from "will the agent be right?" — which you can never fully guarantee — to "if it's wrong, can I get back?" — which you can engineer for. That second question has an answer you control.
Rollback vs Idempotency
These get conflated because both make retries safer, but they solve different problems and you usually want both.
| Rollback | Idempotency | |
|---|---|---|
| Question | How do I undo a change after it happened? | How do I make repeating a change safe? |
| Direction | Backward — restore prior state | Forward — same result on every retry |
| Requires | Captured state or a compensating action | A stable key and dedupe |
| Failure it prevents | Permanent damage from a bad step | Duplicate harm from a retry |
They compose. Idempotent actions make "retry after rollback" safe, and rollback gives idempotency somewhere clean to return to. Reach for idempotency when the risk is doing a thing twice; reach for rollback when the risk is doing the wrong thing once.
The Rifty take
We optimize for reversibility over raw autonomy. An agent should not take an action it cannot walk back unless a human explicitly authorized that specific irreversible step. The tradeoff we accept is real: capturing restore points costs storage, latency, and design work up front. We take it anyway, because a harness you can't rewind isn't a harness — it's a hope. Reversible-by-default is the boundary we enforce, and irreversible-by-exception is the only way past it.
Common failure modes
- Assuming a restore succeeded without re-reading state to confirm it.
- Treating external side effects (emails, charges, webhooks) as reversible when they actually need compensating actions.
- Snapshotting too little — restoring code but not the database, or files but not in-flight state — and landing in a world that is neither the before nor the after.
- Restore points that drift: the captured state no longer matches what the action assumed.
- No rollback budget — unbounded retries after failed reverts spin forever.
- Rolling back one agent's work while a parallel agent has already built on top of it.
Frequently asked questions
What's the difference between rollback and a checkpoint?
A checkpoint is the saved prior state; rollback is the act of restoring it. Checkpointing captures a restore point before a risky step, and rollback consumes that checkpoint to return the system to it. You need both: a checkpoint with no restore path is useless, and rollback with no captured state is impossible.
Can you roll back an irreversible action like a sent email or a payment?
Not truly — a sent email or a captured payment cannot be un-sent. The closest mechanism is a compensating action: a correction email, a refund, a reversing entry. When designing a harness, classify each side effect by reversibility, and gate the irreversible ones behind an approval so the agent cannot fire them unsupervised.
How does rollback let an agent run more autonomously?
Because a wrong step becomes recoverable instead of permanent. Autonomy is risky mainly when mistakes are irreversible; once you can restore the prior state cheaply, letting the agent proceed without a human on every action becomes a bounded bet. Reversibility, not model confidence, is what safely raises the autonomy ceiling.
What state should a rollback capture?
Capture enough to reconstruct every effect the action can touch. For code, a commit or worktree; for data, a transaction or snapshot; for external calls, a recorded inverse. The common failure is partial capture — reverting files but not the database, leaving the system in a state neither before nor after the change.