Databricks Genie Ontology vs Data Workers: Context for Genie, or One Governed Context for the Whole Estate

If your team runs on Databricks, the context story changed this summer. Your analysts define KPIs as Unity Catalog metric views. Stewards now write Pages for business terms and group assets into domains. Business users ask Genie One in Slack, Teams or Excel, and Genie Agents (formerly Genie Spaces) answer for finance, sales and ops. Underneath all of it sits Genie Ontology, which joins the definitions you model with snippets Genie learns from your dashboards, queries and Genie Agents, then ranks them by authority.

Inside the workspace, that works well. The seams show up at the edges. The finance mart is built by dbt in Snowflake. The board deck comes from Looker. The dbt Semantic Layer holds its own net_revenue. When the Snowflake rule changes and the Databricks metric view doesn't, Genie One gives the CFO one number and the dashboard gives another, and both systems believe they're right.

Genie Ontology is the context layer for Databricks' own agents, inside the workspace. Data Workers is the agentic data platform that keeps one governed context across the whole estate. Its Data Context Wizard reads the Databricks layer in as one source, joins it with dbt, Snowflake and BI definitions, sends every conflict to a person, and has agents fix the model when the definition and the numbers drift apart. This page is about choosing between them, or deciding how they share the work.

Key takeaways

• •Genie Ontology is a strong context layer for Genie. It combines Unity Catalog semantics (metric views, domains, Pages, certification) with snippets Genie infers and ranks by authority. It's in Public Preview (docs updated Sep 11, 2026).
• •It's scoped to Databricks. It learns from Databricks assets and connected apps. Nothing documented reconciles it with dbt MetricFlow, Snowflake definitions or LookML.
• •Data Workers keeps one approved definition per metric across every platform. It imports Databricks metric views, dbt MetricFlow and LookML, flags definitions that disagree, and nothing becomes authoritative without a named human approver.
• •Data Workers acts on context. When a definition drifts, agents propose the fix where the drift started, re-check the answers and leave a tamper-evident receipt.
• •Keep Genie for answers inside Databricks. Data Workers reads Unity Catalog grants, imports metric views and works next to Genie One's MCP server in your client today. Nothing moves.
• •Start with a definition audit. Observe-only, it lists every metric defined differently across your platforms, with blast radius. See pricing.

Going further. For everything Data Workers adds on a Databricks stack, read Data Workers on Databricks. For the operations side of the Genie family, read Genie ZeroOps vs the Autonomous Data-Conductor. For the executive version, read the Databricks data leader's guide.

Six things Data Workers adds on top of Genie Ontology

1. One definition per metric across every platform. Data Context Wizard imports Databricks metric views, dbt MetricFlow, dbt manifests and LookML into one governed graph. When net_revenue means one thing in Databricks and another in Snowflake, it shows up as a conflict with its sources and its blast radius, before a business user finds it.

2. A person approves before anything becomes trusted. Data Workers computes an authority score too. The score orders the review queue and ranks retrieval. It never promotes anything. Nothing reaches authoritative or canonical without a named human approver, and an agent can't approve its own work. That rule is enforced in code.

3. A trust score you can read signal by signal. Every fact carries its source, freshness and score, and the score comes with its per-signal breakdown: source reliability, how often it's used, how close it sits to human-approved facts, freshness and its correction history.

4. Corrections that hold. When a finance controller says "active customer means activity in the last 90 days", that correction becomes a governed fact. Data Workers can flag or block a later answer that contradicts it, so the same argument doesn't restart next quarter.

5. Context that leads to a fix. When context shows a problem, the Data-Agents Swarm does the work: the Pipeline Building agent proposes an approval-gated dbt diff, the Schema Evolution agent catches the upstream change, and the Autonomous Data-Conductor re-checks the result and files a receipt.

6. Context you own. The full graph and its audit chain export to open JSON-LD. Data Workers stores metadata and scrubbed facts about your data, never copies of your tables.

One incident, five systems

Here's a scenario many Databricks shops with a second platform will recognize. It's an illustrative example.

