Cortex Sense vs Genie Ontology - Which One Checks the Answer

In June 2026, Snowflake and Databricks each announced a governed context layer for their AI agents, two weeks apart. Cortex Sense and Genie Ontology converge on nearly the same architecture. They both learn a model of your business from the signals you already produce, rank the most trusted definitions, and serve them to an agent. The real differences between the two are narrow. The difference that matters is the one they share. Neither checks whether the number an agent computes is correct. This post credits both, draws the line honestly, and names the third thing that does the checking.

1. What each one is, in one paragraph

Genie Ontology is the context layer Databricks announced at its Data and AI Summit in June 2026. It builds a graph of how your company works, learned from your Databricks data and from more than 50 connected applications, and it ranks the most authoritative definition of a term or a metric for an agent to use. Databricks describes the ranking as an approach similar to PageRank, and at the keynote its team called it OntoRank. Genie Ontology is in preview. The agents it powers, Genie One, Genie Agents, and Genie Code, are generally available. For the full breakdown, see What Is Genie Ontology?.

Cortex Sense is the context layer Snowflake announced at Snowflake Summit, two weeks earlier. It collects the business definitions an agent needs from signals you already have, then finds and reorders the definitions that fit a question and hands the top ones to the agent. It feeds two Snowflake agents, CoWork, a work assistant, and CoCo, a coding assistant. Cortex Sense is entering private preview in mid-July 2026. For the full breakdown, see What Is Cortex Sense?.

Both are governed context layers for AI agents. Both work with a single vendor. Each one is real work on the right problem, and the first job of this post is to say what each gets right before it draws a line neither one crosses.

2. Where they converge

The striking thing about these two announcements is how little separates them. Two rivals, two weeks apart, shipped the same shape of product.

Both learn from the signals you already produce. Genie Ontology reads your tables, queries, dashboards, pipelines, and connected applications, and builds a graph from them. Cortex Sense assembles its context from signals like query history, object metadata, BI dashboard definitions, and the governed semantic views in Snowflake's Horizon Context. Neither requires new hand-written knowledge to start.

Both are maintained ahead of time, not assembled fresh at each query. Genie Ontology keeps its graph up to date as the data changes. Cortex Sense has a one-time indexing cost and a continuous refresh cadence. It is worth being exact here, because an early reading of Cortex Sense called it a query-time service. Snowflake's own description is a pre-built index that refreshes, which is the same posture as Genie Ontology.

Both rank context by trust. Databricks says Genie Ontology weighs five signals: where a definition came from, the authority of its author, how often people rely on it, how closely it ties to certified and widely used assets, and how fresh it is. Snowflake says Cortex Sense ranks by relevance, authority, popularity, and freshness, and gives an explicit example. A metric definition backed by a governed semantic view carries more authority than one inferred from a handful of queries, and a join pattern in 500 production queries carries more weight than one in three. These are the same idea. Rank the definition your company trusts most.

Both keep a human in the loop for conflicts. Snowflake's Cortex Sense surfaces a conflict to a human to settle. Databricks' own documentation tells space authors to review and resolve inconsistencies. Neither product removes curation. Both reduce it.

Both anchor in a governance catalog. Genie Ontology sits on Unity Catalog, whose semantics feed it as one governed input. Cortex Sense sits on Horizon, whose semantic views it treats as the gold-standard signal.

And both led their announcements with the vendor's own benchmark showing accuracy climbing sharply once context is added. That is not two visions competing. It is one architecture, shipped twice.

3. Where they actually differ

The differences are real, but they are narrower than the marketing suggests, and they are about mechanism, emphasis, and maturity rather than about the core bet.

The selection mechanism differs. Genie Ontology builds a persistent graph and ranks nodes in it, which is why the PageRank comparison fits, because authority flows through links between definitions and certified assets. Cortex Sense finds and reranks definitions, and the underlying retrieval is the same kind of hybrid search by meaning and keyword that Snowflake documents elsewhere in its platform. Graph ranking and retrieval reranking are different techniques, and they can fail in different ways, but both end in the same place, a short list of trusted definitions handed to an agent.

