Rollback strategies
Designing for the wrong action that got through: reversibility tiers, transactional multi-step actions, the kill switch, and the incident trail.
Validation and gates reduce wrong actions; they never reach zero. Mature agent engineering assumes a bad action will get through and asks: how fast can we detect it, and how completely can we undo it? Reversibility, designed in advance, is the difference between an incident and a catastrophe.
The reversibility tiers (classify every write tool)
- Reversible: ticket notes, status changes, internal flags. Undo is cheap; these can run auto with light review.
- Compensable: a refund (can be re-charged), an email (can be followed by a correction). Not truly undoable, but a compensating action limits damage. These deserve gates near the threshold and fast detection.
- Irreversible: account deletion, a sent legal notice, an external payment cleared. No undo exists. These are propose-only, full stop — the tier where prevention is the only strategy.
- Design principle: push actions down the tiers where you can. A 'soft delete' (reversible) instead of a hard delete; a queued outbound email with a 5-minute cancel window instead of an instant send. Engineering reversibility in is cheaper than any cleanup.
Multi-step actions and the transaction problem
Agents chain actions: refund the customer, update the ticket, send the reply. If step 2 fails after step 1 succeeded, you have a refund with no record and no notification — a partial-completion mess. Borrow from databases: either make the sequence transactional (all-or-nothing where your systems allow), or build compensation — a recorded plan of how to undo each completed step if a later one fails. At minimum, log each step's completion so a human can finish or reverse a half-done sequence. An agent that dies mid-sequence must leave a legible trail, not a mystery.
The kill switch and the incident trail
- A kill switch that actually stops actions. One flag that flips every write tool to refuse-and-log — so when something goes wrong at 2am, on-call can freeze the agent's hands without taking down the service. The read side can keep running; the dangerous side halts. Test it like a fire drill.
- The action log is your black box. Every action: what, when, which trajectory requested it, what the validator saw, approved-by-whom, and the result. When you must answer 'what did the agent do, and can we undo it?', this log is the entire answer — and it's the same audit discipline every product in this catalog ships.
- Rehearse the recovery. 'The agent issued 50 wrong refunds overnight' — walk it: kill switch, query the action log for the batch, run compensations, root-cause from the trajectories. A recovery plan you've never rehearsed is a hope, not a plan.
For every write tool, ask before shipping it: when this fires wrongly — not if — how do we detect it, and how do we undo it? If the honest answer is 'we can't undo it', that tool is propose-only or it doesn't ship. This one question, asked early, prevents the incidents the other lessons only mitigate.