• •07:10. A finance analytics engineer merges a dbt PR that redefines net_revenue in Snowflake to exclude refunds. The change is correct and reviewed.
• •07:40. The dbt Cloud job rebuilds the finance mart in Snowflake with the new rule.
• •08:30. The Databricks metric view that Genie Agents use for revenue still includes refunds. Nobody owns keeping the two in step.
• •09:00. The CFO asks Genie One in Slack for last quarter's net revenue. Genie resolves the term through Genie Ontology, picks the certified metric view, cites it, and answers.
• •09:05. The Looker board-deck tile, built on the Snowflake mart, shows a number 3% lower.

Genie answered well from what it could see. Its job is answering. Data Workers' job is making sure the definition behind the answer is the same one finance approved, on every platform.

What Genie Ontology covers, as of October 2026

A lot changed at Data + AI Summit 2026 and in the months after it, including the names. Databricks One became Genie One, Genie Spaces became Genie Agents, Databricks Assistant became Genie Code, and AI Gateway became Unity Gateway. Here's what Databricks' own documentation says ships today.

Pages are the most important change since launch. When Genie Ontology launched in June, the trust story was a computed authority score. Since August, stewards can write governed definitions that Genie One puts ahead of what it learns. That's a real step toward governed context, and we score it that way below.

One platform, not one more tool

Context is one job on a data team's list. The same team keeps quality checks running, closes incidents, changes pipelines, runs schema changes and migrations, handles access, cuts spend and keeps the data under its models healthy. Each point tool adds another console, another contract and another handoff.

Data Workers covers the whole data lifecycle with one context graph, one approval flow and one audit trail. We score the same ten stages on every comparison page. Genie Ontology leads on Analytics & Insights, because Genie One is where business users already ask. It comes close on Catalog & Context inside the workspace. The other stages belong to other products, Databricks' or ours.

Genie Ontology 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 trusted context. Genie leads on two, both on its own surface: answers where business users already work, and context learned from Databricks usage. Data Workers leads on the outcomes that decide whether the definition behind an answer is the right one everywhere.

These are directional scores of scope, not benchmarks. They measure what each side covers, not answer quality, and the reasoning is shown so you can argue with any line. Genie Ontology is in Public Preview, so we scored it from Databricks' documentation and launch materials.

Where Genie Ontology stops

Every limit below comes from Databricks' own documentation, and none of them is a flaw. Databricks built Genie Ontology to make Genie answer well on Databricks data. Scoping it to what Unity Catalog governs is the right design for that job.

It learns from Databricks surfaces. Inferred snippets come from metric views, dashboards, SQL queries and Genie Agents, plus connected workplace apps such as Google Drive, Jira, Slack and Confluence. A dbt MetricFlow metric, a Snowflake definition or a LookML measure isn't a source it reconciles against. Lakehouse Federation can read Snowflake tables, but reading a table isn't reading the rule someone wrote about it.

The modeled layer lives in Databricks. Pages, domains, metric views and certification are governed inside Unity Catalog. A steward can attach external links as a Page's sources, and Genie Code can bulk-import Pages from documents. The Page is still a Databricks definition. If dbt changes the rule tomorrow, nothing updates the Page.

Inferred snippets rank on their own. The authority score weighs where a snippet came from, how often it's used and how fresh it is. That's a useful signal. Popularity still isn't correctness: the most-used definition of active_user in the sales org can be the wrong one for a finance question. Pages let you override it for the terms you've written down. For everything else, the ranking decides.

Publishing is open by design. Any consumer with Discover access can create and publish a Page, and owners and curators edit and accept suggestions. That's good for adoption. It's a different control from a named approver signing off before a definition steers answers.

Answering isn't fixing. When the answer is wrong because the data under it changed, Genie Ontology tells you what the data means. It doesn't change the model. Databricks' operations agent, Genie ZeroOps, is a separate private preview scoped to Databricks assets, which we compare in Genie ZeroOps vs the Autonomous Data-Conductor.

There's no documented API for the ontology itself. Outside agents can ask Genie One over its MCP server and get an ontology-grounded answer. We found no documented API or MCP tool to read, approve, write or export individual snippets.

Why doesn't Databricks just do this itself?

Because it's a different product with different risks. Genie Ontology exists to ground Genie's answers in what Unity Catalog governs. Reconciling definitions that live in Snowflake, dbt and Looker means reading other vendors' semantic models closely enough to compare them. Fixing the drift means writing to production systems Databricks doesn't run: a dbt project, a LookML repo, a Snowflake view. That requires blast-radius scoping across platforms, approvals, rollback, receipts and liability for changes in tools someone else owns.

