Snowflake’s ontology tooling is real, and it works. Semantic View Autopilot reached GA on February 3, 2026, cutting model creation from days to minutes, and Snowflake’s own ontology-grounded Cortex Agents architecture lifted a benchmark from 50.0% to 78.2%. Atlan’s Enterprise Data Graph and Active Ontology pick up from there, extending that same work across the data estate, not replacing it. Once a knowledge graph needs to answer questions about a customer or product that also lives in Salesforce, dbt, or a BI tool, Snowflake’s own engineering team has already named that reach a “follow-on architecture concern” it has not solved yet. Extending the entities Snowflake already defined, not replacing them, closes that gap.
| What It Is | Extending a Snowflake-native ontology so the same entities resolve consistently across every other connected system |
|---|---|
| Key Benefit | Agents get one resolved definition of shared entities instead of three conflicting ones per system |
| Best For | Teams running Snowflake alongside Salesforce, dbt, Looker, or other platforms that share entities with the warehouse |
| Core Components | Snowflake Semantic Views, cross-system entity resolution, Enterprise Data Graph, Active Ontology, MCP delivery |
| When Snowflake Alone Is Enough | Entities live entirely inside Snowflake, with no CRM or separate BI semantic layer in the picture |
What does Snowflake’s ontology tooling actually do?
Snowflake’s own ontology and semantic tooling is a genuine, current capability set built for reasoning over data inside the warehouse. Semantic View Autopilot reached general availability on February 3, 2026, reducing the time to build a semantic model from days to minutes by generating Semantic Views automatically from existing schemas. Teams that previously hand-wrote metric mappings can now generate a starting model and refine it, the same trade-off covered in Snowflake Semantic Views vs Cube vs AtScale.
Underneath that, Snowflake’s own engineering team has published a more ambitious architecture: an ontology-grounded Cortex Agents system built on node-edge tables, recursive-CTE traversal, Flattened GraphRAG, and terminology-mapping overrides. On a 22-question biomedical benchmark, this improved success from a 50.0% Semantic View baseline to 78.2%. The Snowflake-Labs/ontology-on-snowflake repository backs this with a real, maintained reference implementation. An ontology formally specifies the concepts, relationships, and constraints within a domain, a discipline older than any single vendor’s tooling (Ontology Development 101, Stanford Center for Biomedical Informatics Research).
Semantic View Autopilot and the ontology-grounded Cortex Agents architecture
The two capabilities work together, not as alternatives. Autopilot handles the fast path: generate a usable semantic model from a schema in minutes. The ontology-grounded architecture handles the harder path: represent entities and typed relationships as a graph, so Cortex Agents traverse multi-hop questions instead of matching on a single table. Teams evaluating a semantic layer for AI agents should read Snowflake’s own architecture before assuming they need a separate tool.
What changes when your ontology needs to reach beyond the warehouse
Snowflake’s Semantic Views are warehouse-bounded by design: they resolve business metrics and column mappings for data inside a Snowflake account, a deliberate, sensible boundary, not an oversight. They see only Snowflake data, not dbt models, Looker metrics, Salesforce objects, or Jira data. Current practical ceilings reinforce the boundary: a 1 MB YAML spec limit, a 50 to 100 column ceiling for Cortex Analyst, no cross-account replication, and a Business Glossary still on the H2 2026 roadmap.
The load-bearing fact here comes from Snowflake’s own team, not a competitor’s critique. In the same engineering blog that reports the 78.2% benchmark result, Snowflake’s authors explicitly name multi-ontology, multi-relation-type coordination across systems as a “follow-on architecture concern” they have not yet solved, not a shortfall anyone else discovered. Christian Kleinerman, EVP of Product at Snowflake, described Horizon Context’s role in similar terms at Snowflake Summit 2026: it “helps collect signals, enrich those signals and make them available to CoCo, CoWork, or Cortex Agents.” What is Snowflake Horizon Context and Snowflake Cortex Sense cover that warehouse-native layer in more depth.
Get the AI Context Stack
A four-layer blueprint for context across the enterprise, from metadata foundation to agent orchestration, with implementation steps for 2026.
Get the Stack GuideWhat extending an ontology beyond Snowflake actually means
Extension has a concrete, narrow meaning: the same entity, resolved once, reachable everywhere it lives, not a second ontology built next to the first. The strongest proof the ecosystem, Snowflake included, sees this need is the Open Semantic Interchange (OSI), a vendor-neutral YAML standard for interoperable semantic models finalized in February 2026 with more than 50 participating companies, Snowflake among the founding group. A vendor does not co-launch a portability standard if it believed context should stay inside its own warehouse. Readers new to the concept can start with what is ontology in AI and the Ontology 101 explainer.
Most organizations run 15 to 30 tools in their data stack across three to five platforms, so agents that only see platform-native context are blind to 60 to 80% of the data estate (Atlan, 2026). Extension means resolving a shared entity into one definition every system can read, the pattern Enterprise Knowledge’s guidance on scaling a semantic layer describes: a shared top-level ontology as the hub individual systems map into, not compete with.
Semantic view vs. ontology: what’s the difference?
| Dimension | Snowflake Semantic View | Ontology |
|---|---|---|
| Scope | Single Snowflake account | Spans every connected system |
| Primary unit | Business metric or column mapping | Typed entity and relationship |
| Where it lives | Inside the Snowflake warehouse | A graph reachable by any connected system |
| Who can read it | Cortex-native tools | Any MCP-connected agent, Snowflake’s included |
Example: resolving ‘customer’ across Snowflake, Salesforce, and BI tools
Concretely: a Snowflake Semantic View defines “customer” as a row in a dim_customer table joined to billing history, Salesforce defines it as an Account record with a lifecycle stage, and a BI tool defines it as whatever grain the dashboard team modeled last quarter. An agent reading only Snowflake’s definition answers billing questions correctly and lifecycle-stage questions wrong, not because Snowflake is wrong, but because it was never scoped to cover the other two systems. Active Ontology resolves this by treating “customer” as one node with attributes from all three sources.
How do you extend an ontology across your data estate without replacing Snowflake’s semantic layer?
The extension sequence has four parts, none requiring migrating away from Snowflake Semantic Views. First, keep Semantic Views as the authoritative definition for Snowflake-native entities. Second, resolve entities that exist in more than one system, customer, product, account, into a single cross-system definition. Third, sync enriched, resolved definitions back into Snowflake rather than maintaining a disconnected parallel graph. Fourth, deliver the unified definition to agents, including Snowflake’s own Cortex Analyst, CoWork, and CoCo, through one interface, so Cortex-native and cross-system agents read the same resolved entity.
Atlan’s Enterprise Data Graph is the mechanism for the first three steps, ingesting Snowflake alongside dbt, Looker, Tableau, BigQuery, Databricks, Salesforce, and the legacy systems a warehouse-only connector never reaches (more below). The Atlan MCP server handles the fourth: it delivers the resolved ontology back to Snowflake’s own agents rather than routing around them.
Why syncing back into Snowflake matters more than building a parallel graph
A resolved entity that only exists in a separate tool creates a new problem: now there are two places to look for “the truth about customer,” drifting apart the moment either is updated without the other. Syncing enriched descriptions, governance policies, and Semantic View definitions back into Snowflake keeps this from happening, and keeps this an extension of Snowflake’s work, not a parallel system competing with it. Teams evaluating how to implement an enterprise context layer for AI should treat bidirectional sync as a requirement; the same drift risk is why semantic layer vs data catalog keeps coming up as a related question.
Context Gap Calculator
See how much of your data estate sits outside your current semantic or ontology tooling, and where the gap is largest.
Calculate Your GapCommon mistakes when extending ontology beyond Snowflake
Teams that get this wrong tend to make the same four mistakes, each in how the team implemented the extension, not a flaw in Snowflake’s own tooling.
- Forking a second, disconnected ontology instead of syncing back into Snowflake. Two sources of truth for the same entity drift apart the first time either changes without the other.
- Skipping entity resolution and letting duplicates stand. The same “customer” ends up as three unreconciled records, and an agent querying any one gets a confidently wrong answer.
- Trying to extend every entity type at once. Teams that attempt the entire schema in one project stall before shipping; starting with the entities agents actually query gets extension into production faster.
- Treating extension as a replacement project. Re-litigating decisions Snowflake already made correctly for Snowflake-native data wastes effort that should go toward systems Snowflake was never going to reach.
Most of these mistakes trace back to one misunderstanding: reading “extend beyond Snowflake” as “Snowflake wasn’t enough,” rather than “these entities also live somewhere Snowflake was never scoped to reach.” The context graph vs ontology distinction is worth understanding first, since the two are often conflated in exactly the way that produces a forked, disconnected build.
When is Snowflake’s native ontology tooling enough on its own?
For a real segment of teams, the honest answer is that Snowflake’s own tooling is sufficient. A team whose entities, customers, products, accounts, live entirely inside Snowflake, with no separate CRM, no independent BI semantic layer, and no dbt models of entities outside the warehouse, has no extension problem to solve. Semantic Views and the Snowflake-Labs architecture are sufficient as they ship today for that team.
The deciding variable is how many systems hold the same entity, not team size or maturity. Most enterprises cross this line the moment a CRM or a dedicated BI semantic layer enters the picture, earlier than most expect. Extension only becomes necessary once a team crosses that line; it is not a claim that every team already has. Compare this against AI readiness and knowledge graphs before deciding where a given team sits.
How Atlan extends ontology across Snowflake and the rest of the data estate
Atlan’s Enterprise Data Graph ingests Snowflake metadata, schemas, query history, tags, and Data Metric Function quality results, alongside dbt, Looker, Tableau, BigQuery, Databricks, Salesforce, and legacy systems most warehouse-native tools never reach, across more than 100 connectors in general availability. Active Ontology, Atlan’s ontologist context agent (Orion), resolves the same entity across those systems into one definition, the mechanism behind “customer” meaning one thing everywhere it appears, the same discipline described in ontology design for AI.
Context Engineering Studio, generally available, versions and certifies ontology entities as code before any entity reaches a production agent. Enriched descriptions, governance policies, and Semantic View definitions sync back into Snowflake, keeping this additive rather than a parallel system. This resolved graph sits alongside the broader metadata knowledge graph and knowledge graph construction work, and complements rather than replaces the vector database an agent might also use for unstructured retrieval.
On the delivery side, MCP hands the unified, cross-system ontology back to Snowflake’s own agents, Cortex Analyst, CoWork, and CoCo, so it and an agent built on an AI agent harness elsewhere in the stack read the identical resolved entity. How to give AI agents access to enterprise data covers the access side: permission to query data is not a consistent definition of what it means. Grounding agents in resolved, governed context lifted text-to-SQL accuracy by 38% in the AI Labs benchmark.
Real stories from real customers: context that spans more than one system
"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
— Joe DosSantos, VP Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
Atlan in Action: Live Context Layer Demos
Watch how enterprises resolve entities across Snowflake and the rest of their stack in a live context layer walkthrough.
Watch a Live DemoWhat Snowflake’s own engineering team flags as next: multi-system ontology
Snowflake’s engineering team, in the same blog post that reports the 78.2% benchmark result, already named the open question: multi-ontology, multi-relation-type coordination across systems is a “follow-on architecture concern” it has not yet solved. Snowflake’s own tooling did what it was built to do, reason well over Snowflake-native data. What comes next is a question of reach, not correctness: keep Semantic Views as the source of truth for Snowflake-native entities, resolve entities that live in more than one system, and sync the resolved definitions back rather than forking a second graph.
This is not a question Atlan has fully closed either. The Open Semantic Interchange standard and Snowflake’s own roadmap both point toward multi-system semantic coordination as an industry-wide problem, still being worked out across every vendor in this space, Atlan included. Explore how an ontology-first AI architecture changes once entity resolution is in place, and how that resolved graph feeds the broader agent context layer an enterprise builds around it.
FAQs about extending ontology beyond Snowflake
1. What are Snowflake’s native ontology and semantic-modeling capabilities in 2026?
Snowflake ships Semantic Views for business-metric and column-mapping definitions, Semantic View Autopilot (GA February 3, 2026), and an ontology-grounded Cortex Agents architecture built on node-edge tables and recursive-CTE traversal. Snowflake’s own engineering team reported this architecture improved a biomedical benchmark from 50.0% to 78.2%.
2. Is Snowflake Semantic Views the same thing as an ontology?
No. A Semantic View maps business metrics and columns to a query surface inside one Snowflake account, while an ontology defines typed entities and relationships any connected system can read. A Semantic View is Snowflake-scoped by design; an ontology travels across every system sharing the same entities.
3. Does Snowflake have a knowledge graph capability?
Yes, within the warehouse. The Snowflake-Labs ontology-on-snowflake reference implementation models entities and relationships as node-edge tables traversed with recursive CTEs. It reasons over Snowflake-native data; it does not natively resolve entities living in Salesforce, dbt, or a BI tool.
4. How do you keep entity definitions consistent across Snowflake, Salesforce, and BI tools?
Resolve each shared entity, such as customer or account, into one canonical definition, then sync it back into every source system rather than maintaining separate ones. Atlan’s Active Ontology performs this resolution while ingesting Snowflake, Salesforce, dbt, and BI metadata into the Enterprise Data Graph.
5. Does extending an ontology beyond Snowflake mean replacing Snowflake’s semantic layer?
No. Extension keeps Snowflake Semantic Views as the authoritative source for Snowflake-native entities and adds a resolution layer for entities that also exist elsewhere. Resolved definitions sync back into Snowflake, so the extension is additive, not a replacement.
6. What does Snowflake’s own engineering team say about ontology across multiple systems?
Snowflake’s engineering blog on ontology-grounded Cortex Agents names multi-ontology, multi-relation-type coordination across systems as a “follow-on architecture concern” it has not yet solved, its own next step, not a gap a competitor identified.
7. What is the status of Snowflake’s Business Glossary roadmap?
Snowflake’s Business Glossary is on the roadmap for the second half of 2026 and has not shipped. Current Semantic Views carry practical ceilings: a 1 MB YAML spec limit, a 50 to 100 column ceiling for Cortex Analyst, and no cross-account replication.
Sources
- Ontology in Snowflake: Building Cortex Agents, Snowflake Engineering Blog
- Snowflake Delivers Semantic View Autopilot as the Foundation for Trusted, Scalable Enterprise-Ready AI, Snowflake Press Release
- Overview of Semantic Views, Snowflake Documentation
- Ontology on Snowflake: Part 1, Overview and Data Model, Snowflake Builders Blog
- Snowflake Semantic Views: What They Do, Where They Stop, Colrows
- Snowflake Horizon Context: The Governed Context Layer for AI, BI and Apps, Snowflake Blog
- How to Scale a Semantic Layer with Interoperable Ontologies, Enterprise Knowledge
- Ontology Development 101, Stanford Center for Biomedical Informatics Research
- Build Meaning Before Machines, Forrester Research
- Ontology Is the Missing Piece From Your Agents, r/AI_Agents
