Who Owns Your Context Layer?

The context layer is one of the most important assets your business is building in the AI era. It is what turns a generic assistant into a reliable agent.

For analytics, it is the difference between an agent returning a confidently wrong answer and an agent returning a correct answer with a useful interpretation.

As capable as a model may be, it will consistently struggle to deliver business value without a strong context layer.

It is no surprise, then, that the context layer has become one of the most important assets every AI provider is trying to build, own, and capture.

What is a "context layer" anyway?

In the broader context of AI assistants, the context layer is any information that helps AI understand who the user is, what resources are available, what rules apply, and what the organization already knows.

For data intelligence, context includes table documentation, verified examples, conversational memory, and the organization-level knowledge that accumulates from actual usage.

How does it compare with a semantic layer?

The semantic layer is a formal abstraction layer on top of your data. It defines metrics, dimensions, entities, joins, and relationships in a governed way. A semantic layer is not a prerequisite to start producing useful AI analytics, but it can help standardize answers and control which information is accessed.

Do you own your context layer?

Since the context layer is necessary for reliable AI agents, the important question is simple: can you access it?

How easy is it for you to migrate or reuse your layer of intelligence if you want to use another solution?

Right now, few organizations really care about this question because everything is new, noisy, and trendy.

Why should you care? Incentives and pricing

The SaaS era demonstrated what happens when a vendor becomes deeply entrenched in a business's operations. Between 2010 and 2020, SaaS spending grew more than 10x. That is not the same as saying every SaaS product became 10x more expensive, but the lesson is clear: usage grows, switching costs rise, and vendors gain pricing power. During the same period, SaaS price inflation outpaced total market inflation by more than 4x.

Oracle, Stambia, and others are examples of vendors that could raise prices faster than clients could adapt and migrate to new tools.

The same dynamic is emerging in AI analytics. Snowflake Intelligence and Databricks Genie have structural pricing power because they sit close to clients' data, already have enterprise relationships, and integrating alternatives is painful.

More importantly, they are incentivized to build and keep their clients' context layer.

We wanted to understand the extent of lock-in that exists in the market. We looked for a benchmark but could not find much online, so we decided to make one.

Benchmark methodology

We scored six leading AI analytics platforms on four axes that together define how open a context layer is:

• Catalog / table documentation and metadata — Are table and column descriptions exportable, and in what format?
• Semantic layer / modeling — Are metric, dimension, and relationship definitions expressible in an open standard such as dbt MetricFlow or Cube, or only in a vendor-specific format?
• Memory and knowledge — Is accumulated learning — user context, organization context, trusted examples, feedback — accessible outside the vendor's environment?
• Conversations and traces — Can you audit and export the history of AI interactions in a structured form?

Each axis is scored 0 to 3 on the same ordinal scale:

• 0 — Not accessible; black box.
• 1 — Exportable as a snapshot; point-in-time, not synchronized.
• 2 — Accessible live; programmatic, on-demand, current state.
• 3 — Accessible live in an open format or open standard.

A note on what "open standard" means today. The four axes are not at the same level of standardization, which matters for reading the scores:

• Catalog and metadata — settled for Iceberg table catalogs, not for AI context. The Apache Iceberg REST Catalog API is a standard interface for managing Iceberg table metadata and catalog operations. It is supported across several lakehouse catalogs. But it does not settle the broader AI context layer: business descriptions, synonyms, sample values, verified examples, conversational memory, and usage-derived knowledge remain product-specific.
• Semantic layer — emerging. The first public Open Semantic Interchange specification was released in January 2026 as OSI v0.1, with an Apache-licensed repository and participation from Snowflake, dbt Labs, Salesforce/Tableau, Databricks, and others. Native OSI import/export remains early; in practice, dbt MetricFlow remains the most operational open semantic standard today. We count both dbt MetricFlow and OSI-compatible semantic definitions as valid open standards in the scoring. Sources: Salesforce on OSI v0.1 and dbt Labs on the first OSI spec.
• Memory and knowledge — no standard yet. Every vendor structures memory differently. MCP-based conventions may emerge, but there is no recognized open AI-memory standard today.
• Conversations and traces — no standard yet. OpenLineage covers data lineage, not AI reasoning paths or conversational traces.

The fifth axis: direct context access via MCP

A fifth axis matters most for actually using your own AI: direct context access via MCP. We score this 0, 4, or 8, weighted more heavily than the other four because it determines whether the openness scored above is theoretical — the context is exportable — or practical — your own agent can actually consume it.