Read-only federation is the sensible choice for a lakehouse vendor. Writing across systems, under guardrails, is the product Data Workers is.

Use Genie Ontology, Data Workers, or both

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

What it costs

Databricks says customers "do not incur costs for curating ontology snippets" at this time, and that pricing may change. Genie products moved to pay-as-you-go on Jul 8, 2026, with 150 free DBUs of model usage a month. Genie One and Genie Agents usage is free through Jan 31, 2027. Genie Code continues to bill.

Data Workers is priced the other way round. The Apache 2.0 core is free and reads, analyses and recommends. Governed writes with receipts start with the pilot, at $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. See pricing.

The fastest first win: a cross-platform definition audit

Point Data Workers at Unity Catalog, your dbt project and your BI metadata in observe-only mode. The Context Wizard imports your metric views, dbt MetricFlow metrics and LookML, and the first thing you see is a list: every metric defined in more than one place, where the definitions disagree, and which dashboards and Genie Agents sit downstream of each.

Each conflict lands in the Spellbook Promotion Inbox for the right owner to settle. Nothing writes to Databricks or anywhere else during the audit. Most teams find their net_revenue, active_customer or churn problem in the first pass, and the approved answers become the definitions every agent, including the ones your team builds on Genie One, can check against. The step-by-step path from there is in From Databricks to an autonomous data platform.

What each Data Workers product does here

Data Context Wizard. One governed graph across warehouses, lakehouses, dbt, orchestration and BI. It reads Unity Catalog grants, imports Databricks metric views, dbt MetricFlow and LookML, and carries source, author, confidence and observation time on every fact. Its authority score has the same family of signals as Genie's, with a per-signal breakdown and a human gate in front of anything authoritative.

Spellbook Data Catalog. The business-user app and control plane, in preview. Conflicting definitions, proposed promotions and proposed fixes land in one inbox where people approve, steer, send back or roll back. Approval requests also reach the team in Slack or email.

Data-Agents Swarm. 20+ specialist agents that do the work context points to. Here the important ones are the Pipeline Building agent (approval-gated dbt diffs), the Schema Evolution agent (upstream changes before they reach a metric), the Data Change Review agent (blast radius before merge) and the Search & Research agent (answers across platforms).

Autonomous Data-Conductor. Owns an outcome rather than a step: detect, diagnose, fix, review, verify and remember. For context drift, it routes the conflict, sends the fix to the right agent once a person approves the definition, re-checks the answers and records what it learned.

Guardrails

Genie Ontology manages risk by answering only from sources you're allowed to see and citing them. Data Workers manages it by letting agents propose and act under graded, reversible control.

• •New deployments start observe-only. You open the next level of autonomy one domain at a time, as the receipts earn trust.
• •No agent promotes its own work. Agent-written facts land as derived. Authoritative and canonical need a named human approver, enforced in code.
• •Every write is scoped before it runs, with blast radius computed across platforms.
• •Every executed change is approved or reversible, with a tamper-evident receipt you review and roll back in Spellbook.
• •Off-ontology writes are rejected. The graph only accepts node and edge types its schema defines, so a bad inference can't invent a new kind of fact.
• •Least privilege. On Databricks, Data Workers acts through Unity Catalog with the grants you give it, so UC's enforcement applies.

"Our agents can call Genie One over MCP. Doesn't that close the gap?"

For answers inside Databricks, largely yes. The Genie One MCP server is GA, and a coding agent like Claude Code or Cursor can ask it a business question and get an answer grounded in Genie Ontology. That beats writing SQL against raw tables.

It's still one answer from one platform's context. Nobody compares that answer with the dbt definition, routes the conflict to its owner, fixes the model or records the decision. MCP gives an agent one more tool. Data Workers gives you a governed context across the estate and an operating model for keeping it right, and every Data Workers agent is itself an MCP server your coding agent can call.

How it fits together

Nothing moves and nothing gets replaced. Connect Data Workers to Unity Catalog, your other warehouses, your dbt project and your BI tools, and add the Genie One MCP server to the same client if you want answers checked. The Context Wizard builds the graph and every agent starts observe-only. Keep Pages, domains and metric views as the governed layer inside Databricks. Data Workers keeps them in step with everything outside it.

