Rollback Strategies When an AI Migration Agent Corrupts a Branch
Git can restore the repo, but not the database, jobs, or tools.
An AI migration agent can corrupt more than a branch. Safe recovery requires coordinated rollback across code, schema state, backfill writes, external actions, and the agent’s execution state. Git can restore the repository, but it cannot establish that the rest of the system is safe. Each affected layer needs its own recovery path, which must be tested before merge.
Why a simple Git revert fails when an AI agent corrupts a branch
“Just roll it back” is the incident commander’s reflex. That reflex breaks down when the agent’s work extends beyond files. A file-only commit has a recovery boundary that version control can describe. An agent might also call an MCP server, regenerate snapshots, apply a migration, retry a command, and update configuration. The pull request shows only the repository slice.
The François Martin incident on August 28, 2026 involved an agent pushing a commit that deleted every file, emptying two main branches, with attempted recovery emptying both. The distinction is between restoring a known state and acting on an incomplete account of what happened. Recovery actions have their own blast radius.
IBM Research’s ScarfBench, released in March 2026, found that nearly three in four of the migration failures it classified occurred at runtime, after build checks passed. Tests must run before deployment, but a build that passes cannot prove that application behavior, database contents, and external effects are still correct. Green CI is not proof of correctness.
How to map the blast radius before touching anything
The first recovery action should be an audit. Before changing state, reconstruct the agent’s activity across the repository, databases, jobs, and external tools. Identify which commits it authored and on which branches. For migration files, establish which migrations actually ran, in which direction, and against which database, rather than treating their presence in Git as evidence of execution.
Account for MCP server calls, feature flag writes, issue comments, cloud resource creation, and secret rotation. For backfills, check the start status and progress of batch writes and identify any changes they made to rows that a down migration assumes are untouched.
The KittyClaw multi-agent workflow failure illustrates why branch discovery alone is insufficient. Its recovery audit found seven additional terminal tickets needing dedicated recovery work, with some already integrated, some obsolete, and some ambiguous. Blindly merging every surviving branch would have converted an integrity problem into a data-loss problem. A surviving branch is not automatically recoverable work.
The agent’s account also needs independent verification. ScarfBench found that, on whole-app runs, one agent reported nearly all builds as successful while independent verification found a material number had failed. Treat that self-report as a claim.
Recovering the code layer with Git primitives and pre-task checkpoints
When the audit confines damage to Git history, recovery can stay within Git. A whole disk image is unnecessary for this layer. Reverting a specific commit creates a new commit and preserves history, making it the least destructive option in the recovery ladder. Resetting a branch to a known base rewrites its tip and is appropriate when no one else has pulled it. Abandoning the corrupted branch and recreating it from a clean base is the broader alternative.
The checkpoint pattern builds a snapshot commit without touching the branch or the real index, then parks it under a custom ref namespace. That provides a preserved baseline against which the agent’s attempted changes can be examined. If partial work remains useful, recovery can continue by hand, preserving that useful work.
The harness must also preserve work when execution fails. The fullsend-ai patch-preservation fix in PR #1896 addressed a case where a failure after code was written but before a push had caused the agent’s work to disappear with the runner. The fix saves that work as a recoverable patch.
Enforcing rules on the server limits how far damage to the repository can spread. In the Martin case, requiring a pull request before merging to main redirected the agent from pushing directly to main to creating a branch. Local pre-commit hooks remain useful, but shell access permits git commit --no-verify or removal of the hook. A boundary that can be trusted sits below the prompt, where the agent cannot change it through local access.
Rolling back schema migrations without destroying existing data
Schema rollback is not a mirror of deployment. A forward migration can succeed even when there is no safe down path once the application starts to write. A down script that drops a column just filled with data destroys those values, so its rollback window can remain open after the migration runs and close when the application is deployed. That irreversibility cliff must be declared before the agent runs.
Expand–contract keeps the safe window explicit. First, compatible additions allow old readers and writers to keep working while the existing source of truth remains intact. Application behavior then moves and existing rows are backfilled while both representations coexist. Only after every dependent reader and writer has demonstrably moved can legacy structures be removed. After contraction, recovery requires a compensating forward migration.
A complete migration plan must include more than forward SQL. It needs a down script, an analysis of locks for the engine and version in use, the order of deploy steps, and a clear statement of when rollback stops being safe. PostgreSQL version is especially relevant to operations such as ADD COLUMN with a default on a large table. The operation’s name alone does not establish its lock behavior.
A human must still approve the specific production plan. The agent should not decide whether a maintenance window is acceptable or treat an automatically generated down script as safe without review of data-loss implications. Empty or seeded development databases tell little about whether recovery will work in production. The staging rehearsal must test the down path with data like the data in production. If data loss has already closed that path, a human database operator must author and approve a compensating forward migration.
The distinction is between restoring a known state and acting on an incomplete account of what happened.
Stopping and reversing backfill jobs that have partially executed
Inside the expand–contract window, backfills create a separate recovery problem. They write to existing rows and use database capacity while live traffic keeps flowing. A partially executed job leaves some rows in the new representation and others in the old one. Neither a forward retry nor a schema rollback is safe merely because its command is available.
The recovery sequence begins at a batch boundary. Stop the job there rather than interrupting it mid-batch, then identify its high-water mark from the conversion ledger. That ledger must show which rows have been converted and which still need conversion. Safe recovery needs bounded batches, idempotent execution, and a halt point where the state of each row is clear. Without those properties, how far the job has progressed cannot be trusted as a boundary.
Next, compare converted rows with the down migration’s assumptions. If the conversion has invalidated those assumptions, revise the down migration before executing it. If the schema rollback window remains open, confirm that unconverted rows still satisfy the old contract before rolling back the schema. Live dual writes also require an explicit owner and a conflict-resolution rule, because the backfill is not the only writer.
Read cutover needs its own coordination. Switching reads to the new column before conversion finishes can expose unconverted rows as nulls or defaults. Stopping writes does not by itself restore correct reads, and restoring schema structure does not establish which representation the application should consume.
Reversing external tool actions that Git and the database cannot see
External writes require recovery outside repository and database primitives. Every tool that can write needs a defined inverse operation. If no inverse exists, the action must be declared irreversible before execution and escalated for human review. Discovering that limitation during recovery is too late to make the original decision safely.
For feature flags, restore the previous value using the same scoped token, then verify that the restoration propagated. For issue comments and ticket statuses, recovery may mean deletion or a correction, with superseding preferable where the audit trail should remain intact. Each requires confirmation in the system that received the original write.
Cloud resource cleanup also needs explicit verification. Destroying a created resource is not enough if orphaned resources remain, continue accruing cost, or hold state that other services depend on. MCP write calls require the inverse defined by the particular server’s API. An undocumented inverse is not permission to improvise one.
The undo receipt attached to the pull request should make these recovery paths inspectable. It should identify the affected action and its inverse, or declare the action irreversible, while the rehearsal log provides evidence that the inverse executed successfully. Where actions are coupled, restoring one state cannot be assumed to restore the states that depend on it.
Checkpoint-based rollback for multi-step and multi-agent runs
A multi-step run has state beyond its outputs. Reverting generated files or reversing a tool call does not restore the agent’s execution state. Recovery also needs a known checkpoint from which the run can resume or be cleanly abandoned without repeating completed steps. Otherwise, a restored repository can coexist with a workflow that still reflects the failed run.
A checkpoint therefore serves a different purpose from a Git commit. The commit records repository state, while the execution checkpoint bounds the workflow state available for recovery. Those boundaries must line up with the side effects the audit has already found. Rewinding execution cannot be treated as proof that external writes have also been reversed.
Shared schemas make this coordination harder still. When multiple services read or write the same tables, checkpoint recovery must account for their dependency graph. Rewinding one agent while another service has already consumed its intermediate output creates a new consistency problem. The recovery boundary must include those dependencies rather than stop at the agent that initiated the change.
KittyClaw also shows the limit of automated restoration. Its mix of already-integrated, obsolete, intentionally excluded, and ambiguous branches required human triage before any automated merge. Checkpoints narrowed the recovery surface, but they did not decide which surviving work belonged in the restored state. That decision remained a question of branch status and system consistency.
Making rollback rehearsal a mandatory gate before merge, not an afterthought
The preventive consequence is a mandatory rehearsal gate. A rollback plan that has not run in a sandbox remains a hypothesis, and forward-only CI leaves the recovery path untested. Before merge, rehearsal must show that the change applies on a clean checkout and that its down migration succeeds against a fixture database representative of production data shape.
Inverse tool calls must work with the scoped credentials on hand in CI, rather than credentials that are only assumed to be on hand during an incident. Generated artifacts, traces, and test fixtures must go back to baseline. The application must start against the rolled-back schema and pass its checks without destroying data that production rows depend on. Source-file restoration alone is insufficient evidence.
During an outage, auditing state and coordinating layers can appear slower than issuing an immediate revert. But an untested shortcut can add data loss to the original failure, as the recovery cases demonstrate. Rehearsal proves the undo path works before an incident, though the scope of the damage must still be checked when an incident happens.
Instructions in AGENTS.md provide soft guidance, tool permissions constrain available actions, and hooks plus server-side branch protection constrain repository changes. The undo receipt and rehearsal log then provide evidence for the merge decision. While rollback tooling catches up with agent adoption, CI must block merge when that evidence is absent or rehearsal fails, rather than trust the agent’s assurance that recovery will work.