Snowflake Horizon Context: What It Does to the OSI

"As models become commoditized, context will be the real differentiator."

That is how Josh Klahr framed the agentic AI era when Snowflake announced Snowflake Horizon Context at Summit 26 on June 2. Klahr leads Snowflake Horizon. He also convenes the Open Semantic Interchange working group. That combination of roles is relevant to everything that follows.

The line itself is not surprising. Anyone paying attention to the data infrastructure space has been building toward that sentence for two years. Models are converging. The gap between GPT-4o, Claude Sonnet, and Gemini 1.5 is shrinking faster than the vendors want to admit. What remains differentiated is the context you feed them. Proprietary data, governed definitions, trusted business logic. That is where competitive advantage lives in the agentic era.

Then Snowflake shipped Horizon Context. And the question changed.

What Snowflake Horizon Context actually is

Snowflake Horizon Context is not a new product category. It is a named, integrated context layer inside Snowflake Horizon Catalog. It collects metadata from across your data estate, enriches it with business meaning, and activates it for every AI agent, BI tool, and Cortex consumer in your stack.

Snowflake organizes it around three functions:

Collect. Pull contextual signals from disparate sources: Tableau, Power BI, Apache Airflow via OpenLineage, external databases via connectors, and Snowflake-native metadata. The catalog becomes a single searchable hub enriched with query logs, schemas, and popularity metrics. Critically, Snowflake explicitly supports the Open Semantic Interchange standard here as one of the collection mechanisms. More on what that means shortly.

Enrich. Build and maintain semantic views through Semantic Studio, an AI-assisted IDE inside Snowflake Workspaces with Git-based versioning and CoCo integration. Or skip the manual step entirely with Semantic View Autopilot, which ingests existing SQL, Tableau, or Power BI files and generates semantic views automatically. The enrichment layer handles level-of-detail metrics, composable definitions, and materializations that rewrite queries on your behalf.

Activate. Surface governed definitions in every tool that matters. CoCo and CoWork consume them natively. BI tools including Tableau, Power BI, Excel, Google Sheets, ThoughtSpot, and Sigma query governed definitions directly. External AI agents, including those running on Claude, Cursor, or any MCP-compatible framework, get governed data access through Snowflake's MCP integration.

That third pillar is the architectural claim. One context layer, actively activated for every consumer, regardless of where the query originates.

The four context types Snowflake is capturing

Horizon Context is specific about what "context" means here. Four categories:

Structural context: what exists and how it connects. Tables, columns, lineage, schema relationships.

Operational context: what is happening. Query logs, data freshness, pipeline performance, usage patterns.

Semantic context: what it means. Metric definitions, business logic, ontologies, governed vocabularies.

Behavioral context: how it is used. Popularity scores, query patterns, which assets get consumed by which teams and tools.

These four layers working together is a materially different proposition from what a traditional data catalog or a standalone semantic layer provides. A catalog gives you structural context. A semantic layer gives you semantic context. Horizon Context, as designed, assembles all four into one continuously maintained layer.

For AI agents operating autonomously, this matters in concrete ways. An agent querying a "revenue" metric needs more than a definition. It needs to know whether the underlying data is fresh (operational), whether this metric is used consistently across the organization (behavioral), and how revenue relates to other business concepts it might need to reason across (structural). An agent that has all four layers available makes materially better decisions than one working from a definition alone.

This is also why existing text-to-SQL approaches fall short. They have structural context (the schema) and sometimes semantic context (metric definitions), but behavioral and operational context are missing. The result is a system that knows what the data is but not whether it is fresh, trusted, or used the way the business actually intends.

For a deeper look at the semantic layer foundations underneath all of this, see our Snowflake Semantic Views practitioner guide and the broader complete guide to the semantic layer.

Where this sits in the Intelligence Allocation Stack

In the Intelligence Allocation Stack framework, Layer 2 is the semantic layer: business logic translated for machines, metric definitions, governed vocabulary. Horizon Context is Snowflake's Layer 2 bet, made at the platform level.