• 0 — No MCP exposure. No meaningful MCP endpoint is available.
• 4 — Vendor-agent MCP. The MCP server lets external clients call the vendor's AI or query surface, but the context is mediated by the vendor's own agent. Your agent can ask the vendor's agent to answer, but it cannot directly inspect the underlying context artifacts: semantic definitions, verified examples, memory, traces, or documentation.
• 8 — Direct context MCP. The MCP server exposes useful context surfaces directly as tools or resources — for example models, topics, docs, projects, threads, semantic objects, or queryable data — so a third-party agent can retrieve, inspect, query, and reason over them without routing everything through the vendor's own chat agent.

Total scoring is therefore out of 20: four axes × 3, plus MCP × 8.

A separate layer, governance — RBAC, access policies, policy portability — sits adjacent to the context layer and is equally important for enterprise adoption. We have not scored it here because governance interoperability is not standardized enough to compare fairly. We may add governance as a fifth axis in a future revision.

This benchmark deliberately does not measure answer quality, breadth of integrations, UX, or pricing.

Not that those do not matter. They are simply not what we set out to measure. Plenty of work exists on accuracy. Almost none exists on portability.

Results

Platform	Semantic Layer	Catalog & Metadata	Memory & Knowledge	Conversations / Traces	MCP context	Total
Snowflake Intelligence (Cortex Analyst)	2	2	2	2	4	12/20
Databricks Genie	2	2	2	2	4	12/20
Hex Magic	3	2	2	2	8	17/20
Omni	3	2	2	2	8	17/20
Nao	3	3	2	2	8	18/20
Myriade	3	3	2	2	8	18/20*

* Myriade row is self-assessed pending external validation — see annex.

Analysis and insights

The leading warehouse providers keep doors semi-closed: 12/20

This is not surprising, nor is it a coincidence, since their economics depend on it. Snowflake and Databricks get a lot right: both expose important semantic and catalog surfaces live, and Snowflake offers a one-way bridge from dbt into Snowflake semantic views. But their MCP posture is best described as vendor-agent MCP.

You can call Cortex Analyst or Genie from external MCP-compatible clients. What you cannot do, based on public documentation, is directly consume the full underlying context layer — semantic definitions, verified queries, trusted examples, learned patterns, accumulated memory — as reusable artifacts for your own independent agent. Hence the 4/8 on MCP.

Every query routed through Cortex Analyst is a query you pay Snowflake for. Every Genie space is a workload that keeps your team, and your usage-based bill, inside Databricks.

Openness means letting workloads escape.

Hex and Omni are more open, but still product-mediated: 17/20

Hex and Omni both score 17/20. They have strong semantic-layer integration with dbt MetricFlow and expose useful MCP tools that can be consumed by external agents.

That said, they are not "raw open context files" architectures. Their MCP servers expose product-native tools and context surfaces — projects, threads, models, topics, documentation search, and query execution — rather than a universal context schema. That is enough to score 8/8 on practical MCP access, but it is still different from owning every context artifact as files in your own repository.

Nao and Myriade score 18/20, with different evidentiary status

Nao reaches 18/20 through a code-first architecture: the context layer is close to the file system. Markdown documentation, YAML configuration, dbt references, tests, and benchmarks can be versioned and read by external tools. MCP is useful, but the architecture does not depend on MCP for context portability. One caveat: Nao's repository is mostly Apache 2.0, with enterprise/commercial-licensed exceptions marked in the codebase.

Myriade also scores 18/20, but with a different architecture and a different evidence status. The product promise is a self-hosted platform that generates and maintains documentation, then exposes that context as MCP-readable markdown resources while keeping dbt definitions as source of truth. This is the right openness architecture for enterprises that want context generated and maintained for them. However, because the decisive MCP/API/dbt details are not yet publicly documented, this row should be labeled self-assessed pending external validation.

Two architectures, the same target score:

• Nao addresses data teams comfortable with code-first workflows.
• Myriade addresses enterprises that want context generated and maintained for them, with a unified platform for data-team workflows and business-team conversational analytics.

Conclusion

This will probably settle in time. Snowflake and Databricks have real track records on open standards — Polaris was donated to the Apache Foundation, Unity Catalog and Delta Lake were open-sourced — and both could extend that posture to AI context.

The incentives this round are different, though. Every Genie space and every Cortex Analyst query is a workload they keep inside. The push for openness will more likely come from customer demand than from vendor initiative.

