Bring your own context: plug your ontologies, semantic layers and knowledge graphs into Data Workers
Your context already lives in ontologies, semantic layers, knowledge graphs and enterprise search. Data Context Wizard brings it in, keeps it true against the warehouse, and lets agents act on it with approvals.
Your company has already paid for context, several times over. The metric definitions live in the dbt Semantic Layer or LookML. The business entities live in a Palantir Ontology or a Fabric IQ ontology. Relationships sit in Neo4j. Documents and tribal knowledge sit behind Glean. Each warehouse now ships its own context layer too: Snowflake Horizon, Unity Catalog metric views, Google's Knowledge Catalog. Then someone asks an agent how many active customers you have, and three agents give three answers.
This page is about that moment. Your ontologies, semantic layers and knowledge graphs hold the meaning. Data Context Wizard brings that context in instead of asking you to rebuild it, keeps it true against the warehouse, and lets agents act on it with approvals. Nothing you modelled is thrown away. Data Workers, the agentic data platform, plugs each source in with provenance, joins it to lineage, quality and usage, sends conflicts to a named owner, and writes approved facts back.
This hub is the map for the series. It explains the role swap, shows what agents can do with your context at each autonomy level, and links a guide for every context tool your team is likely to run.
Key takeaways
- •Keep the context you built. Ontologies, semantic layers, knowledge graphs, memory stores and enterprise search keep holding the meaning. Data Context Wizard reads them as first-class sources and records where every fact came from.
- •One governed view for every agent. Claude, ChatGPT, Copilot, Genie and your own agents read the same approved definitions, scored against live quality, freshness and usage.
- •A named person approves what becomes canonical. Agents can propose a definition. Only a human can promote it, and every promotion carries who, why and when.
- •Context that stays true. When a column is renamed or a pipeline changes, lineage shows which definitions it touches, and the trust score drops until someone confirms the fix.
- •Nothing is migrated. Your ontology, semantic layer and graph stay where they are and stay yours. Approved facts go back as dbt docs patches, catalog sync plans and open exports, and to each tool's owner for review.
The role swap for the whole category
Every tool in this series is excellent at its job. Palantir models operational objects and the actions on them. The dbt Semantic Layer and Cube compile one metric definition to SQL. Neo4j stores and traverses relationships. Glean finds the right document with the asker's permissions. Mem0 and Zep remember facts across agent runs. Each one holds part of the meaning of your business, usually for one engine or one app.
What none of them sees is the rest of your estate. The dbt metric doesn't know that the LookML measure with the same name filters out trial accounts. The ontology doesn't know that the table behind its Customer object failed a freshness check this morning. The vector index doesn't know which pipeline produced the chunk it returned. Give an agent all of them at once and it picks whichever answer it finds first.
Put Data Workers underneath and the picture changes. The Data Context Wizard brings each source in through an importer, a catalog connector, or the tool's own API or MCP server, and every fact carries its source, confidence, authority level and time, plus who approved it. It joins those facts to lineage, quality and usage across Snowflake, Databricks, BigQuery and the rest, and scores trust on every asset from quality, freshness, documentation, usage and how fast the owner responds. The Data-Agents Swarm uses that view to do real work, the Autonomous Data-Conductor verifies each change downstream, and Spellbook Data Catalog (in preview) is where people approve definitions, roll back and audit.
Here is what the Context Wizard takes in today:
- •Semantic definitions through importers. dbt MetricFlow, Unity Catalog metric views, Wren AI MDL and dbt manifests, plus a live reader for the dbt Semantic Layer API.
- •Catalogs through connectors. Knowledge Catalog, Microsoft Purview, DataHub, OpenMetadata, Polaris, Glue, Hive Metastore and Iceberg REST catalogs, alongside Snowflake, Databricks and BigQuery.
- •Lineage and tribal knowledge. SQL and dbt lineage, Google Docs and Sheets, documents and Slack or wiki notes with author and confidence.
- •Everything else over its API or MCP server. Palantir, Glean, Fabric IQ, Neo4j, Cube, AtScale, the memory and vector stores and the rest connect to Data Workers over their API or MCP server today, and their facts enter as proposals with provenance.
Approved facts go back out through dbt docs patches, catalog sync plans, and open exports in JSON-LD and the Open Knowledge Format (OKF), so your context stays portable and stays yours.
Why doesn't your context tool just do this itself?
Focus and risk. Each of these products is built to model, store or serve meaning well for its own engine or its own app, and that focus is why it is good. Most of them sensibly expose context read-first (Glean's permission-aware search, Knowledge Catalog's discovery tools) or let agents write only inside their own model (Palantir action types, Cube data model commits, Neo4j Cypher, Fabric IQ's proposal-first ontology agent).
Reconciling one vendor's definition against another vendor's, scoring it against live quality and usage in systems the vendor doesn't run, routing the conflict to a named owner, and then changing production data with approvals, rollback and receipts is a different product with a different liability. A semantic layer vendor shouldn't be accountable for a broken Airflow DAG run, and a graph database shouldn't decide which revenue definition finance signed off. That cross-system slice is the product Data Workers is.
One definition, end to end
An illustration, not a customer case. "Active customer" is defined four ways: a MetricFlow metric in the dbt Semantic Layer, a LookML measure in Looker, a dimension in a Snowflake semantic view, and a property on the Customer object in a Palantir Ontology.
- •At 08:10 the CFO's chief of staff asks Claude for active customers by region. A sales leader asks Genie the same question at 08:25. The numbers differ by 6%.
- •Data Context Wizard already holds all four definitions with provenance: the MetricFlow metric through its dbt Semantic Layer reader, the semantic view through the Snowflake connector, LookML through the Looker connector, and the ontology property over Palantir's Ontology MCP.
- •Its contradiction scan flags the conflict: LookML and the semantic view exclude trial accounts, dbt and the ontology don't. Nothing is promoted automatically. The conflict lands in Spellbook for the finance analytics owner, with every candidate, its source, its usage and its trust score.
- •At 09:40 the owner approves the dbt definition with trials excluded. The resolution records her name, the reason and the definitions it supersedes.
- •Data Workers drafts the dbt docs and
schema.ymlpatch for review, and the approved definition goes to the LookML, semantic view and ontology owners with the exact difference to reconcile. Claude and Genie now answer from the approved fact. - •Two weeks later a product team renames
account_statusin the billing Postgres database. The dbt manifest and the context graph show the dbt model and all four definitions that depend on it. The trust score drops, an incident opens, and a scoped fix waits for approval before any agent answers from stale context.
The owner made one decision. Every agent got the same number. The receipt shows who decided, why, and what changed.
The L0 to L4 climb for context
You set the autonomy level per domain, and any domain can be dialled back at any time. One rule holds at every level: an agent can propose a definition, but only a named person can make it canonical.
| Level | What agents can do with your context | Who decides |
|---|---|---|
| L0 manual | Nothing. People keep definitions current by hand in each tool. | People |
| L1 observe | Read every source with provenance, answer from the highest-trust definition, show lineage and usage, report contradictions and stale facts. | Nobody needs to; nothing changes |
| L2 propose | Draft new definitions, business rules, corrections and dbt docs patches from what agents learn, each routed to the owner. | The domain owner approves each one |
| L3 act reversibly | Apply pre-approved classes, such as syncing approved descriptions to the catalog or updating lineage after a confirmed rename, with rollback ready. | Policy set by the owner; every action has a receipt |
| L4 autonomous | Keep a trusted domain's context current end to end, re-scoring, re-linking and verifying without waiting. Canonical promotion still needs a person. | The owner reviews receipts and can dial it back |
Most teams start every domain at L1 to see where definitions disagree, move definitions and documentation to L2 in the first weeks, and earn L3 on catalog sync and lineage updates. Our safety guide covers what an agent can and can't do at each level.
A guide for every context tool
Each guide shows how that tool's context enters Data Context Wizard, one worked example in the tool's own vocabulary, and the L0 to L4 climb. Platform context engines already have deep pages: Snowflake Horizon Context vs Data Context Wizard, Knowledge Catalog's context engine vs Data Context Wizard, Databricks Genie Ontology vs Data Workers and Unity Catalog metric views and lineage in Data Context Wizard. If your catalog is Atlan, read Atlan vs Spellbook.
Enterprise ontologies
Palantir Ontology. The Ontology MCP lets outside agents read objects and run predefined action types; Data Workers reads it and keeps the data behind each object healthy. Read You're on Palantir Ontology.
Fabric IQ. The ontology (preview) imports RDF, Turtle and OWL and turns Power BI semantic models into entities and metrics; Data Workers joins it to lineage beyond OneLake. Read You're on Fabric IQ.
Stardog. A virtual knowledge graph over many sources, queried with SPARQL, GraphQL or SQL. Read You're on Stardog.
Ontotext GraphDB. Graphwise (formerly Ontotext) GraphDB holds standards-based RDF with reasoning and Graph RAG. Read You're on Ontotext GraphDB.
TopBraid EDG. TopQuadrant's TQ Data Foundation governs SKOS and OWL vocabularies and glossaries, with an MCP server component. Read You're on TopBraid EDG.
timbr. An ontology-based semantic layer queried in plain SQL, with data virtualization over the sources you already run. Read You're on timbr.
RelationalAI. A knowledge graph and reasoner that runs as a Snowflake native app. Read You're on RelationalAI.
Salesforce Data Cloud. Data 360 (formerly Data Cloud) holds the customer profile, its semantic models and the segments it activates. Read You're on Salesforce Data Cloud.
SAP Business Data Cloud. SAP data products and the knowledge graph behind them; Data Workers connects over SAP's APIs or an MCP server today. Read You're on SAP Business Data Cloud.
Semantic layers and interchange
dbt Semantic Layer. MetricFlow definitions come in through Data Workers' importer and live Semantic Layer reader, and approved docs go back as a dbt patch. Read You're on the dbt Semantic Layer.
Cube. Cube's MCP server can edit, commit and merge the data model, so approvals on model changes matter. Read You're on Cube.
AtScale. One universal semantic layer for SQL, MDX and DAX tools, defined in open SML. Read You're on AtScale.
Snowflake semantic views. Governed metrics for Cortex Analyst and CoWork, read through the Snowflake connector. Read You're on Snowflake semantic views and the semantic views over MCP how-to.
OSI semantics (adopted). Teams that keep Ossie YAML in the repo convert it with Ossie's own dbt converter and import it as MetricFlow. Read You're on OSI semantics.
Open Semantic Interchange. Apache Ossie (incubating, formerly Open Semantic Interchange) moves definitions between tools; Data Workers decides with your owners which one is approved. Read You're on Open Semantic Interchange.
For LookML, read LookML to Data Context Wizard. For semantic layers together, read Data Workers with Cube, AtScale, MetricFlow and OSI.
Graph databases
Neo4j. Neo4j's MCP server reads and writes Cypher; Data Workers reads your graph as a source and can also run its own context graph on Neo4j. Read You're on Neo4j.
Memgraph. Real-time graph analytics with an MCP server for Cypher and schema introspection. Read You're on Memgraph.
TigerGraph. Deep-link analytics at scale with GSQL, openCypher and graph plus vector search. Read You're on TigerGraph.
Amazon Neptune. Managed property graph and RDF on AWS with Gremlin, openCypher and SPARQL. Read You're on Amazon Neptune.
PuppyGraph. Graph queries over Iceberg, Delta and warehouse tables with no copy. Read You're on PuppyGraph.
Agent memory
Mem0. A hosted MCP server with tools to add, search and update memories. Read You're on Mem0.
Zep. The unified context layer for enterprise data: temporal context graphs that trace each fact to its source, plus Zep's open-source Graphiti framework. Read You're on Zep.
Letta. Stateful agents that edit their own memory, and an MCP client that can call Data Workers' agents directly. Read You're on Letta.
Cognee. Documents and conversations turned into a queryable graph with remember and recall. Read You're on Cognee.
Vector databases and retrieval
Pinecone. Managed vector search with an MCP server for upsert, search and rerank. Read You're on Pinecone.
Weaviate. Hybrid search with a Query Agent and an MCP server. Read You're on Weaviate.
Qdrant. Filterable vector search with an open-source MCP server. Read You're on Qdrant.
Chroma. Apache 2.0 vector store with chroma-mcp for collections and documents. Read You're on Chroma.
Contextual AI. Grounded answers over document estates, with Agent Composer and an MCP server. Read You're on Contextual AI.
TrustGraph. Open-source Graph RAG with ontologies and SPARQL that you run yourself. Read You're on TrustGraph.
Context engines and enterprise search
Glean. Glean's Remote MCP Server is on by default for eligible tenants and permission-aware; Data Workers adds governed data definitions next to the documents. Read You're on Glean.
Kaelio. The open-source ktx context layer keeps definitions in git and proposes updates; Data Workers routes them to owners across platforms. Read You're on Kaelio.
Jedify. A business context graph for data agents, served over MCP and A2A. Read You're on Jedify.
Promethium. Federated answers across sources with a 360 Context Hub. Read You're on Promethium.
Databricks Genie Ontology. Authority-ranked context for Genie, read through the Databricks connector and the metric views importer. Read You're on Databricks Genie Ontology.
Snowflake Horizon Context. Context for CoWork and CoCo inside Snowflake, with Cortex Sense ranking it. Read You're on Snowflake Horizon Context.
Google Knowledge Catalog. Knowledge Catalog (formerly Dataplex Universal Catalog) assembles context bundles with lookupContext; Data Workers reads it through its connector and exchanges OKF bundles. Read You're on Google Knowledge Catalog.
New to the category? Start with what a context layer is, context layer vs semantic layer, ontologies for enterprise data and semantic layer vs knowledge graph for LLM grounding.
What changes for your data team
The context you already built starts doing work. Here is what that looks like on a normal week.
- •Definitions stop multiplying. A conflict between dbt, LookML and the warehouse goes to one owner once, and every agent answers from the approved version.
- •Context stays current. Lineage ties each definition to the tables and pipelines under it, so a rename lowers trust and opens a fix before an agent repeats a stale answer.
- •Ontology teams keep their model. Palantir, Fabric IQ and Stardog stay the system of record for entities and relationships. Data Workers reads them and sends approved changes back to their owners.
- •Tribal knowledge gets a home. Slack threads, wiki pages and Google Docs enter with author and confidence, and earn authority only when an owner approves them.
- •Audits get easier. Every fact shows where it came from and who approved it, next to every change agents made with it.
Leader buy-in: what to tell the room
The outcome. The company has already invested in semantic layers, ontologies and search. Data Workers turns that investment into consistent answers and governed changes across every agent, without a rebuild.
The risk story. At L1 agents only read, score and report. At L2 they propose and a named person approves. At L3 they act only on reversible change classes you chose, each with a receipt and a rollback. No agent can make its own definition canonical, and Data Workers acts through each platform's own permission system with the grants you give it. Our security and deployment guide covers where data goes.
Why now. In the last year every warehouse shipped a context layer and an MCP server, semantic layers and ontologies gained write tools, and standards like Apache Ossie made definitions portable. Most estates now hold three to six sources of meaning that disagree, and agents read all of them.
Build or buy. Some teams try to wire their own MCP servers to each context tool. Reads work. Reconciliation, owner approval, freshness and receipts across every system are the hard part, and we compare the paths in build it ourselves with Claude Code and MCP servers.
The case for your CFO
The company has paid for its context more than once: the semantic layer, the ontology program, the catalog, the search seats. That spend only pays off when agents give the same right answer and act on it safely. Today each agent reads whichever definition it finds, so the business gets confident numbers that disagree and the data team spends its week reconciling them. Data Workers turns that existing context into one approved answer per question, with an owner and a receipt, and nothing is migrated.
The first win is narrow and visible: connect the two or three systems that define your most-argued metric, settle it once with its owner, and let every agent answer from it. Our ROI guide shows how to size it on your own numbers. Start with a pilot on one domain. See pricing; the pilot is credited in full against the first year.
The sentence to repeat upstairs: "We already paid for our context; Data Workers makes every agent use the approved version and keeps it true, with an owner and a receipt on every change."
FAQ
Do we have to move our ontology or semantic layer into Data Workers? No. Your ontology, semantic layer and graph stay the system of record. Data Context Wizard reads them with provenance, and approved facts go back through dbt docs patches, catalog sync plans and open exports, or to the tool's owner to apply.
What if two sources define the same metric differently? The contradiction scan finds it and routes every candidate, with source, usage and trust score, to the owner. Nothing is promoted automatically, and the owner's decision is recorded.
Can an agent change a definition everyone depends on? It can propose one. Making a definition canonical needs a named human approver at every autonomy level, and the change carries a receipt and a rollback path.
How does context stay current when the data changes? Lineage from SQL and dbt ties each definition to its tables. A rename or schema change lowers the trust score and opens a scoped fix for approval.
Our tool isn't in your importer list. Can we still use it? Yes. Data Workers connects to it over its API or MCP server today, and its facts enter as proposals with their source recorded.
Is our context locked in once it's in Data Workers? No. The graph exports to JSON-LD with its audit chain and to OKF bundles, and Data Workers can run its own graph on Neo4j or Postgres.
Does this replace our catalog? No. Catalogs like Unity Catalog, Horizon, Knowledge Catalog and Atlan stay the inventory and the permission system, by design. Data Workers reads them and adds the governed, cross-platform view agents need.
Sources
- •Apache Ossie (incubating), formerly Open Semantic Interchange, https://ossie.apache.org/ (checked Oct 2, 2026)
- •Google Cloud, Knowledge Catalog overview (Dataplex Universal Catalog renamed Apr 10, 2026), https://docs.cloud.google.com/knowledge-catalog/docs/introduction (updated Sep 30, 2026; checked Oct 2, 2026)
- •Microsoft, What is ontology (preview) in Fabric IQ, https://learn.microsoft.com/en-us/fabric/iq/ontology/overview (checked Oct 2, 2026)
- •Microsoft, Import and export ontologies (preview), https://learn.microsoft.com/en-us/fabric/iq/ontology/how-to-import-export (page dated Sep 4, 2026; checked Oct 2, 2026)
- •Palantir, Ontology MCP overview, https://www.palantir.com/docs/foundry/ontology-mcp/overview (checked Oct 2, 2026)
- •Glean, Remote MCP Server, https://developers.glean.com/guides/mcp (checked Oct 2, 2026)
- •dbt Labs, About the dbt MCP server, https://docs.getdbt.com/docs/dbt-ai/about-mcp (checked Oct 2, 2026)
- •Cube, MCP server, https://docs.cube.dev/docs/integrations/mcp-server (checked Oct 2, 2026)
- •AtScale, Universal semantic layer, https://www.atscale.com/ (checked Oct 2, 2026)
- •Neo4j, MCP tools (read-cypher, write-cypher), https://neo4j.com/docs/mcp/current/tools/ (checked Oct 2, 2026)
- •Memgraph, MCP, https://memgraph.com/docs/ai-ecosystem/mcp (checked Oct 2, 2026)
- •TigerGraph, Documentation, https://docs.tigergraph.com/home/ (checked Oct 2, 2026)
- •AWS, What is Amazon Neptune, https://docs.aws.amazon.com/neptune/latest/userguide/intro.html (checked Oct 2, 2026)
- •PuppyGraph, Documentation, https://docs.puppygraph.com/ (checked Oct 2, 2026)
- •Stardog, Documentation, https://docs.stardog.com/ (checked Oct 2, 2026)
- •TopQuadrant, TQ Data Foundation documentation, https://docs.topquadrant.com/latest/ (updated Jun 29, 2026; checked Oct 2, 2026)
- •timbr, Ontology-based semantic layer, https://timbr.ai/ and https://docs.timbr.ai/doc/ (checked Oct 2, 2026)
- •RelationalAI, Documentation, https://docs.relational.ai/ (checked Oct 2, 2026)
- •Mem0, Mem0 MCP, https://docs.mem0.ai/platform/mem0-mcp (checked Oct 2, 2026)
- •Zep, Documentation and homepage (unified context layer, source tracing, Graphiti), https://help.getzep.com/overview and https://www.getzep.com/ (checked Oct 2, 2026)
- •Letta, MCP tools, https://docs.letta.com/v1-sdk/tools/mcp-tools (checked Oct 2, 2026)
- •Cognee, Documentation, https://docs.cognee.ai/ (checked Oct 2, 2026)
- •Pinecone, MCP server, https://docs.pinecone.io/guides/operations/mcp-server (checked Oct 2, 2026)
- •Weaviate, Documentation, https://docs.weaviate.io/weaviate (checked Oct 2, 2026)
- •Qdrant, mcp-server-qdrant, https://github.com/qdrant/mcp-server-qdrant (checked Oct 2, 2026)
- •Salesforce, Data 360 (formerly Data Cloud), https://www.salesforce.com/data/ (checked Oct 2, 2026)
- •Graphwise, GraphDB (ONTOTEXT AD doing business as Graphwise), https://graphdb.ontotext.com/documentation/11.5/ (checked Oct 2, 2026)
- •Qdrant, Documentation, https://qdrant.tech/documentation/ (checked Oct 2, 2026)
- •Chroma, chroma-mcp, https://github.com/chroma-core/chroma-mcp (checked Oct 2, 2026)
- •Contextual AI, Documentation index, https://docs.contextual.ai/llms.txt (checked Oct 2, 2026)
- •TrustGraph, Documentation, https://docs.trustgraph.ai/ (checked Oct 2, 2026)
- •Kaelio, ktx documentation, https://docs.kaelio.com/ktx/docs (checked Oct 2, 2026)
- •Jedify, Product overview, https://www.jedify.com/ (checked Oct 2, 2026)
- •Promethium, AI Insights Fabric, https://promethium.ai/ (checked Oct 2, 2026)
- •Data Workers, Data Context Wizard product page, https://dataworkers.io/product/data-context-wizard/ (checked Oct 2, 2026)
- •Data Workers, data-workers-agent-swarm repository (Context Wizard importers, connectors, contradiction, approval, provenance and write-back tools) (checked Oct 2, 2026)