Genie ZeroOps vs the Autonomous Data-Conductor: Fixing Incidents Inside Databricks or Across the Estate

If you run Databricks, your on-call week has a familiar shape. A Lakeflow job goes red at 4 a.m., or worse, it goes green while a Delta table fills with nulls. Someone opens the run, reads the logs, walks Unity Catalog lineage upstream, and finds that the real cause sits in a dbt model in Snowflake or a renamed column in a Postgres source. Databricks announced Genie ZeroOps on June 16, 2026 to take the first half of that work off your plate.

Genie ZeroOps is the on-call engineer for the Databricks workspace. The Autonomous Data-Conductor is the incident commander for the whole estate. It finds the cause wherever it lives, fixes it there under approval, re-checks the result after the fix ships and leaves a receipt with a rollback path. Data Workers is the agentic data platform for running the whole data lifecycle, and this page compares the two on the job they share: closing data incidents.

This is the choosing page. For how Data Workers wires into a Databricks stack, read Data Workers on Databricks. For the stage-by-stage path, read From Databricks to an autonomous data platform, and for the executive version, the Databricks data leader's guide.

Key takeaways

• •Genie ZeroOps is a well-designed agent for the workspace. It traces root cause over Unity Catalog lineage, tests a fix on a shallow clone and opens a pull request for a person to approve.
• •It was announced June 16, 2026. Databricks said private preview would begin in July. As of October 2, 2026 there is no docs page, release-note entry, GA date, pricing, API or MCP server for it.
• •ZeroOps covers Databricks assets. Nothing Databricks has published names dbt, Airflow, Snowflake or BI tools as things it watches or fixes.
• •The Conductor runs detect, diagnose, fix, review, verify and remember across the estate. It fixes the cause where it starts, re-runs the quality check behind the failed test after the fix lands and leaves a receipt.
• •Autonomy is set per domain with Data Workers, from observe-only up the L0 to L4 ladder, with irreversible changes held for a named approver.
• •The free Apache 2.0 core diagnoses and recommends. Governed fixes with receipts start with the $7,500 pilot. See pricing.

What Genie ZeroOps is

Databricks describes ZeroOps as "a background agent built into Databricks that autonomously monitors, investigates, and proposes fixes for data and AI assets such as pipelines, jobs, tables, ML models and more." Its announcement, demo and summit session describe five things.

• •It watches Databricks workloads. Jobs, pipelines, tables and ML models, using run history, events, logs and data quality metrics. That includes silent failures, where a job succeeds and the data is still wrong.
• •It finds the root cause over lineage. It walks "the complete dependency graph of every asset" through Unity Catalog lineage, and can use GitHub PRs and Jira tickets as context.
• •It tests the fix on a copy of production data. Its sandbox "creates a table clone using metadata without duplicating the underlying data," with scoped permissions and network isolation, so the fix runs against real data and never against production.
• •It opens a pull request. The demo calls them "verified pull requests". Issues land in an inbox ranked by severity, and "nothing gets applied to production without your approval."
• •It governs through Unity Catalog. It reaches only what your credentials allow. In the data quality and compliance flavour shown at the summit, a governance lead approves the change.

That's a sensible design. Testing a fix against a shallow clone of real data is a real strength on Databricks' own surface, and we score it that way below.

What Databricks covers, as of October 2026

ZeroOps sits on top of Databricks' existing operations tooling, so here is the whole set with status and date.

A note on status. The announcement blog still says ZeroOps "is entering private preview in the coming weeks," and the summit session said July. Databricks' product release notes through September 2026 contain no ZeroOps entry. Some aggregators describe it as public preview; the primary sources they cite don't say that, so we don't either. One Azure Databricks blog calls ZeroOps "a fully autonomous execution layer that handles underlying infrastructure provisioning and query tuning." The main announcement describes propose-and-approve, and we use that reading.

One incident, five systems

This is an illustration, not a customer case. It shows what ZeroOps sees and what Data Workers does when the cause sits outside the workspace.