The emphasis differs. Snowflake foregrounds the human-authored semantic view as the gold standard and layers automation around it. Its auto-generator of semantic views, Semantic View Autopilot, is already generally available and reframes modeling as going from coding into curation. Databricks foregrounds the auto-built graph and treats the governed semantic layer as one input the graph reads. One vendor starts from the governed definition and reaches toward automation. The other starts from automation and reaches back toward governance. They are heading for the same middle from opposite ends.

The maturity differs. Snowflake's auto-generator is GA, but Cortex Sense itself, the full auto-context engine, is only entering private preview in mid-July 2026. Databricks has Genie Ontology in preview and the agents it powers already GA. Neither vendor has the full auto-context piece at general availability yet. Both are shipping the vision ahead of the finished product.

Here is the comparison in one view.

The last row is the point of this post. Read on for why it is the same on both platforms.

4. Where they are the same in the way that matters

Both vendors support the story with their own benchmark. Databricks reports that Genie answered 84.5% of real-world questions correctly on the first try, against 52.4% for the strongest general-purpose coding agent. Snowflake reports a climb from about 23% for a general agent with no governed context, to about 47% for its own agents with the service off, to about 83% with Cortex Sense on. These are each vendor's own internal benchmark, run on the vendor's own platform, and they use different baselines and different questions, so they are not a score between the two products. Read each as the vendor's number. Even read that way, both gains are large, and governed context clearly helps an agent answer hard questions. That is worth saying plainly.

Now look at what the ceiling leaves out. If 83% of answers are correct, roughly one in six is wrong. If 84.5% are correct, it is still roughly one in six. In both cases the agent does not mark these answers as uncertain and does not refuse them. It returns them in the same confident voice as the answers that are right, and it can cite a governed source for them. So the number each vendor led with is the problem, not the win. The governed layer is on, and roughly one in six answers is still confidently wrong, with a governed source attached.

An answer is still wrong for three reasons, and the reasons add up. They apply to both layers.

First, the context each layer builds can be incomplete. The graph and the semantic view hold what a metric means. Neither holds every rule that decides whether a calculation on that metric is valid. The definition can be present and right, and the rule that protects it can be absent.

Second, the selection step can surface the wrong definition. This failure lives inside each product's own hero mechanism. OntoRank ranks by authority and popularity, and the most popular definition is not always the right one for the question asked. Cortex Sense reranks by relevance and the same trust signals, and the best-matching definition is not always the correct one either. A ranking measures how trusted or how relevant a definition is. It does not measure whether that definition answers this specific question. Better ranking reduces how often the wrong one rises. It does not remove it.

Third, and this is the hardest reason, some errors do not come from the context at all. Suppose the layer surfaces the correct, complete definition. The agent can still compute the wrong number, because the metric gets combined across time, or across levels of detail, in a way that is not valid. A definition tells the agent what a metric means. It does not tell the agent what math is safe to do with it. Whether a calculation is valid depends on how the metric was built in the transformation code that produced the data. Neither layer runs the agent's query against that code, and neither checks the result.

Context is not correctness, on both platforms. More context helps with the first two reasons. It does not touch the third.

5. The worked example that breaks both

First, a disclosure. Cortex Sense is entering private preview and Genie Ontology is in preview. We have not tested either, and we make no claim about either. The receipt below is a Cortex Analyst query, which Snowflake ships today as a generally available product, run against a governed semantic view. We use it only to show the kind of error that any context layer leaves unfixed, whether the layer ranks a graph or reranks retrieval.

