Rollback belongs in the plan

Teams often ask for a rollback plan immediately after something goes wrong. That is several hours too late.

Once an agent has deployed a broken change, deleted data, or sent a message, the system is already in a state the original plan did not cover. Any rollback invented at that point is a fresh production action, designed under pressure and aimed at a system that may still be moving.

Rollback belongs beside the proposed action, before approval and before apply.

“We can revert the commit” is not a plan

A commit can be reverted while its effects remain. A deployment may have run a database migration. A worker may have emitted jobs that are still queued. A configuration change may have altered traffic before the old version returns. Customers may already have received an email that cannot be unsent.

The plan has to describe the state transition as well as the file change.

Suppose an agent proposes a new billing rule. The forward plan says which code will deploy and which tests pass. A real rollback plan also asks whether invoices will be written under the new rule, how those records will be identified, and whether restoring the old code can interpret them. If the answer is “we will work that out if needed,” the system is not ready for unattended promotion.

For each consequential action, the agent should be able to state:

• the signal that will trigger a stop or reversal;
• the authority allowed to make that decision;
• the mechanism that restores a known state;
• the data or side effects that the mechanism cannot restore;
• the check that proves recovery actually happened.

This information changes the forward plan. A dangerous migration may become a staged dual-write. A broad release may become a small traffic slice. A public message may remain a draft until a person approves it. Rollback design is not administrative paperwork after engineering. It shapes safer engineering.

Some actions need compensation, not rollback

Not every effect is reversible. Sent messages, disclosed information, completed payments, and many physical actions cannot be returned to their previous state. Calling the response a rollback creates false confidence.

These workflows need a compensation plan. That could mean issuing a correcting message, creating an offsetting transaction, revoking access, or escalating to an incident owner. Compensation does not erase the original action. It limits further harm and establishes what happens next.

The distinction matters when assigning authority. An agent may be allowed to roll back a canary deployment automatically after a protected health check fails. It should not invent and send an apology to customers merely because a metric crossed a threshold. The second action carries new reputational and legal consequences.

Rollback itself can be unsafe

Returning to an older version is not always the lowest-risk move. The old binary may be incompatible with newly written data. A security fix may not be safe to remove. During an incident, repeated automatic reversals can make diagnosis harder and turn a small fault into oscillation.

A good plan can therefore choose to halt, isolate, or roll forward instead. The requirement is not “always revert.” The requirement is to decide the containment strategy while there is still time to test it.

That strategy should have limits. Set a retry budget. Name the state that counts as recovered. Record when automatic recovery must stop and hand control to a person. An agent that keeps applying and reverting because each local check looks plausible is not resilient. It is thrashing.

Plan the way back before the next change

Take the next agent action that can affect shared state. Before it runs, write the failure signal, containment mechanism, decision authority, and recovery check in the same proposal as the forward change. Test the mechanism against a staging state that resembles the one it would have to recover.

If an effect cannot be reversed, say so plainly and require a compensation path or a smaller initial action. Do not approve the forward plan until the way back, or the reason there is no way back, is visible.