At 02:10 a source team renames cust_id to customer_id in the Postgres billing database. At 02:40 Fivetran lands the change in Snowflake. At 03:15 the dbt Cloud job builds fct_revenue with null customer keys. The tests are warn-level, so the run goes green. At 04:00 the Airflow DAG triggers a Lakeflow job that copies the model into a Delta feature table. The job succeeds, and anomaly detection flags a completeness drop on the managed table.

ZeroOps does its part well: it sees the symptom where it lands and proposes a tested Databricks-side patch. The dbt model is still wrong, though, and tomorrow night's run will write nulls again. Data Workers follows the same failure into dbt, fixes it there, reruns the pipeline, re-checks both the dbt test and the Delta check, and files a receipt with the diff, approver, timestamp, blast radius and rollback path. The pattern is remembered, so the next rename of a key column is caught before the dbt run.

Why doesn't Databricks just do this itself?

Focus and risk. Databricks built ZeroOps to make the lakehouse run itself, and that is the right job for it. Databricks' agents make Databricks the center of gravity, which is a sensible business choice, and the design follows from it.

ZeroOps reasons over Unity Catalog lineage and tests on Delta shallow clones. Both are excellent inside the workspace and both stop at its edge. Lakehouse Federation lets it read a Snowflake table, but reading is where federation ends. Its write path is a pull request into the Databricks project. It has no write path into a dbt repo that builds in Snowflake or into an Airflow deployment, and no business reason to build one.

Writing to production across systems is a different product. It needs blast-radius scoping that spans every platform a change touches, approvals that route to the right owner, rollback for each kind of action, receipts that hold up in an audit, and context about every other system in the estate. It also means taking responsibility for changes in tools Databricks doesn't own. That's the product Data Workers is.

One platform, not one more tool

Fixing incidents is one stage of the data lifecycle. The same team keeps the catalog current, answers business questions, writes quality checks, runs pipelines, changes schemas, handles access, protects sensitive data, cuts spend and keeps models fed. Each point tool adds another console, another contract and another handoff.

Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail. We score the same ten stages on every comparison page. Here we score Genie ZeroOps as the agent, together with the Databricks features it consumes. It wins its two home stages, Observability & Incidents and MLOps & Models.

Genie ZeroOps vs Data Workers on the outcomes you buy

The lifecycle view shows breadth. This view scores eight outcomes a data leader pays for when the job is closing incidents. ZeroOps leads on two, both on its own surface: clone-testing and being native to Lakeflow. We're even on shipping through your own review. Data Workers leads on the outcomes that decide whether the incident is actually closed.

These are directional scores of scope, not benchmarks, and the reasoning is shown so you can argue with any line. ZeroOps is in private preview, so we scored it from Databricks' announcement, demo and summit session.

Where Genie ZeroOps stops

Every limit below comes from Databricks' own materials, and each follows from building an ops agent for the lakehouse.

It acts on Databricks assets. ZeroOps launches on jobs, pipelines, tables and ML workloads, with "Apps, and Lakebase databases" on the roadmap. It reads GitHub and Jira as context. It doesn't watch or fix dbt, Airflow, Snowflake or BI.

Many incidents start upstream of the workspace. A renamed source column, a Fivetran sync, a dbt model in Snowflake or a late Airflow task all surface as a Lakeflow problem. ZeroOps sees the symptom where it lands. When the cause is outside Databricks, it can patch only the Databricks side.

Verification ends at merge. The shallow-clone test is strong evidence before merge. Nothing documented re-checks the downstream table or closes the incident after the fix ships.

Rollback and audit belong to your CI/CD. ZeroOps has no documented rollback of its own. Deployment history lives in your bundles and CI, and activity in workspace audit logs.

Autonomy is fixed at propose. Every change waits for a person. There's no documented way to let one class of fix, such as reruns of late loads, run on its own.

It has no API or MCP server. Findings stay in its inbox UI. The managed MCP list (updated September 21, 2026) has no ZeroOps server, so other agents can't read its findings yet in a supported way.