A real one first. In a production environment we audited, Cortex Analyst, on a governed semantic view, was asked for a count of servers. It reported 477 servers and described them as growing every month. The true number was 48, and it was flat. The metric summed a per-period distinct count across time, so a server present in more than one period was counted in each one. Typedef's typed graph caught it deterministically, by reading how the metric was built. Cortex Sense and Genie Ontology are context layers that sit on top of exactly this kind of governed definition. A better-ranked definition, or a better-retrieved one, does not change this number, because the fault is not which definition the agent chose. It is in the transformation the definition sits on.

Here is the same class of error in a form you can run yourself in ten lines. A company stores a daily count of active users. Each row holds a date and the number of distinct users active that day, computed upstream with a COUNT(DISTINCT user_id). Someone then defines monthly active users as the sum of the daily counts. That definition can be the most authoritative one in the company. It can be certified, widely used, ranked first by OntoRank, and returned first by Cortex Sense. It is still wrong to add daily distinct counts across a month, because a user active on more than one day is counted on each of those days.

sql
-- Three users, two months. Some users are active on more than one day.
CREATE TABLE raw_events (event_date DATE, user_id INT);
INSERT INTO raw_events VALUES
  ('2024-01-01', 1), ('2024-01-15', 1),  -- user 1 active twice in January
  ('2024-01-15', 2),
  ('2024-02-02', 1),
  ('2024-02-10', 3), ('2024-02-20', 3);  -- user 3 active twice in February

-- The upstream daily table: active_users is already a per-day COUNT(DISTINCT)
CREATE TABLE daily_active_users AS
SELECT event_date AS activity_date, COUNT(DISTINCT user_id) AS active_users
FROM raw_events
GROUP BY event_date;

sql
-- WRONG: sum the daily distinct counts across the month
SELECT date_trunc('month', activity_date) AS month, SUM(active_users) AS mau
FROM daily_active_users
GROUP BY 1 ORDER BY 1;
-- January: 3, February: 3

sql
-- CORRECT: count distinct users over the whole month from raw events
SELECT date_trunc('month', event_date) AS month, COUNT(DISTINCT user_id) AS mau
FROM raw_events
GROUP BY 1 ORDER BY 1;
-- January: 2, February: 2

The true monthly active users are two in January, users 1 and 2, and two in February, users 1 and 3. The sum reports three in each month, because it counts user 1 twice in January and user 3 twice in February. This output is verified on DuckDB v1.2.2. The error is in the transformation rather than the engine, so the same numbers come back on any SQL engine.

Now notice where the fact that breaks the answer lives. It is not in the question, which only asked for monthly active users. It is not in the definition, which is a plain sum and looks safe to add. It is not in the two tables, because one stores raw events and the other stores a daily count, and neither shows that adding the daily counts double counts people. The COUNT(DISTINCT) that makes the sum invalid is a step in the transformation code between raw events and the daily table. Nothing in the question, the definition, or the daily table warns you, and a context layer does not recompute the metric from the raw events to find out. The only place the error shows is in that transformation.

This same sum is what you would register as a governed metric on either platform. On Databricks it is a Unity Catalog metric view that Genie reads as context. On Snowflake it is a semantic view that Cortex Sense treats as the gold-standard signal. Both governed objects encode the same additive-looking SUM(active_users), and both layers can serve it with full confidence. The governed layer does not make the number right. It makes the wrong number authoritative, and consistent everywhere it is used, which is worse than a single mistake because now every agent repeats it and cites a governed source.

6. Three graphs, three questions

The clearest way to hold all of this is to see that we are talking about three different questions, and only one of them is about correctness.

Genie Ontology is a graph of observed authority. It answers which definition the company trusts most. Cortex Sense is a retrieval service over a governed store. It answers which definition best matches the question. Both are questions about which context to use, and both are useful. Neither is a question about whether the resulting calculation is valid.

The question of validity needs a different graph. That graph is built from the transformation code that produced the data, and it carries the rule for what math each metric allows. It answers whether a calculation is valid. Genie has the authority graph. Cortex Sense has the retrieval layer over the definition store. Verification needs the third graph, and neither product is it.