In the meantime, if you have not tried a few solutions, what matters most for you is not openness yet. It is testing what AI can actually do for your business. Pick the tool that is easiest to start with, see what value it delivers, and learn what good context looks like in your domain.

Once you have tried a few solutions and know what works, that is when openness matters. That is when you check who lets you keep what you have built.

---

Annexes — detailed scoring with sources

Scoring conducted in May 2026. All scores are based on publicly available documentation and product announcements as of that date, except for the Myriade row, which is explicitly self-assessed pending public technical documentation.

Snowflake Intelligence — Cortex Analyst + Semantic Views

Semantic Layer — 2/3. Cortex Analyst Semantic Views are accessible live via SQL functions such as SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW — on-demand, current state, and programmatic. The format is Snowflake-specific YAML, not dbt MetricFlow or OSI. A one-way ingest bridge from dbt exists through the dbt_semantic_view package; no symmetric export is documented.
Semantic Views overview · YAML specification · Best practices · Semantic Model Generator / dbt ingest

Catalog & Metadata — 2/3. Column comments are accessible live through SQL DDL queries. Descriptions, synonyms, and sample values can be represented in semantic YAML and read through SQL functions. This is live access, but in a Snowflake-specific format.
YAML specification

Memory & Knowledge — 2/3. Verified queries can be embedded in the semantic YAML and accessed live. Some user-level feedback and monitoring information lives in Snowsight and related Snowflake-native surfaces rather than in an open API or standard memory schema.
Cortex Analyst documentation · Analyst optimization with verified queries

Conversations / Traces — 2/3. The Cortex Analyst REST API returns generated SQL and conversation responses on demand. Query history is queryable via SQL. This is live access in Snowflake-specific formats, not an open AI-trace standard.
REST API

MCP context access — 4/8 (vendor-agent MCP). Snowflake-managed MCP supports an Analyst tool over semantic views and standard MCP tools/list / tools/call. However, the Analyst tool type is CORTEX_ANALYST_MESSAGE: it invokes Cortex Analyst over semantic views rather than exposing the semantic model, verified queries, or memory artifacts as directly readable context resources for an independent agent.
Snowflake-managed MCP server

Databricks Genie

Semantic Layer — 2/3. Genie Spaces use instructions, trusted assets, and Unity Catalog Metric Views to interpret business questions. These surfaces are accessible through Databricks-native APIs and management workflows. The format is Databricks-proprietary; no native export to dbt MetricFlow or OSI is documented.
What is a Genie Space · AI/BI Genie is now GA

Catalog & Metadata — 2/3. Unity Catalog comments and related metadata are accessible live through Databricks APIs and SQL. Genie space context is managed through Databricks-native interfaces. This is live access in proprietary formats.
Set up and manage a Genie Space

Memory & Knowledge — 2/3. Public documentation supports Genie-space instructions, trusted assets, feedback workflows, benchmarks, and conversation APIs. Product announcements describe knowledge-mining capabilities. However, benchmarks are documented primarily as evaluation assets, not clearly as exported memory. Score 2 reflects Databricks-native live access, not an open memory format.
The next generation of Databricks Genie · Trusted assets in Genie

Conversations / Traces — 2/3. Conversation history is accessible through the Genie Conversation API, and SQL queries are visible in Databricks-native surfaces. There is no portable open trace format for AI reasoning paths.
Genie Spaces Conversation API

MCP context access — 4/8 (vendor-agent MCP on the AI surface). Databricks has official MCP support governed through the Unity AI Gateway. Managed MCP servers include Genie Spaces, Vector Search, Databricks SQL, and Unity Catalog functions. This is strong runtime/tool access, but public documentation does not show the Genie context layer — instructions, trusted assets, learned patterns, feedback, and memory — exposed as independently readable context artifacts.
Model Context Protocol on Databricks

Hex Magic

Semantic Layer — 3/3. Semantic Model Sync supports dbt MetricFlow, Cube, and Snowflake Semantic Views. dbt MetricFlow is an open-source semantic layer engine and can remain the live source of truth. Hex's internal semantic model is described as designed for portability.
Introducing Semantic Model Sync · Introducing Semantic Authoring

Catalog & Metadata — 2/3. Context Studio captures workspace rules, table and column descriptions, endorsements, and AI guides. Some metadata can sync from dbt schema descriptions, but the composite context layer is Hex-specific.
Context Studio

