How to Undo What an Agent Did — Four Rollback Strategies and Their Limits

If an agent does anything in production, that anything must be undoable. This is the most-frequently-missed requirement of AI agent adoption. It looks like ctrl+z. Undoing actions in production is actually four small automation patterns plus separate scenarios where each fails.

This post is the four-strategy combination we settled on over six months and where each one breaks.

Strategy 1 — inverse-action queue

The simplest. Right after every action, the agent records its inverse in a queue. Rollback executes the queue in reverse.

Agent action                   → Queued inverse
─────────────────────────────┼──────────────────────────
Deploy v2.4.7 to staging      → Deploy v2.4.6 to staging
Update flag enable_x = true   → Update flag enable_x = false
Restart service api-1         → (none — restart is idempotent)

Where it fails — one action is the input of another. If v2.4.7 ran a DB migration on deploy, rolling back the deploy to v2.4.6 leaves the DB mismatched.

Strategy 2 — snapshot-based

Right before the agent acts, take a system-state snapshot. Rollback = restore the snapshot.

VM snapshots, DB point-in-time recovery, k8s deployment revision history all fit this pattern.

Where it fails — external side effects after the snapshot. If the agent called an external payment API, the system rewinds but the payment itself happened. External effects need a separate compensation procedure.

Strategy 3 — forward correction

Instead of rolling back, ship a new forward action to correct. Sent the wrong alert? Send a correction alert. Bad deploy? Fix-forward deploy.

This is the most common rollback shape in production. Many real actions are literally not undoable.

Where it fails — time-sensitive actions. If you sent an alert 15 minutes ago, the correction alert has different effect. People who saw the original have already acted on it.

Strategy 4 — shrink the blast radius (avoid rolling back)

The most important strategy is avoiding rollback altogether. Before the agent does something big, do something small and bound the impact.

Examples:

• No direct production deploy — always canary 5% → verify → 25% → 100%
• Throttle external API calls — one at a time, verify, then next
• DB changes split into two phases — additive schema add, later start using the new column

This strategy's limit — agent action speed drops. What a human did in one go, the agent does in five steps, taking 5× longer. ROI is conditional.

The combination we use

We combine all four:

Agent action type                   | Primary strategy
────────────────────────────────────┼─────────────────────────────────
Config / flag change                | 1. Inverse queue (simplest)
Deploy                              | 4. Blast radius (canary) + 1. Inverse queue
DB schema change                    | 4. Blast radius (additive only)
External API call                   | 3. Forward correction (no rollback)
Bulk change (100+ rows)             | 2. Snapshot + 4. blast radius

This is the combination we settled on after six months. Initially we thought strategy 1 alone was sufficient. The first DB migration incident corrected us.

The limit — actions that can't be undone

Some actions no strategy can undo:

1. External notification (email, SMS, payment confirmation)
2. Physical device control (smart factory, IoT)
3. Time-dependent decisions (invalidating an older time-bound token)
4. Effects on external systems (third-party triggers)

These don't go to the agent. Humans trigger explicitly. In our authority model, they're a separate category. (→ Can agents hold production deploy authority)

Inverse queue, snapshot, forward correction, blast-radius reduction — when granting a production agent authority, which of these four rollback strategies applies should be an explicit condition of the grant. That's what makes incident recoverability predictable.

If you're deciding the authority boundary for a production agent right now, start with that mapping. Granting authority without a strategy equals incident, which equals permanent authority revocation.