It isn't available to buy. Private preview is invite-only through your account team. No regions, clouds or pricing are published.

How the Conductor runs the loop across the estate

The Autonomous Data-Conductor owns an outcome, not a step. It runs detect, diagnose, fix, review, verify and remember across the estate, routes work to the right specialist in the Data-Agents Swarm and writes what it learned to one context graph. Every agent is an MCP server, so your coding agent can call any of them.

1. Detect. The Quality Monitoring and Observability agents watch volume, schema and lateness against recorded baselines. Data Workers reads the dbt manifest, Airflow 2 and 3 DAG and task state over the Airflow REST API, and Lakeflow run history from system tables, which your coding agent queries through Databricks' managed DBSQL MCP server. If you also run Monte Carlo, Data Workers reads its monitors and incidents over its API today.

2. Diagnose. Data Context Wizard joins your dbt manifest, Airflow state, Snowflake query history and BI metadata in one graph, with Unity Catalog grants and metric views. The Incident Debugging agent follows the failure past the workspace edge to where it started.

3. Fix at the source. The change lands where the cause lives. A dbt fix becomes an approval-gated diff for the owner to merge (Data Workers + dbt). An Airflow rerun goes through a confirmation-guarded trigger (Data Workers + Airflow). On Databricks, grants apply through the Unity Catalog permissions API with the scope you set.

4. Review. The Data Change Review agent attaches a blast-radius report across platforms. Anything irreversible waits for a named approver.

5. Verify. The fix isn't done when the change merges. Data Workers re-runs the quality check behind the failure after the fix lands and closes the incident when it passes.

6. Remember. The receipt and the pattern go into the context graph, so the next break of the same kind starts with what the last one taught.

Genie ZeroOps vs Data Workers, side by side

Use ZeroOps, Data Workers, or both

"Both" means Data Workers works alongside the Databricks capability.

What it costs

Databricks hasn't published pricing for ZeroOps. Related features give a hint: anomaly detection bills serverless DBUs for the tables it scans.

Data Workers' Apache 2.0 core is free; it reads, analyses and recommends. Governed writes with receipts start with the pilot, which is $7,500 one-time. Scale starts at $1,000 a month and Enterprise at $3,000 a month, billed annually. Seats are unlimited, there's no usage meter, and there's no markup on model spend because you bring your own model. Details are on the pricing page.

The fastest first win: a retro on last month's job failures

Connect Data Workers to your dbt project, Airflow and your other warehouses, observe-only, and have your coding agent hand it the last 30 days of Lakeflow job failures from system tables. For each one, Data Workers shows where the root cause actually lived, inside or outside the workspace, what the fix would have been, where it would have landed and its blast radius. The failures that started upstream become dbt diffs proposed for your team to review. Nothing writes to production during this step.

The case for your CFO

The outcome. Data incidents get closed at the source and checked after the fix ships, so the revenue number on Monday's dashboard is right and the same break doesn't come back next week. Engineers spend less of their week tracing failures across systems they don't own.

The risk story. Autonomy is set per domain on a five-rung ladder. At L0 a person handles the work and at L1 agents only observe. At L2 they propose and wait. At L3 they take reversible actions, such as a rerun. At L4 a domain you have chosen runs on its own. Irreversible changes always wait for a named approver, no agent can approve its own work, and every executed change can be rolled back. Each receipt records the diff, the approver, the timestamp, the blast radius and the rollback path. Nothing migrates: Databricks, dbt, Airflow and Snowflake stay where they are.

Why now. Databricks has validated the detect-to-resolve model by announcing ZeroOps. That model is in private preview with no GA date or pricing, and it stops at the workspace edge.

The first win. The retro above: a month of job failures, each traced to its real cause, with proposed fixes.

What stays the same. Databricks and Unity Catalog stay authoritative. Your team keeps dbt, Airflow and its review process, and works through the coding agent it already uses. ZeroOps can stay too.

The path. Start with a pilot (see pricing). The pilot fee is credited in full against the first year.

