Genie ZeroOps: A Hands-On Preview
Thanks to Kristóf Molnár for your help in writing the article.
Genie ZeroOps is an autonomous agent that monitors, investigates, and proposes fixes for data pipelines, jobs, tables, and other assets, soon in your workspace.
“The target lifecycle is to first understand what happened and what was impacted downstream, and only then prioritize the issue. From there, ZeroOps would form a hypothesis, propose a fix, validate it in a sandbox, and repeat the loop based on the result.”
— Kristóf Molnár, Sr. Staff Product Manager at Databricks.
I had a chance to try it in preview. What looks like a "simple" tool is, in fact, one of the most powerful additions to Databricks so far.
How Genie ZeroOps work
Once you access ZeroOps, you land on an inbox displaying your issues.
You can monitor just your jobs, or combine job monitoring with data quality. In my opinion, the combined setup is the way to go.
Everything is in your inbox, so you have one place to monitor the whole workspace, and with Jira, Slack, and other integrations coming, you can even monitor the entire enterprise.
The data quality monitor uses anomaly detection, as we know from Unity Catalog, and is now integrated with ZeroOps. The thing that keeps it all together (and other assets too) is lineage.
Issue Lifecycle
One thing that wasn't obvious to me at first: this isn't a simple detect-then-fix loop. The full lifecycle is:
Detect → investigate → prioritize → propose a hypothesis and fix → validate, loop, improve, and validate again → human review → deploy → verify → close.
That extended lifecycle is one of ZeroOps' strongest advantages, though the sandbox for the validation loop is still in development and wasn't available in the version I tested.
Inbox
The ZeroOps inbox is genuinely clear. Status automatically moves to "Closed" once an issue is resolved. You get the source of the problem, lineage showing what else is affected, and the option to mark something as "not an issue."
Below are three problems I put ZeroOps to the test on, along with how it handled each one.
Data Overflow Issue
I started simple: a classic SQL data type problem that anyone who works with SQL has hit at some point. I had source data with integers reaching into BIGINT range, but ingested it into a TINYINT field, which broke almost immediately. ZeroOps correctly proposed running an ALTER statement to change the field type to BIGINT.
It didn't mention that type widening needed to be enabled first, so I added that step manually:
Once fixed, ZeroOps automatically marked the issue "Resolved" the next day.
Division by Zero Issue
This one was trickier. I'd built logic to handle cases where a value in one column got divided by zero, so the job ran fine except for the one failure when the input data actually contained a zero. ZeroOps caught it and proposed a clean fix.
Migration Issue
I disabled network access to the old server ahead of switching to the new one. ZeroOps correctly detected the lost connection and alerted me.
That got me thinking: what if I documented the migration (including the planned IP change for the server) in a skills.md file? It would be great if ZeroOps could read that documentation and propose a fix to update the connection automatically. That integration is coming. Usually, when I write documentation in Confluence, it gets one or two reads: one from me, and one self-like. With ZeroOps reading skills files, I'll finally be sure my documentation gets read, which might actually motivate me to document every job.
Configuration
Configuration currently happens through chat. Personally, I'm not a fan of that approach, so I'm hoping DAB support arrives soon.
At least Genie Code gave me a full list of the commands it uses to interact with the ZeroOps API.
What's Next
The ZeroOps roadmap is strong, and some of it we've already seen at the summit or mentioned above:
Sandbox
Additional lineage diagrams showing downstream impact
Jira and other tool integrations
More inbox options (assigning issues, setting severity)
Connections to MCP servers and skills
Support for more asset types
Configuration via DABs
My Top Three
Skills integration: it could finally make my documentation useful and guarantee it gets at least one reader.
Sandbox: a genuinely advanced solution, branching your code and data to validate fixes before they touch production.
DABs support: I'm a big believer in infrastructure as code, and DAB configuration would fit that workflow.
TL;DR
Genie ZeroOps is Databricks' upcoming autonomous agent for monitoring, investigating, and fixing pipeline, job, and table issues. It caught a data overflow bug (though it missed the type-widening step), resolved a division-by-zero error, and correctly flagged a broken connection during a live server migration. The full lifecycle (detect, investigate, prioritize, fix, validate, human review, deploy) is more thorough than a simple detect-and-fix loop, though the validation sandbox isn't available yet and configuration is still chat-only, not DABs.
In the era of AI, I can't imagine running Databricks in production without ZeroOps after just one day of using it. Databricks has shipped a lot recently, but this is by far the most useful addition yet.