Memory & Knowledge — 2/3. Threads, workspace rules, and guides are accessible through Hex-native surfaces and MCP tools. The format is Hex-specific; no recognized open AI-memory standard exists yet.
AI in Hex documentation

Conversations / Traces — 2/3. Threads can be retrieved and continued through MCP tools such as get_thread and continue_thread, and Hex projects can be inspected in product-native formats. This is live access, but not an open AI-trace standard.
Magic AI · Hex MCP Server documentation

MCP context access — 8/8 (beta, tool-oriented direct context MCP). Hex's MCP server exposes tools such as search_projects, create_thread, get_thread, and continue_thread. This lets a third-party agent retrieve and use Hex context directly, although the MCP server is documented as beta.
Hex MCP Server documentation

Omni

Semantic Layer — 3/3. Omni integrates with the dbt Semantic Layer. dbt metrics, dimensions, measures, and entities can be read into Omni's model. The integration is one-way: Omni ingests definitions from dbt, but Omni-authored metrics are not exported back to dbt semantic files.
Integrate dbt's semantic layer with Omni · Omni + the dbt Semantic Layer

Catalog & Metadata — 2/3. Field-level descriptions and AI context are available in Omni topics and models. dbt YAML metadata can be synced in, but the composite layer remains Omni-specific.
AI in Omni documentation

Memory & Knowledge — 2/3. Topics, field-level AI context, and documentation search are exposed through Omni-native surfaces and MCP. The format is Omni-specific; no open-standard memory export is documented.
Omni AI documentation

Conversations / Traces — 2/3. Omni supports AI sessions and model-aware interactions, but public documentation should be strengthened before making a hard claim about dedicated conversation-history export APIs. Score 2 assumes live product/API access in Omni-specific formats, not an open AI-trace standard.
Omni AI documentation

MCP context access — 8/8 (query/model tools). Omni's MCP Server connects external AI tools to the Omni model. It exposes tools such as pickModel, pickTopic, getData, and documentation search. This enables external agents to query and reason over Omni-modeled data directly.
Omni AI MCP Server

Nao Labs

Semantic Layer — 3/3. Nao uses a file-system/context-builder approach: YAML configuration, dbt references, markdown definitions, skills, and MCP configuration can live in version control. When dbt MetricFlow or dbt semantic definitions are used as the source of truth, semantic context remains live and open.
Nao GitHub repository · Nao configuration docs

Catalog & Metadata — 3/3. Documentation can live directly as markdown and YAML in the repository, accessible through direct file read or MCP. This is open by construction.
Nao GitHub repository

Memory & Knowledge — 2/3. Test cases, expected SQL, context files, skills, and feedback loops can be versioned and tracked. These are accessible in open file formats, but there is no recognized open AI-memory standard yet.
Nao GitHub repository

Conversations / Traces — 2/3. Nao emphasizes transparent reasoning and file-based context. Traces can be inspected in self-hosted deployments, but no open AI-trace standard exists yet.
Nao GitHub repository · Nao Labs homepage

MCP context access — 8/8. Nao can expose a headless analytics agent through MCP, and the underlying context layer is also directly accessible as files: markdown documentation, YAML configuration, skills, and semantic definitions. License caveat: the repository license says the project is mostly Apache 2.0, with files marked /* @license Enterprise */ governed by a commercial license.
Nao GitHub repository · Nao LICENSE

Myriade

Scoring of Myriade by Myriade.

Catalog & Metadata — 3/3. Autonomous documentation generation is the core product claim. The target openness claim is that documentation is rendered as markdown, live-accessible via MCP, and consumable by any third-party agent. This specific MCP/markdown-resource claim needs public documentation.
Myriade public product page

Semantic Layer — 3/3. Claimed native dbt integration: semantic definitions remain in the customer's dbt project — MetricFlow / project YAML — and Myriade consumes them live as source of truth. This should be linked to public technical documentation before publication.
Myriade documentation (placeholder — replace with a specific technical docs page before publication)

Memory & Knowledge — 2/3. Claimed user-level and organization-level memory accessible via MCP. The protocol is open; the schema remains Myriade-specific because no open AI-memory standard exists. This should be documented publicly.

Conversations / Traces — 2/3. Claimed conversation history accessible via API and MCP in structured form. No open standard for AI reasoning paths exists; public API documentation should be published before relying on this claim externally.

MCP context access — 8/8. Claimed context layer exposed as MCP resources in markdown for direct third-party agent consumption, without needing to route through Myriade's own AI. This is the central claim to document publicly for the 18/20 score.