The sentence for upstairs: "Databricks just showed that ops should run from detection to fix. We need that loop across dbt, Airflow, Snowflake and Databricks, verified after the fix ships and with a receipt, and we can pilot it now."

Guardrails

ZeroOps manages risk by proposing everything. Data Workers manages it with graded, reversible control.

• •Autonomy is set per domain. Reruns of late loads can run at L3 (act, reversibly) while dbt model changes stay at L2 (propose).
• •New deployments start observe-only. You open the next level one domain at a time as the receipts earn trust.
• •Every write is scoped before it runs, with blast radius computed across platforms.
• •Every action is approved or reversible, and every executed change leaves a tamper-evident receipt. You review and roll back in Spellbook Data Catalog, which is in preview.
• •No agent can approve its own work. An authority guard enforced in code sits in the write path.
• •Least privilege. On Databricks, grants go through the Unity Catalog permissions API, so UC's enforcement applies.

How it fits together

Nothing moves and nothing gets replaced. Data Workers connects to Unity Catalog for grants, your dbt project, Airflow and your other warehouses, and takes Lakeflow run state from system tables through your coding agent. Context Wizard builds the graph, every agent starts observe-only, and your team asks and approves from the coding agent it already uses, with Spellbook as the place to review, roll back and audit. ZeroOps has no API, so its findings stay in its inbox. The pull requests it opens are ordinary PRs in your repo, and Data Workers reviews them like any other change. Data Workers stores metadata and scrubbed facts about your data, not copies of your tables.

When Genie ZeroOps alone is enough

ZeroOps can be enough if Databricks runs your whole critical path, from ingestion through orchestration to the tables your dashboards read, and your team is happy to approve every fix by hand. If you have a dbt project, an Airflow deployment or a second warehouse in that path, your incidents will often start outside the workspace, and that's where the Conductor earns its place.

FAQ

Genie ZeroOps vs Data Workers: which should I choose? Choose Data Workers if your incidents cross systems, if you want fixes made at the source, or if you need receipts and rollback for every agent change. ZeroOps suits a Databricks-only estate where every fix is approved by hand. Many Databricks teams will run both.

Is Genie ZeroOps available yet? Databricks announced it on June 16, 2026 and said private preview would begin in July. As of October 2, 2026 there is no docs page, release-note entry, GA date or pricing. Ask your account team for preview access.

Does Genie ZeroOps work with dbt or Airflow? Nothing Databricks has published says ZeroOps watches or fixes dbt or Airflow. It can read GitHub PRs as context. Data Workers reads your dbt manifest and Airflow 2 and 3 task state, and fixes there.

Does ZeroOps have an API or MCP server? Not that Databricks has documented. Its findings live in an inbox UI. Databricks' managed MCP servers cover Genie One, Genie Agent, AI Search, DBSQL and UC functions. Data Workers works next to those servers in the same client and reviews the PRs ZeroOps opens.

Can we run ZeroOps and Data Workers together? Yes. ZeroOps keeps testing Databricks-side fixes on shallow clones. Failures that trace outside the workspace go to the Conductor, and both sides ship through your review.

What does the free core do? The Apache 2.0 core reads, analyses and recommends. Governed fixes with receipts start with the $7,500 pilot. Scale starts at $1,000 a month and Enterprise at $3,000 a month, billed annually, with unlimited seats and no usage meter.

What happens if an agent gets a fix wrong? Data Workers scopes every write before it runs and sends it to review at the autonomy level set for that domain. Every action is approved or reversible, every executed change leaves a tamper-evident receipt with a rollback path, and no agent can approve its own work.

Sources

Sources for Databricks capabilities and statuses: Databricks announcements, documentation and release notes current as of October 2, 2026, including Introducing Genie ZeroOps, the Genie One press release, the Genie ZeroOps for data quality and compliance session, the ZeroOps demo, the Lakeflow agentic data engineering blog, the Azure Databricks blog, the product release notes, and docs for anomaly detection, Genie Code for pipelines, managed MCP servers, repair runs, job notifications and Declarative Automation Bundles. Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.