You're on Databricks Genie Ontology: Keep Curating It, and Let Data Workers Keep It True Across Every Engine

Your stewards already did the hard part. Analytics engineers define KPIs as Unity Catalog metric views, curators group assets into domains, owners write Pages for the terms the business argues about, and certification marks which tables to trust. Genie Ontology joins that human-modeled layer with snippets Genie infers from your metric views, dashboards, SQL queries and Genie Agents (formerly Genie Spaces), ranks each by authority, and grounds every answer in Genie One (formerly Databricks One) and Genie Code. Business users ask in Slack, Teams or Excel and get an answer with citations.

Genie Ontology is where your Databricks meaning lives. Data Context Wizard is where every agent reads it, next to the definitions in Snowflake, dbt and your BI tools, with lineage, quality, usage and a named owner on every fact. Data Workers is the agentic data platform built for what happens after the curation: the moment a Page and a dbt metric disagree, or an upstream change quietly bends the metric view a Page points to. It reads Unity Catalog grants natively, works next to Genie's MCP server in your team's client, imports your metric views, reconciles its terms with the rest of the estate, routes each contradiction to its owners, and acts on the data under Genie with approvals and receipts. Your Pages stay yours, in Databricks, by design.

Key takeaways

• •Your curation keeps its job. Pages, domains, metric views, certification and inferred snippets stay in Databricks, and Genie One keeps answering from them. Data Workers never writes into Genie's own model.
• •One governed view across engines. Context Wizard imports metric views and records how Genie resolves a term, asked over Genie's MCP server from your coding agent, next to dbt, Snowflake and BI definitions.
• •Contradictions go to owners. When a Page, a metric view and a dbt metric disagree, the conflict lands in Spellbook Data Catalog with its blast radius, and nothing becomes authoritative without a named approver.
• •Fixes land where each definition lives. Metric view changes go to their owner as proposals, Page edits to the Page owner, dbt changes as diffs for the owner to merge. Genie is re-asked over MCP to confirm.
• •Start with a pilot. One domain, read-only, on the ladder from L0 manual to L4 autonomous.

Genie Ontology is where the meaning lives. Data Workers keeps it true everywhere.

Genie Ontology learns what your Databricks estate means from the way people use it, and puts the definitions your stewards write ahead of what it learns: Genie One prioritizes the human-modeled context in your Pages over inferred context, and cites them. Most companies also keep meaning in Snowflake, dbt and Tableau, and the app team changes its own database whenever the product changes. Context Wizard holds all of those definitions in one graph and checks that each curated term still matches the data under it and the rest of the company.

Here is one week at a subscription software company, an illustration rather than a customer case. The Page for "active subscriber" says active or trialing. The certified metric view subscription_metrics computes active_subscribers with status <> 'canceled', written when the app had three statuses. Finance's dbt metric in Snowflake, built on Stripe data landed by Airbyte, counts only subscribers with a paid invoice.

Genie answered well from what it could see. The problem started three systems upstream and crossed into another engine; Data Workers caught it at 02:10, put it in front of the owners and confirmed the fix through Genie itself.

Why doesn't Genie Ontology just do this itself?

Because Databricks built Genie Ontology to make Genie answer well on what Unity Catalog governs, and every design choice follows from that job. Snippets are gated by Unity Catalog permissions, so Genie only uses context the asker may see. Inferred context is ranked automatically, so it covers terms nobody has time to write down. Any consumer can create and publish a Page, which is how a glossary actually gets written. Those are the right calls for a context layer every business user touches.

Reconciling that meaning with definitions in another vendor's warehouse, a dbt project and a BI tool is a different product. It means comparing other engines' semantic models, deciding who owns each conflict, and changing data in systems Databricks doesn't run, with blast-radius scoping, approvals, rollback, receipts and the liability that comes with them. Keeping Genie Ontology focused on Databricks is a sound boundary, and the work on the other side of it is the product Data Workers is.

Every tool owns a slice. Data Workers covers the whole lifecycle

Genie Ontology owns one slice and owns it well: business context for Genie inside Databricks. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the meaning your stewards already curate. The scores match our Genie Ontology vs Data Workers comparison.

These are directional scores of scope, not benchmarks. Genie Ontology is in Public Preview (docs updated September 11, 2026), so we scored it from Databricks' documentation.

How Genie Ontology and Data Workers work together

Genie One, Genie Code and your engineers' coding agents stay on top, where people ask, curate and approve. Spellbook Data Catalog (in preview) is where the data team looks: each conflict, its approver, what changed and how to roll it back. Underneath, Context Wizard keeps one governed context graph, the Data-Agents Swarm (20+ specialist agents) does the work, and the Autonomous Data-Conductor runs each fix from detect to verify, under per-domain guardrails.

Bring your own context: four routes, all working today, none of them copying your tables.