What is significant about the Summit 26 announcement is the vertical integration. Snowflake is not just providing the semantic layer. They are connecting it to Layer 1 (the data foundation and catalog), Layer 3 (the orchestration and pipeline context), and Layer 4 (the AI agents and Cortex consumers) within a single product surface.

Constellation Research's analysis of the Summit 26 announcements noted the shift: Snowflake is no longer competing on data formats or storage efficiency. The announcements are about "meaning, trust, permissions, context, and governance." That is an intelligence allocation story, not a compute story.

This also explains the BlackRock and Indeed early customer references. BlackRock needs Horizon Context to maintain consistent business definitions across an AI analytics estate spanning asset classes, regulatory contexts, and geographies. Indeed needs it so "AI agents automatically inherit evolving business logic, keeping every system aligned without manual intervention." Both use cases depend on a Layer 2 that is active, governed, and automatically propagated, not manually maintained.

The OSI question that Horizon Context surfaces

Here is where the announcement gets genuinely complicated.

Josh Klahr leads the Open Semantic Interchange. He also announced Horizon Context. Both roles are visible, intentional, and relevant to each other. But they point in potentially different directions.

The Open Semantic Interchange, as of the v1.0 specification released in January 2026, is an Apache 2.0-licensed, vendor-neutral standard for exchanging semantic constructs: datasets, metrics, dimensions, relationships, and contexts across any platform. The explicit goal is portability. Define a metric once, use it everywhere, regardless of which cloud, which warehouse, or which BI tool you prefer. The 50+ companies participating in OSI signed up for that vision.

Horizon Context is a first-party implementation of governed context, owned by Snowflake, branded under Snowflake Horizon, baked into the Snowflake data cloud. It references OSI as one collection mechanism among several. It lists OSI-member companies, including Sigma, AtScale, Omni, and ThoughtSpot, as ecosystem partners on its product page.

Two readings of that combination are defensible, and they are not the same future.

Reading one: Horizon Context is Snowflake's OSI reference implementation

In this reading, Snowflake is doing exactly what a good standards contributor does. They built the most complete, most deeply integrated implementation of OSI principles possible, running natively on their platform. Horizon Context handles the Snowflake-resident semantic layer. OSI handles the interchange: the metadata that flows between Snowflake and Databricks, between Snowflake and dbt Labs, between Snowflake and tools that live outside the data cloud.

The OSI standard, in this reading, becomes the protocol that makes Horizon Context interoperable with the rest of the ecosystem. Snowflake is the implementation. OSI is the interface. Both are needed, and Snowflake's investment in Horizon Context makes OSI more valuable, not less, because it proves that a first-class semantic context layer is buildable and deployable at enterprise scale.

The evidence for this reading: Snowflake explicitly lists OSI as a supported collection mechanism for Horizon Context. The ecosystem partners on the Horizon Context product page are all OSI members. And Klahr's public communications around the OSI working group remain active and collaborative.

Reading two: Horizon Context is Snowflake's gravity well

In this reading, the dynamic is different. Snowflake is the data cloud used by 13,900+ enterprise customers. Those customers will adopt Horizon Context because it is the default, native, zero-additional-infrastructure path to a context layer for AI. Once the context layer lives in Snowflake, governed by Horizon, activated for CoCo and CoWork and the Cortex stack, the practical incentive to maintain separate OSI-compliant semantic definitions in external tools diminishes.

OSI becomes, in this reading, the export protocol. The standard that lets other vendors claim compatibility with whatever Snowflake's customers are already running. Portability exists on paper, but the gravity is in the cloud where the data lives. The open standard becomes the consolation prize for the vendors who could not capture the customer relationship at the platform level.

The evidence for this reading: the Horizon Context announcement does not describe OSI as foundational to the architecture. It is one of several listed collection mechanisms. The semantic layer itself is Snowflake's Semantic Views, governed by Snowflake RBAC, activated by Snowflake Cortex. A customer who goes deep on Horizon Context is building their context layer inside Snowflake. Moving that context layer to another cloud is theoretically possible with OSI. In practice, it requires rebuilding the governance model, the catalog connections, and the Cortex integrations from scratch.

What the OSI members have to decide