A fair objection comes up here, and it is the strongest one either vendor can make. Genie Ontology links definitions to certified assets, and both platforms build lineage that records which columns feed which. Does that not already cover validity? It does not. Certification and authority links record who trusts a definition. Lineage records that one column feeds another. Neither of them carries the rule that a distinct count cannot be summed across time, which is the exact fact you need to catch the error in Section 5. Having the certification link, and having the lineage, is not the same as catching the error. The rule that protects the calculation comes from reading the transformation code itself, not from who trusts the definition or which column feeds which.

A fair objection is that both platforms let you declare non-additivity. Snowflake semantic views have a NON ADDITIVE BY clause, and Databricks metric views recognize non-additive measures like COUNT(DISTINCT) and even warn that their grand totals can be wrong. So why does the example still slip through? Because both act on what is visible in the metric definition. The example's metric is a plain SUM(active_users), and the COUNT(DISTINCT) that makes it invalid lives one layer upstream, in a separate model that already collapsed the data to a daily count. The measure the platform sees is an ordinary additive sum, with no DISTINCT to recognize and no dimension a modeler would think to mark. The declaration is also hand-written, so it only helps when someone remembers, and Snowflake's clause returns the last snapshot value anyway, which for a distinct count is the last day's number, not the month's. Declared non-additivity records what a person asserted about the measure they wrote. It cannot read what the upstream code already did to the data.

There is a second reason the derived graph is the durable one. The definitions a context layer ranks or retrieves are authored by people or inferred from usage, and hand-maintained context drifts from the data as the business changes. Anthropic's own data team reported exactly this pattern in a writeup on the analytics agent they built. In their words, "we watched our offline accuracy drift from ~95% at launch to ~65% over a month before we treated this as an engineering problem." The cause was that the skill documents giving the agent its context describe a data model that changes daily, so without active maintenance they are wrong within weeks. A graph derived from the transformation code is re-derived from that code on every commit, so it does not drift away from what the pipeline actually does. This is the derived-versus-hand-authored axis, and it is the reason a verifier re-checks the math on every change rather than trusting a label someone wrote once. Reading a metric's lineage back to the operation that decides its validity, the buried COUNT(DISTINCT) in the example above, is what we call metric provenance.

7. The third thing: a verifier in the loop

The only thing that turns a good guess into a checked answer is to verify the answer against the code that built the data. In practice this means working out the properties of each metric from how it was built, and checking the answer against those properties before it goes out. A verifier here is a deterministic check derived from that code. It is not a second model grading the first, and there is no judgment call in it.

The check works at two levels. When the unsafe pattern is visible in the measure expression, for example a COUNT(DISTINCT), an AVG, a MEDIAN, or a ratio that divides by a distinct count, the verifier reads the expression and marks the measure as not safe to add on its own. There is no field for a person to fill in, and no person in the loop.

When the pattern is buried upstream, as it is in the Section 5 example, the verifier follows the metric's lineage back to the COUNT(DISTINCT) that produced the daily column and derives the same property from the transformation that built it. That is the walk that caught the 477 in Section 5.

What holds at both levels is the principle. Whether a calculation is valid can be derived by reading the code that built the metric, at the level of the expression and at the level of the lineage behind it. A context layer cannot derive it at either level, because neither the ranked graph nor the reranked retrieval reads the transformation code. A label is something a person declares. A property is something you read from the code.

This matters more as the reader of the metric changes. A person building one dashboard might know not to sum daily active users. An agent querying a governed metric does not. It will group by whatever level of detail the question implies, including the monthly rollup nobody checked, and it will return the inflated number with full confidence and a governed source to cite. That is the failure both Cortex Sense and Genie Ontology leave in place, and it is the failure a verifier is built to catch.

This is what we build at Typedef. Typedef is the verifier for data agents. It derives the properties of your metrics from the transformation code and checks an answer against those properties before it ships. You can read more without booking a demo at Typedef.