• •Unity Catalog, through grants and lineage rows. Data Workers' Databricks connector reads grants with a scoped service principal, and system.access.table_lineage rows reach Context Wizard through the same coding agent, over Databricks' managed DBSQL MCP server, each naming the job or notebook that produced it.
• •Metric views, imported. Context Wizard imports metric view measures and dimensions beside dbt MetricFlow metrics, each tagged with source and owner, so resolve_metric returns every candidate when one term has two definitions.
• •Genie, asked over MCP. Databricks made the Genie One MCP server generally available on September 25, 2026, as the MCP Service system.ai.genie_one_mcp in Unity Gateway (formerly AI Gateway) (the managed MCP overview page still says Public Preview). In Databricks' words, "Genie resolves business terms through Genie Ontology." An engineer's coding agent or an orchestration step holds the Genie One server next to the Data Workers agents, asks Genie how it resolves a term, and hands the answer and citations to Context Wizard as evidence.
• •Pages, recorded with their provenance. When a Page settles a term, the owner records it with define_business_rule or import_tribal_knowledge, citing the Page, and can mark the canonical table with mark_authoritative. Every agent then reads the same rule through get_authoritative_source.

Writing back, the Databricks way. Data Workers never writes into the ontology, Pages or snippets. A metric view change arrives as a proposal for its owner, and a dbt change as a diff for the owner to merge. A Page edit goes to the Page owner; because Genie Code can draft a Page from "external content accessible through MCP connections", the owner can register Data Workers as an MCP Service and let Genie Code draft it. The full two-way wiring is in Genie MCP server: connect Genie One and Genie Agents to Data Workers, and the Databricks MCP basics are in our MCP server for Databricks guide.

Setup today. List the open-source repo's start-agent.sh in the client's MCP config next to the Genie One server, authenticated with OAuth and the ai-gateway scope.

Example: a coding agent's MCP config with Genie One and Data Workers
{
  "mcpServers": {
    "genie-one": {
      "type": "streamable-http",
      "url": "https://<workspace-hostname>/ai-gateway/mcp-services/system.ai.genie_one_mcp",
      "headers": { "Authorization": "Bearer ${DATABRICKS_OAUTH_TOKEN}" }
    },
    "dw-context-catalog": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-context-catalog"]
    },
    "dw-schema": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-schema"]
    },
    "dw-incidents": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-incidents"]
    }
  }
}

List the tools with the client's own command (for example /mcp). Beyond the tools above, this guide uses trace_cross_platform_lineage and blast_radius_analysis on dw-context-catalog, assess_impact on dw-schema, and diagnose_incident and remediate on dw-incidents. A term audit prompt reads: "Ask Genie One how it defines active subscriber, resolve the same metric in Data Workers, and list every definition that disagrees, with its owner and blast radius."

One term, L0 to L4. Autonomy is set per domain.

• •L0 manual. When Genie and a dashboard disagree, someone reconciles them by hand.
• •L1 observe. Data Workers lists every term defined differently across engines, with blast radius. Nothing changes.
• •L2 propose. Contradictions land in Spellbook; approved definitions become owner proposals and dbt diffs.
• •L3 act reversibly. For change classes with a proven record, such as rebuilding the days a bad value touched, Data Workers runs the fix after approval, verifies it and can roll it back.
• •L4 autonomous. For a scoped domain, Data Workers keeps the data under approved definitions healthy and re-asks Genie each morning to confirm.

You can step back down any time. For the safety model, read is it safe to let AI agents change production data; for where metadata and credentials live, read where does our data go.

What changes for your team

Genie Ontology gave your stewards a place to write down what the business means. Data Workers keeps it true after the next upstream change.

• •Incidents. A new status value or a late file is traced from the source to the Genie answer it affects, often before anyone asks.
• •Data quality. Each Page gets checks that test the data against the definition it states.
• •Cloud spend. Snowflake credits are traced to the query and dbt model behind them, and each fix goes to its owner drafted.
• •Access. A request to see a Genie Agent's tables arrives as a time-boxed grant proposal, applied through Unity Catalog.
• •Audits. Every definition change carries its approver, across Databricks, Snowflake and dbt, in one tamper-evident record.
• •Migrations. Metric views and marts move in parity-checked waves while Pages and Genie answers stay stable.

Keep Genie Ontology, or consolidate?

Keep Genie Ontology if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.

Most Databricks teams keep it: Genie One is where business users ask and Pages are where stewards write. What teams consolidate is usually a separate glossary tool or a spreadsheet of "official" metrics. If you're weighing building the reconciliation layer yourself, read build it ourselves with Claude Code and MCP servers: connecting to the Genie One MCP server is the easy part; the graph, approvals and rollback are the work. For everything else Data Workers adds on Databricks, read Data Workers on Databricks. Teams with a second context layer can follow the same pattern in you're on Snowflake semantic views and you're on the dbt Semantic Layer; the whole category is in the hub, bring your own context.

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 board dashboard or queries the finance mart. The investment in Pages and metric views keeps paying off, and fewer board numbers get restated.

