Two Summits, Same Blueprint

The short version

• Within two weeks in June 2026, Snowflake and Databricks shipped the same blueprint: an AI coworker, reusable agents, and an auto-assembled "context layer" to ground them.
• Almost everything marketed as a context layer, semantic layer, or ontology runs on one of five mechanisms: retrieve, rank, generate SQL, traverse, reason.
• The new auto-assembled layers rank candidate definitions and surface the most trusted one. That selects meaning rather than traversing or deriving it, and a trusted definition can still produce a wrong number.
• Both headline accuracy figures (Snowflake 47% to 83%, Databricks 52% to 84.5%) are internal, vendor-run benchmarks on undisclosed question sets.
• Architecture shows on cross-domain, multi-hop questions that must be explainable. An eight-question checklist turns the lens into an evaluation tool.

Within two weeks this June, Snowflake and Databricks shipped the same blueprint: an AI coworker, reusable agents, and an auto-assembled "context layer" to ground them, each backed by a strong internal benchmark (Snowflake reporting a jump from 47% to 83% accuracy, Databricks from 52% to 84.5%).

The category question is settled: whether a vendor has a context layer no longer separates them. The real differences live in how that layer is built, governed, and reasoned over. This is the lens I use to read these announcements, independent of any vendor, and the one I would suggest you carry into your own testing. For disclosure: I work on zaimler, the unified context layer for agentic AI.

Five mechanisms, one word

Almost everything marketed as a "context layer," "semantic layer," or "ontology" runs on one of five distinct mechanisms, each more capable than the last. The vocabulary is shared across all five, which is what makes the space hard to read. Naming the mechanisms makes it legible.

Mechanism 1: Retrieve. Search text and metadata for passages similar to the question, and hand the top matches to the agent. This is where catalogs, RAG (retrieval-augmented generation), and vector patterns live.

Mechanism 2: Rank, then retrieve. Same mechanism, but candidate definitions have more mature scoring (e.g., by authority, popularity, and freshness) and the most trusted one wins. This is where the new auto-assembled layers sit: Databricks Genie Ontology with its OntoRank scoring, and Snowflake's forthcoming Cortex Sense.

Mechanism 3: Generate SQL from a schema model. Annotate fields and joins so the agent can compose SQL against your tables. These mechanisms can span schemas and databases within one platform. Cortex Analyst, Databricks metric views, and Microsoft Fabric semantic models live here.

Mechanism 4: Traverse a typed entity graph. Resolve entities across sources, then traverse typed relationships at runtime, multi-hop, with provenance. This is where most products claim to be. Few are.

Mechanism 5: Validate and reason. Constraints that reject invalid assertions, and formal inference that derives new facts. No major product ships this today. Be skeptical of the claim.

Credit where it is due: Jessica Talisman's "Not an Ontology" reaches this same reading product by product, concluding that Cortex Analyst and OSI (Open Semantic Interchange) describe, Genie ranks, Fabric IQ traverses on a schedule, Foundry runs procedures per action, and Snowflake's ontology materializes a fixed set of derivations, with reasoning the one capability none of them ships. The spectrum above generalizes that observation into an evaluation tool you can point at any product.

(This spectrum is one side of a lens. The other side is the path a builder climbs, which I laid out in Most "Ontologies" Don't Reason. Build Yours in the Right Order Anyway. A product runs one mechanism; a builder accumulates structure. If you are evaluating, start here. If you are building, start there.)

Two honest observations follow from the summits.

First, ranking is not reasoning. A layer that returns the most trusted definition (mechanism 2) is a real improvement on similarity search, but it selects meaning. It does not traverse or derive it.

Second, ranking is not correctness. The most authoritative definition can still produce a wrong number, because whether a calculation is valid lives in the transformation code, not in how trusted the definition is. Summing daily distinct-user counts to get a monthly total is the classic case: the definition can be certified and still double-count people.

Neither point is an attack on any vendor. Both are structural, and both survive better context.

Where the architecture actually shows

Ask one question of any product that says "ontology": which mechanism is actually running? Does it retrieve meaning, rank it, generate SQL from it, traverse it, or reason over it? The word spans all five. The architecture does not.

Most demos run on mechanism 3 questions: well-defined, single-domain aggregates, where almost every modern platform looks strong. The architecture only reveals itself on the hard slice: cross-domain, multi-hop, "why did this happen" questions that must be explainable. That slice is where regulated and customer-facing work lives. Test it deliberately, and inspect not just whether the answer is right, but whether you can see how it was derived.

A few cross-cutting notes worth carrying into testing:

• Benchmarks are internal. Both headline accuracy figures are vendor-run on vendor platforms, on undisclosed question sets. Take them as signal rather than proof; the reproducible test is your own hard questions.
• Automation still needs a human. Auto-assembled context (mechanism 2) infers definitions from usage and authority signals. Inferring meaning without an expert confirming it is the most common source of confident, wrong answers. Favor approaches that treat inference as a draft to validate rather than a verdict. (This is also why human validation sits at the very foundation, rung 0, of the builder's ladder.)
• Federation stops at the platform boundary. Semantic layers now span schemas and databases within one platform. Modeling and querying across genuinely separate platforms is a different claim, and each named product is bound to its own ecosystem: Cortex to Snowflake, Genie to Databricks, Fabric to OneLake.
• Sovereignty has two halves. Residency (where reasoning runs, what leaves your boundary) and portability (whether the meaning can be exported as open structure other tools can use). Talisman's piece makes the portability half especially well; most context layers keep meaning inside the vendor runtime. Decide your requirement on both before you evaluate.

An evaluation checklist

These are the questions I would put to any talk-to-data or agentic approach. They surface the structural differences the demos tend to hide.

1. Which mechanism is it? Retrieve, rank, generate-SQL, traverse, or reason. Knowing the mechanism tells you what the layer can and cannot do on hard questions.

2. Does it resolve entities, or just describe fields? Field descriptions help an agent write SQL. Resolved entities let it reason about a thing rather than a column. Can it hold one governed notion of Customer or Policy across tables and sources? The hard questions need that.

3. What happens on a multi-hop, cross-domain question? Routine aggregations look strong everywhere. Architecture only shows on questions that connect several entities across boundaries. Test a real "why did this happen" case that spans systems.

4. Ranking versus correctness. When it surfaces a definition, does anything check that the calculation built on it is valid, or only that the definition is trusted? A trusted definition can still yield a wrong number.

5. Can you see the reasoning? Does the answer carry a traceable path back to source, or just a result? Explainability is structural: it has to be designed into the answer path. In regulated contexts an unexplainable correct answer is still a liability.

6. Is human validation built in? When the system infers a definition, is an expert asked to confirm it before agents rely on it? Draft-then-validate is a sign of maturity.

7. Cross-platform federation, or one ecosystem? Can it model and query across genuinely different clouds and systems without consolidating first? Most enterprises are multi-cloud. Most context layers are not.

8. Sovereignty, both halves. Where does reasoning run, and can the meaning be exported as open structure? A layer that locks meaning inside one vendor's runtime narrows your options later.

The lens stands on its own, whatever you end up buying. The demos will keep getting better; the five verbs underneath them will not change, and the questions above are how you read which one is actually running.

Further reading: my companion essay Most "Ontologies" Don't Reason. Build Yours in the Right Order Anyway. (the builder's side of this lens); Jessica Talisman, "Not an Ontology" (Intentional Arrangement, June 2026), whose analysis of sovereignty and the reasoning gap informs the framing here; the Databricks Genie Ontology announcement; Snowflake's Ontology-grounded Reasoning with Cortex Agents; Microsoft's Fabric IQ ontology documentation.