How do we roll back an agent's change?

Data Workers writes down the undo before it changes anything (the rollback SQL for a migration, the previous pipeline version in git, the step that removes a backfill's records, the original warehouse size) and lands every change through your normal tools. If a step of a fix fails, it rolls back the operation it recorded and hands the incident to a person. A backfill starts through your orchestrator, its quality assertions are re-checked after the run, and a failure goes to a named person, who runs the recorded undo if it is needed. If any fix completes but your quality and contract checks still fail, it escalates to a person, who can roll the change back from Spellbook.

The undo is never improvised after something breaks. It is scoped to that one change, and the warehouse's own history (Snowflake Time Travel, Delta RESTORE, BigQuery time travel) stays behind it as a second line.

Key takeaways

• •The undo comes first. Data Workers' rule is a pre-validated rollback plan for every production-modifying action, and actions that cannot be reversed are flagged before they run.
• •Rollback is scoped to the change. A migration runs its own rollback SQL; a backfill's recorded undo removes only the records it wrote, and the owner runs it. Everyone else's good writes stay.
• •Failures go to a person with the undo in hand. Every playbook carries rollback steps written before it runs. A backfill whose quality checks fail, or a fix whose checks still fail after its retries, goes to a named person.
• •L3 is the reversible level by definition. At L3 act reversibly, only changes with a recorded undo run without waiting; at L2 propose, everything waits for a named approver.
• •Every rollback leaves a receipt in the same tamper-evident hash chain as the change.

How rollback works in Data Workers

This is how the Autonomous Data-Conductor and the agents behind it handle an undo.

1. The rollback path is recorded before the change. When the remediate tool runs a fix, it records the operation for rollback before the first step executes, so the undo exists even if the run dies halfway.

2. Each kind of change carries its own inverse.

One schema case needs the second line: when a column was dropped, its rollback SQL re-adds the column with its old type, and the values come back from the warehouse's history.

3. The change lands through your tools. Pipeline changes become commits in your repo and backfills start as tasks in your orchestrator, such as an Airflow DAG run, so your reviews, CI and history apply to agent changes too.

4. Failed steps and failed checks go to a person. Every playbook declares pre-checks (source reachable, target writable), ordered steps, rollback steps and post-checks. If a step fails, remediate rolls back the operation it recorded and the incident escalates to a person. A backfill works the same way up to the undo: Data Workers starts it through the orchestrator, reads its status, re-checks the quality assertions and escalates a failure to a named person, who runs the recorded undo (remove the backfilled records) if it is needed. After a fix, Data Workers re-validates the affected assets against their data-quality and contract assertions, tries alternate playbooks within an attempt budget, and if assertions still fail, escalates to a person with the failing checks named.

5. Changes that span systems unwind in reverse order. A fix that touches Snowflake, then dbt, then Airflow runs as a saga: each step carries its compensation, and on failure the applied steps are undone last-in, first-out.

6. The warehouse's own history is the second line. On Databricks, Data Workers' Delta recovery skill reads DESCRIBE HISTORY, inspects the candidate version read-only, then picks a surgical re-insert when good writes landed after the bad one, or RESTORE TABLE when the whole table is bad, and refuses a VACUUM that would cut into the recovery window. The Iceberg skill holds snapshot expiry until the rollback window is confirmed, and the BigQuery storage skill keeps the full seven-day window where point-in-time recovery matters.

7. A person can roll back at any time. Spellbook (in preview) is one inbox where you approve, steer, send back or roll back a change, with the full trace of what the agent saw. Every tool call, the undo included, is written to the SHA-256 hash-chain audit log, readable through get_audit_trail.

Where rollback sits on the autonomy ladder

Rollback is what makes L3 possible. The live Conductor page defines L3 as "Act, reversible: acts on reversible changes". A domain at L3 lets Data Workers run changes that carry a recorded undo without waiting for a person, because the undo is written before the change runs and a failure goes straight to a named person. A domain at L2 propose gets the same rollback plan attached to the proposal, and nothing lands until a named person approves it; an approval nobody answers expires and escalates instead of granting itself.

Data Workers classes every tool by consequence: reversible enrichment, authoritative assertions, compensable changes to the live stack, and the most severe class of irreversible changes, elevated access, spend and deletes. Set that class to always need a person, at every level, and Data Workers enforces the rule. Autonomy levels L0 to L4 explained covers when a domain moves up, and how approvals work for AI data agents walks through the queue.

One worked example: a backfill that fails validation

This is an illustration, not a customer case. On Tuesday at 03:40 the Fivetran Shopify connector resumes after a source outage, and part of Monday's orders arrive late. By 03:58, Monday's partition in Snowflake raw.shopify_orders sits 38% under its usual row count. The ecommerce domain runs at L3 act reversibly.

The daily orders review opens at 09:00 on correct numbers, and the late rows Fivetran delivered stayed untouched. A Time Travel restore of the whole table to 04:06 would also have reverted any good writes since; the scoped undo did not have to choose.

The undo features your warehouse already has

Data Workers is built to use these, not replace them (all checked against vendor docs on Oct 2, 2026).

Snowflake Time Travel. Retention is 1 day by default for every account; Enterprise Edition and higher can set permanent databases, schemas and tables anywhere from 0 to 90 days. You query the past with AT or BEFORE (timestamp, offset or statement ID) and bring back dropped tables, schemas and databases with UNDROP.

Databricks table history and RESTORE. Every write to a Delta or Iceberg table creates a new version you can list with DESCRIBE HISTORY and restore with RESTORE TABLE ... TO VERSION AS OF or TO TIMESTAMP AS OF. The docs (updated Sep 11, 2026) advise using only the past 7 days for time travel unless you raise both retention settings, since deletedFileRetentionDuration defaults to 7 days, and note that a restore is a data-changing operation that "might result in duplicate data for downstream workloads".

BigQuery time travel. The window covers the past seven days by default and can be set from two to seven days. You can query changed or deleted data, restore a deleted or expired table, or restore a table to a point in time. Fail-safe keeps deleted data seven more days, recoverable only through Cloud Customer Care (docs updated Sep 30, 2026).

Each restores one platform to a point in time when a person runs it. Data Workers adds the undo recorded before the change, scoped to that change, across the warehouse, dbt and the orchestrator, ready when a check fails, with a receipt.

The alternatives buyers weigh

Build it yourself. Runbooks work when someone wrote the revert before the change and is awake to run it. Build it ourselves with Claude Code and MCP servers prices that path.

Coding agents and their checkpoints. Claude Code's docs say checkpointing does not track files modified by Bash commands and is "not a replacement for version control"; Cursor's say "Restoring a checkpoint reverts files only" (both checked Oct 2, 2026). That is the right design for a code editor. A database write sits outside it, which is why coding agents pair well with Data Workers over MCP for data changes; see you're on Cursor.

Platform-native agents. Genie Code and Snowflake CoCo confirm actions inside their own platform; Databricks' docs call Genie Code's auto-approve "a productivity feature, not a security boundary" (agent mode docs, updated Sep 25, 2026). A fix that spans Snowflake, dbt, Airflow and Looker needs an undo that spans them too.

Observability tools. Monte Carlo's cost agent docs state that "Monte Carlo is read-only by design" (checked Oct 2, 2026). Its alert is a fine trigger for a Data Workers fix that carries its undo; see Data Workers vs data observability.

Is it safe to let AI agents change production data? covers all six guardrails; our resources on governing AI agents that write to production data and AI guardrails for data pipelines go further.

The case for your CFO

A bad automated change costs a short window in the night, not a morning of wrong numbers and a week of cleanup.

The risk story is short. Each domain sits at the level you choose, from L0 manual to L4 autonomous. At L3, only changes with a recorded rollback run on their own, and a fix whose checks fail goes to a named person with that undo in hand. At L2, a named person approves each change with the rollback plan in front of them. You set irreversible changes, deletes, elevated access and spend to always need a person, and Data Workers enforces that rule. Every change and every rollback leaves a tamper-evident receipt. Your data stays in your systems; the hosted Conductor sees workflow metadata only (where your data goes).

Why now: agents already write to production in many data teams. Without a recorded undo, recovery depends on who is awake and what they remember.

The first win is one domain, usually freshness backfills or failed-run recovery, at L2 propose, moving to L3 once the receipts show clean rollbacks. What stays the same: your warehouse and its Time Travel settings, your dbt project, your orchestrator and your BI. Nothing migrates.

Start with a pilot ($7,500 one-time, credited in full against the first year); see pricing, the ROI calculator and our ROI of agentic data operations guide. The sentence for upstairs: "Every change our agents make comes with its undo written down first, and a failed check goes to a named person."

FAQ

What exactly gets undone in a rollback? Only the change it made. A backfill's recorded undo removes the records it wrote (your owner runs it), a migration runs its stored rollback SQL, a pipeline change reverts its own commit. Other writes to the same table stay in place.

What if the rollback is needed after we have moved on? Roll it back from the Spellbook inbox or through the recorded rollback path. For whole-table recovery, the warehouse's own window applies: 1 day by default on Snowflake (up to 90 days on Enterprise Edition), 7 days by default for Delta time travel, two to seven days on BigQuery. Set those windows to match how far back you want to reach.

Can an agent run a change that cannot be undone? Not on its own under the rule we recommend. Non-reversible actions are flagged before execution, and you route the most severe class (irreversible changes, deletes, elevated access, spend) to a named person at every level.

What happens if the rollback itself fails? The incident escalates to a person with the action log: what ran, what failed, and whether the rollback ran or was skipped.

What does the rollback receipt contain? Agent, tool, tenant, action, resource, arguments, outcome and time, for the change and for the undo, chained by SHA-256 in the audit log, with the named person where one approved. Read it through get_audit_trail or in Spellbook.

Sources

• •Data Workers product repository, data-workers-agent-swarm @ 871ae3df (Sep 24, 2026): core/enterprise/src (rollback, rollback-manager, classes, permission-ladder, resolution/cross-cloud-saga, audit/tamper-evident-log), agents/dw-incidents/src (tools/remediate, remediation/playbook-registry, engine/resolution-loop), agents/dw-schema/src/tools (generate-migration, rollback-migration), agents/dw-pipelines/src (tools/deploy-pipeline, validation/git-workflow), agents/dw-orchestration/src/remediation-saga, skills/dw-connectors/databricks-delta-time-travel-restore, skills/dw-pipelines/iceberg-table-maintenance, skills/dw-cost/bq-storage-billing-model. Checked Oct 2, 2026.
• •Data Workers public repository tools (remediate, generate_migration, rollback_migration, deploy_pipeline, blast_radius_analysis, get_audit_trail): https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)
• •Autonomous Data-Conductor: https://dataworkers.io/product/autonomous-data-conductor/ (checked Oct 2, 2026)
• •Spellbook Data Catalog: https://dataworkers.io/product/spellbook-data-catalog/ (checked Oct 2, 2026)
• •Snowflake, Understanding and using Time Travel: https://docs.snowflake.com/en/user-guide/data-time-travel (checked Oct 2, 2026)
• •Databricks, Work with table history: https://docs.databricks.com/aws/en/delta/history (updated Sep 11, 2026; checked Oct 2, 2026)
• •Google Cloud, Data retention with time travel and fail-safe: https://cloud.google.com/bigquery/docs/time-travel (updated Sep 30, 2026; checked Oct 2, 2026)
• •Claude Code, Checkpointing: https://code.claude.com/docs/en/checkpointing (checked Oct 2, 2026)
• •Cursor, Agent overview (checkpoints): https://cursor.com/docs/agent/overview (checked Oct 2, 2026)
• •Databricks, Genie Code agent mode: https://docs.databricks.com/aws/en/genie-code/agent-mode (updated Sep 25, 2026; checked Oct 2, 2026)
• •Monte Carlo, Cost agent: https://docs.getmontecarlo.com/docs/cost-agent (checked Oct 2, 2026)