"Roll back the agent's action" is not one operation. It is four operations, each appropriate for a different tier of action. Treating all rollbacks as equal leads to over-engineered Tier 1 actions and under-engineered Tier 4 actions. The four-tier framework below classifies actions before they execute and treats each tier with the right operating model.

The framework is the runtime version of the reversibility classifier introduced in how to limit AI agent actions. The same classifier sits inside the pre-action gate that decides whether to execute, execute with compensation logged, execute with notify path, or pause for confirmation.

The reversibility spectrum

Reversibility is a spectrum, not a binary. At one end, actions cost nothing to reverse (rename a file, change a label). At the other end, actions cannot be reversed at any cost (delete a customer record from a system with no audit log). Most actions sit in the middle: reversal is possible but has cost, partial effect, or requires a third party.

The four tiers are checkpoints along this spectrum. The decision the agent (or the integration layer) makes is which tier each action falls into. The operational model differs by tier; conflating tiers produces either friction (treating Tier 1 like Tier 4) or risk (treating Tier 4 like Tier 1).

Tier 1: Trivially reversible

Tier 1 actions are operations on systems with native undo. Database writes with audit logs. File renames in a versioned filesystem. Label changes in an inbox. Draft creation. Calendar event creation in your own calendar.

The undo for Tier 1 is the inverse operation: revert the rename, remove the label, delete the draft. The cost is small (usually a single API call), the effect is complete (the world is back to pre-action state), and there are no third parties involved. Tier 1 actions can run unattended; rollback is fast and lossless when needed.

The agent's job for Tier 1 actions is to log enough information to apply the inverse operation: the prior value (for renames, the old name; for labels, the prior label set), the resource identifier (file path, message id), and the timestamp. The action log covered in how to monitor an AI agent is the natural home for this information.

Tier 2: Compensable

Tier 2 actions are write operations against external systems where the inverse exists but has cost. Bookings (cancel has fees). Charges (refunds clear in business days). Sent messages within retraction windows (Slack, some email systems). Order placements (cancellation may incur restocking fees).

The compensation pattern from the saga discussion in how to stop an AI agent mid-task is the right framing. Each Tier 2 action has a recorded inverse: book flight has cancel flight, charge card has refund card, send Slack message has retract message. The compensation is applied when rollback is needed.

Tier 2 compensations are not free. Cancellation fees, processing time, or partial effects (a retracted Slack message was already read by some recipients) are part of the cost. Rolling back Tier 2 actions is a real operation with real consequences; it is reversible but not without cost. Plan accordingly.

Four reversibility tiers, lowest to highest cost Tier 1: Trivial Renames, labels. Drafts, calendar. Undo: inverse op Cost: zero Run unattended Tier 2: Compensable Bookings, charges. Sends with retract. Undo: saga inverse Cost: fees, partial Run unattended Tier 3: Notify-only Sent customer email. Public posts. Undo: apology/edit Cost: trust + comms Allowlist required Tier 4: Irrev. Wire transfer. DELETE no audit. Undo: none Cost: permanent Human confirm Source: Aryan Agarwal, Gravity reversibility classifier, May 2026.
Each tier has a different operating model. Conflating tiers produces friction or risk.

Tier 3: Notify-only

Tier 3 actions are permanent but recoverable through a follow-up communication. A sent email cannot be unsent, but a correction or apology can be sent. A public post cannot be deleted in everyone's feed, but an edit or follow-up is possible. A customer charge that was correct in policy but wrong in execution can be refunded as a goodwill gesture.

The "rollback" for Tier 3 is the notify path: who to contact, what message to send, what process to follow. The notify path is recorded alongside the action, so when rollback is needed the operator (or another agent in a controlled context) can execute the corrective comms.

Tier 3 actions should sit behind the domain allowlist guardrail covered in how to give an AI agent email access safely. The allowlist plus the notify path together limit blast radius and provide a recovery mechanism.

Tier 4: Irreversible

Tier 4 actions are one-way doors. Wire transfers to external bank accounts. DELETE on a record in a system with no audit log. Posting to a public forum that has no edit feature. Sending a contract for signature.

The right operating model for Tier 4 is human confirmation, every time. The agent prepares the action, submits it to the gate, and waits. A human reviews and approves (or rejects) before the action executes. There is no "the agent has earned Tier 4 trust" graduation; the cost of getting one wrong is whatever the action's permanent effect is.

Some agents should never be allowed Tier 4 actions at all. A personal triage agent has no business with wire transfers. A sales triage agent has no business with contract signatures. The action allowlist (covered in how to limit AI agent actions) is the right place to exclude Tier 4 actions categorically.

The pre-action gate

The pre-action gate is what makes the four-tier framework operational. Without the gate, classification is documentation: a list of which actions belong to which tier with no enforcement at runtime.

The gate sits between the agent's decision and the tool's execution. For each action the agent intends to take, the gate looks up the tier from a configuration table. Tier 1 and 2 actions execute (with the appropriate inverse logged). Tier 3 actions execute with the notify path recorded. Tier 4 actions are paused, the operator is notified through whichever channel the system uses, and the agent waits for confirmation before proceeding.

The gate's configuration is part of the agent's deployment artifact. Updating which actions are at which tier is a deliberate operation, audited like any other production change. The gate is the difference between "we have a reversibility framework" and "our agent applies the reversibility framework."

Frequently asked questions

Can I always roll back an AI agent's action?

No. Some actions are trivially reversible (rename a file). Some are compensable (cancel an order, refund a charge). Some are notify-only (you can apologise but the email is sent). Some are irreversible (transfer money to an external bank account, delete a record from a system with no undo). The right framework classifies each tier and treats them differently.

What are the four tiers of AI agent action reversibility?

Tier 1: trivially reversible (database writes with undo logs). Tier 2: compensable via inverse action (cancel, refund, retract). Tier 3: notify-only (the action is permanent but a follow-up communication is possible). Tier 4: irreversible (no recovery; treat as one-way doors). Each tier has a different operating model.

Should an AI agent ever take Tier 4 irreversible actions?

Only with explicit human confirmation, even when the agent is otherwise running unattended. Tier 4 actions are one-way doors; the cost of getting one wrong is whatever the action's permanent effect is. The pattern is to gate every Tier 4 action behind a confirmation step that requires a human to approve, no exceptions.

How do compensating actions work for AI agents?

Each Tier 2 action has a recorded inverse that can be applied to undo the work. Book flight has cancel flight. Charge card has refund card. Send Slack message has retract Slack message (within the retraction window). When the agent's run is rolled back, the recorded compensations are applied in reverse order. Compensation is not free; some compensations have monetary cost (cancellation fees) or partial effects (a retracted message was already read).

What is a pre-action gate?

A pre-action gate is the runtime check that classifies each action by tier before execution. Tier 1 and 2 actions execute. Tier 3 actions execute with a recorded notify-on-error path. Tier 4 actions are paused, the operator is notified, and execution waits for confirmation. The gate is what makes the four-tier framework operational rather than aspirational.

Three takeaways before you close this tab

Sources