The risk story. Data Workers starts observe-only. Agents propose and people approve: no definition becomes authoritative without a named approver, and no agent can approve its own work. Nothing writes into Genie Ontology, Pages or snippets; changes reach Databricks through their owners. 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. Unity Catalog permissions apply to every Genie call. Nothing migrates.

Why now. Genie One's MCP server is generally available, so every agent in the company can ask Genie. A definition that drifts no longer misleads one analyst; it misleads every assistant that asks, with a citation that makes it look right.

The first win. A read-only term audit for one domain: every Page and metric view compared with the dbt and Snowflake definitions of the same terms, with owners and blast radius, produced without writing anything.

What stays the same. Genie One, Genie Agents, Genie Ontology, Pages, domains, metric views, Unity Catalog, your dbt project, your dashboards and the people who approve changes.

The pilot path. Start with a pilot on one domain. The pilot is credited in full against the first year. For the numbers, see the ROI of agentic data operations.

The sentence to repeat upstairs: "Genie Ontology holds what our terms mean on Databricks; Data Workers makes sure every engine agrees with it and fixes the data when they drift, and nothing changes without one of our owners approving."

Getting started

Start with a pilot. Pick the domain whose terms Genie gets asked about most, connect Data Workers read-only to Unity Catalog grants and the domain's dbt project, import that domain's metric views, give one engineer's coding agent the Genie One MCP server next to the Data Workers agents, and run the term audit against your dbt and Snowflake definitions. Turn on proposals once the owners trust the list. The plans are on the pricing page, and the pilot is credited in full against the first year.

FAQ

Does Data Workers replace Genie Ontology or Pages? No. Genie Ontology stays the context layer for Genie One and Genie Code, and Pages stay where stewards write governed definitions. Data Workers reads that meaning in, reconciles it with every other engine and keeps the data under it healthy.

Can Data Workers read individual Genie snippets? Databricks exposes the ontology to outside agents through Genie itself, so your coding agent asks Genie over the Genie One MCP server and Data Workers records how it resolves a term, alongside the metric views it imports and the Unity Catalog grants it reads. Approval of cross-engine definitions happens in Data Workers, with a named owner.

Will Data Workers write into our Genie Ontology? No, by design. Metric view changes go to their owner as proposals, Page edits go to the Page owner (who can draft them with Genie Code from Data Workers over MCP), and dbt changes arrive as diffs for the owner to merge. Unity Catalog stays the permission system.

How does Genie's authority score relate to Data Workers' trust score? Genie's score picks the best context for an answer. Data Workers' trust score, built from quality, freshness, usage and owner responsiveness, orders the review queue, and a named person approves before anything becomes authoritative.

Is Genie Ontology generally available, and what does it cost? Genie Ontology is in Public Preview (docs updated September 11, 2026), Pages are in Beta, and Genie One is GA; the Genie One MCP server went GA on September 25, 2026. Databricks says customers "do not incur costs for curating ontology snippets" at this time and that pricing may change. Data Workers pricing is on the pricing page.

Sources

Databricks capabilities and statuses, checked October 2, 2026:

• •Genie Ontology (Public Preview; authority score; pricing statement), updated Sep 11, 2026: https://docs.databricks.com/aws/en/genie/genie-ontology
• •Unity Catalog semantics ("the human-modeled layer of the Genie Ontology"), updated Sep 11, 2026: https://docs.databricks.com/aws/en/uc-semantics/
• •Pages (Beta; who can publish; Genie One priority; Genie Code drafting), updated Sep 11, 2026: https://docs.databricks.com/aws/en/uc-semantics/pages
• •Unity Catalog metric views, updated Sep 11, 2026: https://docs.databricks.com/aws/en/metric-views/
• •Genie One MCP server (GA MCP Service system.ai.genie_one_mcp; ai-gateway scope; Genie Ontology quote), updated Sep 21, 2026: https://docs.databricks.com/aws/en/agents/mcp-tools/genie-mcp
• •Managed MCP servers (Public Preview label, URL patterns, scopes), updated Sep 21, 2026: https://docs.databricks.com/aws/en/generative-ai/mcp/managed-mcp
• •MCP Services (external MCP servers usable from Genie Code and Chat in Genie), updated Sep 11, 2026: https://docs.databricks.com/aws/en/generative-ai/mcp/external-mcp
• •Genie One (formerly Databricks One), updated Sep 18, 2026: https://docs.databricks.com/aws/en/genie-one/
• •September 2026 release notes (Genie One MCP server GA on Sep 25, 2026; Beta endpoint sunset Oct 31, 2026; metric view sharing GA): https://docs.databricks.com/aws/en/release-notes/product/2026/september
• •October 2026 release notes (no Genie Ontology, Pages or Genie MCP changes as of Oct 2): https://docs.databricks.com/aws/en/release-notes/product/2026/october
• •Data Workers, client setup: https://dataworkers.io/opensource-docs/client-setup/
• •Data Workers open-source repository, tool registrations: https://github.com/DataWorkersProject/dataworkers-claw-community

Product names and statuses change quickly; tell us if we've got something wrong.