8. Where this goes next

If you want to go deeper on either platform, the four explainers this comparison sits on are live, one for each layer on each side: What Is Cortex Sense?, What Is Genie Ontology?, What Is Horizon Context?, and What Are Metrics in Unity Catalog?.

If you would rather check your own data than trust ours, run the ten-line example above on any SQL engine, then try the same pattern on one of your own governed metrics. Define one as a sum over a pre-aggregated daily count, then recompute it from the raw events. If the two numbers disagree, your own data has made the case, not this post.

9. FAQ

Which should I pick, Cortex Sense or Genie Ontology? On the vision, there is little to pick between them. Each works with a single vendor, so in practice the platform you already run decides it: Cortex Sense on Snowflake, Genie Ontology on Databricks. The more useful question is not which context layer to pick but whether either one checks its answers. Neither does.

Is either available yet? As of July 2026, Genie Ontology is in preview and Cortex Sense is entering private preview in mid-July 2026. On Snowflake, Semantic View Autopilot, the auto-generator of semantic views, is already generally available. The benchmark figures describe the previews, not products you can buy and rely on today.

Does either one verify the agent's answer? No. Both rank or retrieve authoritative context and serve it to the agent. Neither runs the agent's query against the code that built the data, and neither checks whether the result is correct. Both vendors position these as context layers, and independent coverage of both launches made the same point, that better context improves answers without guaranteeing they are correct.

How is a verifier different from a context layer? A context layer answers which definition to use. A verifier answers whether the calculation on that definition is valid, by deriving each metric's properties from the transformation code and checking the answer against them before it ships. The context layers read definitions, usage, and lineage. The verifier reads the code that built the metric, which is where the rule that protects the calculation actually lives.

Did Typedef test Cortex Sense or Genie Ontology? No. Both are in preview, we make no claim about either, and nothing in this post is based on probing either vendor's internals. The example in Section 5 is plain SQL you run yourself, and the supporting facts are each vendor's own public documentation.

Sources

• Databricks, Introducing Genie One, Genie Agents, and Genie Ontology (blog, the announcement and the PageRank-style ranking)
• Databricks, Databricks Launches Genie One (press release, GA of Genie One, Agents, and Code, and the more-than-50 connected applications)
• Databricks, What's new with Unity Catalog at Data + AI Summit 2026 (blog, Unity Catalog semantics feeding the ontology)
• Databricks, Curate an effective Genie Space (docs, space authors review and resolve inconsistencies)
• Databricks, Metric views: BI compatibility mode (docs, non-additive grand totals "might display incorrect values")
• Databricks, Advanced techniques for metric views (docs, recognizing non-additive measures)
• Snowflake, Cortex Sense for enterprise AI agents (blog, the grounded-context mechanism, one-time indexing cost, refresh cadence, ranking signals, and conflict escalation; note it reports a separate 24.1% to 86.3% measure, distinct from the 23-to-83 CoWork set)
• Snowflake, Snowflake CoWork: the personal work agent (blog, the 23 to 47 to 83 benchmark and the agents Cortex Sense feeds)
• Snowflake, Cortex Search: high-quality enterprise AI retrieval (engineering blog, the hybrid search with reranking Snowflake documents elsewhere)
• Snowflake, Horizon Context: the governed context layer (blog, where the definitions and lineage are stored)
• Snowflake, Semantic View Autopilot (blog, the GA auto-generator and the coding-into-curation framing)
• Snowflake, Semi-additive metrics release note (docs, the NON ADDITIVE BY clause is introduced)
• Snowflake, Using SQL commands to create and manage semantic views (docs, the semi-additive last-snapshot semantics)
• Anthropic, How Anthropic enables self-service data analytics with Claude (blog, the hand-authored skill docs drifting from ~95% to ~65% accuracy over a month)
• CIO, From RAG to ontology: Databricks bets on context as the key to trusted AI agents (analysis, the context-is-not-correctness caveat)