Every agent change ships with its undo
Teams hold back on agents that change data because nobody can say how a bad change gets undone. Data Workers records how to undo each change before it runs, puts the change and its undo in front of a named approver, and keeps a tamper-evident record of what happened.
Before and after
| Today | With Data Workers |
|---|---|
| "Can we undo it?" asked after the change has shipped | The undo is recorded before the change runs |
| A rollback plan that lives in someone's head or a runbook | The change and its undo reviewed together by a named approver |
| Finding the old state by digging through query history and backups | Supported changes reverted from the record of the change |
| Code changes and data changes with different ways back | Code reverted through a pull request, as it is today |
| A bad pattern noticed only when someone complains | Agents in an area stop acting on their own when reverts pile up |
Agents that only read are easy to approve and not very useful. The step that matters is letting them write, and the question every security review asks is how a bad write gets undone. Your warehouse already gives you building blocks, such as versioning code with git and data with time travel and clones, but someone still has to decide which one applies to each agent change and prove it was ready before the change ran.
How it works
1. Draft the change with its way back
The Schema Evolution agent writes the change with generate_migration, and the plan to reverse it is recorded in the same step. For code, the way back is the usual one: a pull request that reverts the commit. The undo exists before anyone is asked to approve.
2. Show what the undo touches
The Data Context & Catalog agent runs blast_radius_analysis to list the models, dashboards and consumers the change and its reversal would affect. The approver sees the footprint of both directions, not only the forward one.
3. Approve, run and keep the record
The Data Access & Governance agent sends the change and its undo to a named approver with request_governance_review. Irreversible changes wait for a person, and the highest-risk ones need two different people. The Observability agent keeps a tamper-evident record with get_audit_trail: what was asked, what was approved, what ran and how to undo it.
The impact metrics we move
- •Undo plan ready before the change: from about half a day to minutes
- •Reverting a supported change: from about a day to under 1 h
- •"What changed and who approved it": from about 2 days to minutes
Where teams start
- •Schema migrations. Renames, type changes and new columns, each with a rollback plan.
- •dbt model changes. Agent edits arrive as pull requests, so the revert is the one you already use.
- •Remediation of failed jobs. Reruns and fixes proposed with the undo attached.
- •Access and policy changes. Grants and masking rules, reviewed with the undo recorded.
- •One domain, one warehouse. Snowflake, BigQuery or Databricks, starting with the tables behind your most-read dashboards.
What powers it
Autopilot Standards make the rule once for every domain: no change without a recorded undo and a named approver. The Data-Agents Swarm does the work (the Schema Evolution, Data Context & Catalog, Data Access & Governance and Observability agents above, plus the Incident Debugging agent for fixes), the Autonomous Data-Conductor coordinates the hand-offs, and Spellbook Data Catalog keeps the record of what changed. If reverts start piling up in one area, the agents there stop acting on their own and hand back to a person until the owner resumes them. See where this shows up in AI and ML platform data teams, AI-ready data teams and audit logging data.
The climb: from assisted to autonomous to agentic
Every transformation runs on the same ladder from our thesis. L0 to L2 run today: agents watch, propose and, with a person approving, make changes that carry their undo. L3 and L4 are where a domain can go on evidence, once its record of approved and reverted changes earns it. The autonomy levels are set per domain.
The pilot
- •Scope. One domain: the schemas and models behind your most-read dashboards, with one named approver per area.
- •First week. Agents start by watching and suggesting. They show the changes they would have proposed, each with its undo and receipt.
- •By week two. Changes in the domain arrive with their undo attached; every change still goes to a named approver, and anything irreversible waits for a person.
- •At day 30. We review the impact metrics against your baseline:
- •Undo plan ready before the change: from about half a day to minutes
- •Reverting a supported change: from about a day to under 1 h
- •"What changed and who approved it": from about 2 days to minutes
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
FAQ
Can every change be undone with one click? No. Supported changes are reverted from the record of the change, code changes through a pull request, and anything irreversible waits for a named person before it runs. The pilot lists which of your change types are in each group. The full walkthrough is in how to roll back an AI agent change.
Does it roll back by itself? No. A person decides to revert. The agents' part is to have the undo ready and to stop acting on their own in an area where reverts are piling up.
Which stacks does it cover? Warehouses such as Snowflake, BigQuery and Databricks, plus dbt, Git and 50+ connectors. Your platform's own features, such as time travel and zero-copy clones on Snowflake, stay in place beside it.
What if an agent makes a mistake anyway? The approver sees the change and its undo together, the record shows who approved what, and the revert starts from that record. Read more on letting agents change production data safely and what write access for data agents takes.