The OSI coalition includes dbt Labs, Fivetran, AtScale, Cube, RelationalAI, Sigma, and ThoughtSpot. Each of them now faces a positioning question that Horizon Context made more urgent.

dbt Labs and Fivetran are the most interesting case. The merger creates a combined entity with deep integration across the transformation layer (dbt), the ingestion layer (Fivetran), and the semantic layer (dbt Semantic Layer via MetricFlow). If Horizon Context is the semantic layer inside Snowflake, and MetricFlow is the semantic layer outside Snowflake (or across clouds), the combined entity could position as the OSI-native, multi-cloud alternative. That is a viable strategy, but it requires customers to care enough about multi-cloud portability to run two semantic layers simultaneously.

AtScale has staked its positioning on the universal semantic layer: one semantic definition served to every consumer, regardless of which warehouse the data lives in. Horizon Context does not change that value proposition for customers running multi-cloud architectures. It does raise the bar for how compelling AtScale's native integration with Snowflake needs to be to compete with the default experience inside Horizon Catalog.

Cube is in a different position. Provider-agnostic by design, API-first, open-source core. Horizon Context is a reason for some Snowflake-committed customers to de-prioritize Cube evaluations. It is also a validation that the semantic layer is essential infrastructure, which Cube has been arguing for years. The question is whether the customers who care enough about portability to run a separate semantic layer are a large enough market to sustain Cube's enterprise growth.

Sigma and ThoughtSpot are listed as ecosystem partners on the Horizon Context page. That tells you they have committed to integration. Whether integration means endorsement of Reading One or acceptance of Reading Two is the nuance worth watching in their respective product communications over the next quarter.

The vendors outside the OSI tent

Honeydew is warehouse-native, built to sit directly on Snowflake and define semantics where the data lives. Horizon Context is Snowflake shipping Honeydew's thesis as a first-party product. That is either a validation that makes Honeydew's positioning more defensible, or a displacement event that makes the addressable market for a third-party warehouse-native semantic layer significantly smaller. Snowflake Ventures is an investor in Honeydew, which adds a layer of complexity to how Honeydew publicly positions around this announcement.

The pattern is familiar in enterprise software. Platform vendors watch which third-party tools their customers adopt at scale, then build the winning category into the platform. The third-party tools that survive are the ones that go deeper than the platform's native implementation or serve use cases the platform chose not to prioritize. That is the strategy any semantics-first startup needs to be executing right now.

What the next 90 days will tell us

The Summit 26 announcement established what Horizon Context is. It did not settle which reading of the OSI dynamic is correct. Three data points to watch:

How do OSI working group meetings change after this announcement? If the working group focuses on interoperability between Horizon Context and non-Snowflake implementations, Reading One is happening. If the working group's energy shifts toward compliance scenarios while practical development concentrates inside Snowflake's product organization, Reading Two is the more accurate description.

How do the major OSI members position Horizon Context in customer conversations? dbt Labs, AtScale, Cube, and Sigma each have sales teams calling on Snowflake customers every week. If they frame Horizon Context as the foundation that their tools build on top of, the ecosystem is healthy. If they start positioning it as a competitive alternative to evaluate, the coalition has fragmented.

How do Snowflake's enterprise customers talk about OSI portability in architecture reviews? If customers building on Horizon Context are designing their semantic layer in a way that could be migrated to a different cloud via OSI export, the standard matters. If they are designing Snowflake-native from the start and treating OSI as an optional integration, the gravity has already set in.

Josh Klahr's thesis is correct. Context is the differentiator. Snowflake Horizon Context is the bet that the right place to own that context is inside the data cloud, because that is where the data already lives, where the governance already runs, and where the AI agents already connect.

Whether that leaves room for a portable, vendor-neutral semantic interchange as a peer standard, or reduces it to an interoperability layer for the vendors in second place, is the question the next ninety days will begin to answer.

For the full OSI member landscape and what each organization brings to the interchange standard, see our complete guide to OSI participants. For a practitioner perspective on how AI agents consume semantic context, see our architecture guide on connecting your semantic layer to AI agents. And for the Snowflake-native implementation that Horizon Context builds on top of, the Semantic Views practitioner guide covers the current state of the tooling in detail.