Rollback means undoing a committed action: reverting the change, restoring the prior state. In git you get it for free. In a system-of-record you almost never do.

I think reversibility is the real axis of risk in agentic systems, more than scope or frequency. A write you can undo is a write you can learn from cheaply. A write you cannot undo is a bet. Most architectures treat all writes equally. They shouldn’t.

The honest catch: most real-world writes are only partially reversible. You can delete the calendar invite, but the customer already saw it. You can void the invoice, but the vendor already booked the revenue. The system state rolls back; the human state does not. And when the undo only goes part way, the audit-trail is the one record of what actually changed and what didn’t. Partial reversibility is better than none, and it still isn’t a license to skip the gate.

Reversibility spectrum: risk rises as rollback gets harder Horizontal axis from free rollback on the left through partial in the middle to irreversible on the right. Most real writes cluster in the wide partial zone. FREE PARTIAL IRREVERSIBLE git revert the invite the customer saw the invoice the vendor booked system-of-record write ← cheap to undo no undo →
Reversibility is the axis. Most real writes land in the messy middle, not at the clean ends.

That asymmetry is why the safety work moves before the action, not after it. If you cannot reliably undo, you check before you commit. The weight lands on the approval-gate, on knowing what you’re about to change and what it will cost if you’re wrong. Write access is hard for several stacked reasons, and the fiction of easy rollback is one of them.