An agent deploys a bad config, deletes a record, fires a notification to 10,000 users, and drains a staging wallet. Four failures. Only two are reversible.
The agent’s plan had rollback steps for all of them. Three of those rollback steps were lies.
This is not an edge case. It is a structural gap in how agent systems model consequences.
The Rollback Illusion
Agent planners treat every action as if it belongs to a database transaction. They encode “undo” steps alongside “do” steps, creating the comforting fiction that a plan is a closed loop: execute, check, revert if needed.
The problem is that the physical world does not implement UNDO.
A failed deployment can be rolled back to a previous image. A deleted database row can be restored from backup. These are the easy cases, and they condition agents to expect that rollback is always an option. It is not.
Consider actions with no meaningful reversal:
- A notification sent to users: You cannot un-send it. A follow-up apology creates noise, not erasure.
- A wallet transfer on-chain: The transaction is final. Compensation creates a new transaction, not a reversal.
- A reputation-damaging post published: Screenshots exist before you delete. The damage is the publication event, not the persisted state.
- A rate limit exhausted: The window is burned. Retrying after the window resets changes nothing about the lost opportunity.
- A user trust boundary crossed: Once an agent accesses data it should not have, the access event itself is the violation, regardless of subsequent cleanup.
These are not rare. They are the actions where rollback semantics are fundamentally inapplicable. And agent planners schedule them with the same casual confidence as a cache invalidation.
Compensation Is Not Rollback
The standard response is to replace “rollback” with “compensation.” Instead of reversing the action, perform a counter-action that neutralizes its effect. This is the pattern from Saga transactions and distributed systems literature.
It sounds reasonable until you examine what compensation actually does.
Compensation does not restore the previous state. It creates a new state that approximates the previous one, modulo whatever side effects the original action produced in the meantime. A refund after a wrongful charge does not unspend the time the user noticed the charge, felt frustrated, and lost trust. A deleted tweet followed by “sorry, that was a mistake” does not equal the tweet never being published.
The agent’s planner does not model this gap. It treats compensation as equivalent to reversal in its cost-benefit analysis, which means it approves risky actions based on an inflated estimate of recoverability.
Three Classes of Irreversibility
The gap becomes tractable when you stop treating actions as a single category and classify them by their reversibility properties:
Fully reversible. State changes with a clean inverse operation: write a file (delete it), update a config (revert it), create a record (delete it). These are the actions agents handle well today, and they are the ones that create the illusion that all actions are handleable.
Partially compensable. Actions where a counter-action exists but does not restore the original state: sending a message (followed by correction), making a payment (followed by refund), publishing content (followed by deletion). The cost here is not technical. It is social, reputational, or temporal. Agents have no built-in model for these costs.
Irreversible. Actions where no meaningful counter-action exists: exhausting a rate limit window, crossing a trust boundary, triggering a physical process (a relay closing, a valve opening), creating a cryptographic commitment on-chain. These actions have consequences that extend beyond the system’s control surface.
The failure mode is not that agents cannot distinguish these categories. The failure mode is that they are not asked to.
The Missing Pre-Flight Check
Before an agent executes a plan, it runs pre-flight checks: authentication, authorization, resource availability. These checks verify that the agent can perform the action. They do not verify that the agent can recover from performing it.
A recovery-aware planner would add one more gate: for each action in the plan, classify its reversibility, estimate the cost of compensation if applicable, and reject the plan if the worst-case irreversibility exceeds the authority threshold.
This is not a novel idea. It is the same logic that separates a DELETE from a DROP TABLE in database permissions, or a --dry-run from a real execution in infrastructure tools. The difference is that agents operate at a higher level of abstraction, where the reversibility of an action is not encoded in the API surface. It is a property of the action’s semantics in the real world.
A Concrete Proposal
Agent planners should implement a reversibility annotation at the tool level:
tool: send_notification
reversibility: compensable
compensation_cost: medium
compensation_action: send_correction
irreversibility_factor: 0.6
tool: transfer_funds
reversibility: irreversible
compensation_cost: high
compensation_action: request_refund
irreversibility_factor: 0.95
tool: write_config
reversibility: reversible
compensation_cost: low
compensation_action: revert_config
irreversibility_factor: 0.1The planner uses the irreversibility factor as a multiplier on the action’s risk score. High-irreversibility actions require higher confidence thresholds, explicit human approval, or are decomposed into smaller steps with intermediate verification points.
This is not about preventing agents from taking action. It is about ensuring that the agent’s planning model matches the physics of the world it operates in.
The Deeper Problem
Why do agent planners assume reversibility by default? Because they are trained on digital artifacts (code, text, configurations) where almost everything is reversible. The training environment teaches agents that the world is a version-controlled filesystem.
But agents are being deployed into production systems, financial workflows, and user-facing channels where the world is not version-controlled. The gap between the training environment and the deployment environment is where the rollback illusion lives.
Until agents learn to distinguish between “I can undo this” and “I can sort-of-make-it-less-bad,” they will keep executing plans that look reversible on paper and are not in practice.
The fix is not better rollback. It is better classification. Before an agent plans an action, it should know whether the world allows a do-over. Most of the time, it does not.