When Genie Ontology alone is enough

Genie Ontology can be enough if Databricks holds every definition that matters, your semantic logic lives in metric views and Pages rather than dbt or a BI tool, and your need is business users asking questions. Genie One does that well.

Data Workers earns its place when a second warehouse, a dbt semantic layer or a BI model sits in the path of the numbers your leaders read, when the same definition argument keeps coming back, or when you want agents that fix the data instead of describing it.

The case for your CFO

The outcome. One approved number for each metric the business runs on, whether someone asks Genie One in Slack, opens the Looker board deck or queries Snowflake. Fewer meetings spent arguing about whose revenue is right, and fewer restated numbers after a board deck ships.

The risk story. Data Workers starts observe-only. Agents propose and people approve: no definition becomes authoritative without a named approver, no agent can approve its own work, and every executed change is scoped before it runs, reversible and recorded in a tamper-evident receipt with who approved it, what it touched and how to undo it. Nothing migrates. Unity Catalog, Pages and Genie One stay exactly where they are.

Why now. Every platform shipped its own context layer this year, Databricks included. Each one is good on its own data. Run two platforms and you now have two layers that can disagree with confidence, and business users who trust the answer because an AI cited a source.

The first win. The definition audit: a list of every metric defined differently across your platforms, with what each one feeds, produced without writing anything.

What stays the same. Your Databricks investment, your dbt project, your dashboards and the way business users ask questions.

The pilot path. Start with a pilot. It runs on your estate and the pilot is credited in full against the first year. See pricing.

The sentence to repeat upstairs: "Genie Ontology makes Genie answer well on Databricks data. Data Workers makes sure the definition behind that answer is the one finance approved, on every platform, and fixes the data when they drift apart."

FAQ

What is Genie Ontology? Genie Ontology is Databricks' unified context layer for Genie One and Genie Code, in Public Preview. It combines Unity Catalog semantics (metric views, domains, Pages, certification) with snippets Genie infers from metric views, dashboards, SQL queries and Genie Agents, ranked by an authority score and gated by Unity Catalog permissions.

Genie Ontology vs Data Workers: which should I choose? Choose Genie Ontology for answers inside Databricks. Choose Data Workers when your definitions span Databricks, Snowflake, dbt or BI, when you need a person to approve definitions before they're trusted, or when you want drift fixed at the source. Most teams with a second platform run both.

Is Genie Ontology really an ontology? It's two things. The modeled half (metric views, Pages, domains, certification) is curated and governed, which is close to what people mean by an ontology. The inferred half is a learned knowledge graph ranked by authority. Data Workers adds an explicit ontology schema that rejects off-ontology writes and a named-approver gate on anything authoritative.

What changed with Pages? Pages, in Beta since Aug 12, 2026, let stewards write governed definitions of business terms. Genie One prefers a Page over inferred context and cites it. It's the human-modeled layer of Genie Ontology, scoped to Databricks domains.

How is OntoRank different from Data Workers' authority score? Both weigh source, usage and freshness, the same family of signals. Data Workers returns the per-signal breakdown on every fact, adds correction history, and uses the score only to order review and retrieval. Promotion to trusted always needs a named person.

Does Data Workers replace Genie One? No. Keep Genie One for business users on Databricks data. Data Workers reads Unity Catalog grants, imports metric views, works next to Genie One's MCP server in your client today, and keeps the definitions behind Genie's answers in step with every other platform.

How much does Genie Ontology cost compared with Data Workers? Databricks says ontology curation has no cost at this time, and Genie One and Genie Agents usage is free through Jan 31, 2027. Data Workers has a free Apache 2.0 core, a $7,500 one-time pilot, and Scale from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats. See pricing.

Sources

Databricks capabilities and statuses, checked Oct 2, 2026: Genie Ontology docs (updated Sep 11, 2026), Unity Catalog semantics (updated Sep 11, 2026), Pages (updated Sep 11, 2026), Domains and subdomains (updated Sep 30, 2026), managed MCP servers (updated Sep 21, 2026), release notes for July, August and September 2026, the Genie One, Genie Ontology and Genie Agents launch post (Jun 16, 2026) and the Genie One press release (Jun 16, 2026). Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.