Snowflake Horizon Context vs Data Workers: One Approved Context for Every Agent, on Every Platform

At Summit 2026, Snowflake announced Snowflake Horizon Context, a governed semantic foundation with "active context" for AI and BI inside Horizon Catalog. On June 30 it followed with Cortex Sense, a runtime context layer that assembles meaning from query history, transformation models and BI metrics and ranks it for agents. Both start from a point we agree with: agents are only as good as the context they can trust. If you're weighing Horizon Context and Cortex Sense against a context layer that spans your whole estate, this page is for you.

Your estate probably looks like this. Snowflake is the warehouse, and finance's metrics live in semantic views. The ML team runs Databricks. Marketing's data sits in BigQuery. dbt builds the models, Airflow schedules them, and Looker and Tableau sit on top. Each system holds part of what "active customer" means.

Horizon Context makes Snowflake the best place for an agent to read Snowflake. Data Workers makes every agent read the same approved definition, wherever it was written. Data Workers is the agentic data platform: it runs the whole data lifecycle, and its Data Context Wizard keeps one governed context graph across every platform, where every fact carries its source and nothing becomes authoritative until a named person approves it. Semantic views stay the right home for Snowflake metrics, and CoWork and CoCo are great places to ask questions of Snowflake data. Data Workers keeps every agent on the same approved answer across the rest of the estate, and runs the fixes when that answer breaks.

Key takeaways

• •One approved context across the estate. Data Workers keeps one graph across Snowflake, Databricks, BigQuery, dbt and Airflow, with provenance on every fact and a named approver behind every definition. BI tools connect over their API or MCP today.
• •Snowflake leads on its own surface. Semantic views and Universal Search are GA, CoCo finds semantic views automatically, and CoWork is a great place to ask questions of Snowflake data.
• •Status, as Snowflake states it. Horizon Context's core is GA; its third-party metadata connectors, Semantic Studio and estate-wide search are private preview. Cortex Sense is private preview. Databricks and BigQuery aren't named as metadata sources.
• •Ranking isn't approval. Cortex Sense ranks context and asks a builder when definitions conflict. Data Workers routes the conflict to the owner, and an authority guard in the write path stops anything becoming canonical without them.
• •Definitions from outside Snowflake. The Context Wizard imports dbt MetricFlow, Databricks metric views and Wren MDL, types dbt models into semantic dimensions, and analyses Snowflake query history and cost.
• •Context that runs the fixes. The same graph drives the Data-Agents Swarm and the Autonomous Data-Conductor, which fix problems across systems with a receipt on every change and write what they learned back.

For what Data Workers adds across a whole Snowflake stack, read Data Workers on Snowflake. For the stage-by-stage path, read From Snowflake to an autonomous data platform, and for the executive version, the Snowflake data leader's guide. This page is the choosing view, focused on context.

Six things you get with Data Workers on top of Snowflake Horizon Context

1. One graph across every platform. Data Context Wizard reads Snowflake, BigQuery, dbt and Airflow into one graph, from a library of 50+ connectors, and reaches Looker and Tableau over their APIs or MCP today. An agent asking about a Snowflake table also sees the dbt model that reads it and the dashboard it feeds.

2. Provenance on every fact. Every fact records its source, the actor that wrote it, confidence, authority tier, when it was observed and when it was last confirmed, and it's stored tenant-isolated. When a fact is seen again, its confidence rises instead of creating a duplicate.

3. Nothing authoritative without a named approver. An authority score decides what a person reviews first. A named person decides what becomes authoritative. The authority guard sits in the write path, in code, and the reviewer field never holds an agent, so no agent can promote its own output.

4. Every metric definition lined up. The Context Wizard imports dbt MetricFlow, Databricks metric views and Wren MDL, and puts each variant next to the owner's approved definition. A drift detector flags when a definition moves away from the approved one. Semantic views stay the source of truth inside Snowflake; Data Workers takes them in from the DDL or Ossie YAML your team exports today.

5. Context that runs the fixes. The Autonomous Data-Conductor uses the graph to trace an incident across systems, and the Data-Agents Swarm uses it to scope a change before making it. Fixes are verified downstream, and every change leaves a receipt.

6. One review queue for context changes. Proposed definitions, owner changes and conflicts land in one inbox in Spellbook Data Catalog (in preview), next to every other change agents propose.

One definition, five systems

Here is a morning most multi-platform teams will recognize. It's an illustration, not a customer case.

• •09:02, dbt. The growth team changes active_customers in MetricFlow from 30 to 28 days. The PR merges and the BigQuery mart rebuilds.
• •09:40, Airflow and Databricks. The DAG churn_daily recomputes a Databricks metric view that treats 90 days without activity as churned.
• •10:15, Snowflake. A VP asks CoWork for active customers. The semantic view (paid accounts with a login in the last 30 days) answers 41,200.
• •10:20, Looker. The board dashboard, built on BigQuery, shows 44,900.
• •10:25, Cortex Sense. It ranks the governed semantic view highest and answers consistently inside Snowflake. The MetricFlow change and the Databricks view aren't in its sources.

Inside Snowflake, the right definition usually wins, because governed semantic views outrank inferred ones. The trouble starts when the definitions that disagree live outside Snowflake. That's the ground Data Workers is built for: it saw the change at 09:05, an hour before two numbers reached the board, and the owner settled it with one approval.

What Snowflake Horizon Context and Cortex Sense cover, as of October 2026

Two Summit 2026 renames matter here: Snowflake Intelligence is now CoWork, and Cortex Code is now CoCo. In July, Open Semantic Interchange (OSI) became Apache Ossie, incubating at the Apache Software Foundation. Horizon Context is an umbrella: Snowflake labels its parts one by one. Here is what Snowflake's own pages say, using the more conservative status where they disagree.

Semantic views are the strongest piece of this. They give an agent a governed definition to answer from inside Snowflake, and CoCo now finds them without being told where to look.

One platform, not one more tool

Context is one stage of a data team's lifecycle. The same team writes quality checks, handles incidents, changes pipelines, runs migrations, manages access, protects sensitive data, cuts spend and keeps models fed. Each point tool adds another console, another contract and another handoff.

Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail. We score the same ten lifecycle stages on every comparison page. Here we've scored Snowflake's native context stack: Horizon Catalog including Horizon Context, Cortex Sense, Data Metric Functions (DMFs) and semantic views. Snowflake leads on analytics and insights, and on catalog and context we score level: Snowflake goes deepest on its own data, and Data Workers covers every platform.

Snowflake Horizon Context vs Data Workers on the outcomes you buy

This view scores eight outcomes a data leader pays for when the goal is context agents can trust. Snowflake leads on two, both on its own surface: answers from semantic views and metrics served into BI. We're even on usage signals from query history. Data Workers leads on every outcome that spans platforms or decides what's trusted.

The scores measure scope, not answer quality. They're directional judgments, not benchmarks, and the reasoning is shown so you can argue with any line.

Where Snowflake Horizon Context stops

Each limit below comes from Snowflake's own pages. None is a flaw. Snowflake's context products exist to make the Snowflake account the best place for agents to work, and a context layer centred on your account is a sensible way to build that.

It's Snowflake-first. Horizon Context builds on Snowflake metadata, semantic views, lineage and query history. Third-party metadata comes through connectors in private preview, and the named sources are PostgreSQL, SQL Server, Tableau, Power BI and dbt. Databricks and BigQuery aren't on the list.

Ranking isn't approval. Cortex Sense ranks context "the way web search ranks pages: by relevance, authority, popularity and freshness." A popular join can still be the wrong one, and a newer definition isn't always the approved one. When it finds a conflict, Cortex Sense surfaces it to the Cortex Sense builder and asks a human to settle it. Snowflake doesn't document a named owner or a certification step that makes a definition canonical.

The cross-platform pieces are the newest. The core (semantic views, Universal Search, CoCo discovery) is GA. The parts that reach beyond Snowflake, the metadata connectors and estate-wide search, are private preview, and so is Cortex Sense.

Semantic interchange has limits. Importing Apache Ossie YAML supports spec 0.1.1. Fields without a SNOWFLAKE or ANSI_SQL expression are skipped without an error, so a definition written for another engine can arrive incomplete.

Context informs. It doesn't fix. Nothing in the context stack owns a broken pipeline, checks that a fix held, or records the outcome for next time.

Why doesn't Snowflake just do this itself?

Because Snowflake built Horizon Context for a clear job, and it does that job well. Its design centre is the Snowflake account: semantic views, policies and query history that Snowflake governs end to end. Ranking context by usage and authority is the right design when every definition sits under one set of Snowflake roles and one audit log. Asking a builder to settle conflicts is a sensible default for a context layer that informs answers and doesn't change systems.

Owning definitions across Databricks, BigQuery, dbt and Looker is a different product. A context layer that decides what's canonical everywhere has to record who approved each definition, block agents from promoting their own output, and keep provenance an auditor can follow on platforms Snowflake doesn't run. Going one step further and acting on that context means writing to production systems across the estate: scoping the blast radius of a change, getting it approved, rolling it back, leaving a receipt, and carrying liability for changes in tools Snowflake doesn't own. A warehouse vendor has good reasons to keep that risk out of its own product. That product is Data Workers.

Where the two overlap

"Both" means Data Workers works alongside the Snowflake capability.

Where Data Workers wins in a mixed estate

Keep semantic views as the source of truth for Snowflake metrics, and keep CoWork and CoCo for questions about Snowflake data.

Run everything that crosses platforms on Data Workers. It imports the definitions that live in dbt and Databricks, lines them up with the owner's approved one, and hands every agent the same answer, including your coding agent and the Data Workers agents that act on it. It shows where each fact came from and who approved it. Nothing moves: Data Workers stores metadata and scrubbed facts about your data, not copies of your tables.

What it costs

Snowflake's Service Consumption Table, effective October 2, 2026, has no line item for Horizon Context, Cortex Sense or the managed MCP server; usage bills through the features they call. Table 6(d), which covers Snowflake AI features, CoWork, Cortex Agents and Cortex Analyst via CoWork or Cortex Agents, bills AI Credits per million tokens by model. The Cortex Analyst API bills 67 Platform Credits per 1,000 messages, and Cortex Search bills 6.3 AI Credits per GB-month indexed. The Cortex Sense announcement mentions a one-time indexing cost without a rate.

Data Workers is priced the other way round. The Apache 2.0 core is free. A pilot is $7,500 one-time. Scale starts at $1,000 a month and Enterprise at $3,000 a month (billed annually). Seats are unlimited, there's no usage meter, and there's no markup on model spend because you bring your own model. See pricing. The only Snowflake credits Data Workers uses are for the queries it runs under the role you grant.

The fastest first win: the metrics in your board deck

Pick the ten or so metrics that go in front of the board. Connect Snowflake with a scoped role, then your dbt project and one other platform where those metrics are also defined. Each owner records the approved definition, starting from the semantic view. The Context Wizard imports the MetricFlow and Databricks metric view versions, lists every conflict with its sources, and routes it to the owner in Spellbook. Within a pilot you have an approved definition for each board metric, a record of who approved it, and every agent reading the same one.

What each Data Workers product adds next to Snowflake Horizon Context

Data Context Wizard. One governed graph across warehouses, lakehouses, dbt, orchestration and BI. It scrubs PII before storage, isolates each tenant, keeps a tamper-evident audit and supports GDPR right-to-be-forgotten. We make the full case in Why the Data Layer Needs Its Own Context Layer.

Spellbook Data Catalog. Where people review what agents propose, context changes included: approve, steer, send back or roll back, with asset pages that cover the whole estate. Horizon stays the enforcement point for Snowflake objects. For how an agentic catalog compares with a platform catalog, see Knowledge Catalog vs Spellbook Data Catalog.

Data-Agents Swarm and Autonomous Data-Conductor. 20+ specialist agents and the conductor that runs them read the graph before they act. Each agent is an MCP server your coding agent can call. Fixes are verified downstream, and what each fix teaches goes back into the graph.

Guardrails for context and for change

Snowflake governs context inside the account well: Horizon enforces RBAC, masking and row-access policies, and Autopilot suggestions wait for a user to review and apply them. Data Workers adds controls for context and change across the estate:

• •Every fact has provenance: source, actor, confidence, authority and time observed, stored tenant-isolated.
• •Promotion needs a named approver. The authority guard is enforced in code, in the write path.
• •Autonomy is set per domain. Context upkeep can run at L3 (act, reversibly) while definition changes stay at L2 (propose).
• •New deployments start observe-only.
• •Every action is approved or reversible, with a tamper-evident receipt.
• •Least privilege. Data Workers reads Snowflake with the role you grant, so Snowflake's policies still apply.

"Snowflake's MCP server already gives any agent our semantic views. Isn't that a cross-platform context layer?"

The managed MCP server is GA in Snowflake's docs, and it lets Claude, Cursor and other agents call Cortex Analyst on your semantic views, Cortex Search and SQL. Your coding agent can call it next to Data Workers.

It's still context from one platform, served under Snowflake's rules. The docs set limits: 50 tools per server, SQL and generic tool responses truncated at 250 KB, and sessions under the user's default role with secondary roles off by default. The agent gets Snowflake's answer with nothing to reconcile it against the Databricks or BigQuery answer next door. A cross-platform context layer has to hold all of those definitions, say where each came from, and record who approved the one that counts. MCP is the transport. The graph and the approval are the product, and that's what Data Workers ships.

How it fits together

There's no migration. Connect Data Workers to Snowflake with a scoped role, then add your dbt project, your orchestrator and your other platforms. The Context Wizard reads Snowflake query history and cost and imports the definitions that live elsewhere. Every agent starts observe-only, and the first thing you see is the list of definitions that disagree across platforms, each with its sources. The Databricks equivalent of this comparison is Databricks Genie and ontology vs Data Workers.

The case for your CFO

The outcome. One approved definition for every board metric, read by every agent and dashboard, with a record of who approved it. Fewer weeks lost reconciling numbers that differ by platform, and fewer decks corrected after they ship.

The risk story. At L1 Data Workers only observes. At L2 it flags and proposes; a named owner approves. At L3 it acts only on reversible changes, and L4 autonomy is something you grant per domain, never by default. Every change leaves a receipt with the diff, the approver, the blast radius and the rollback path, and fixes are verified downstream. Nothing migrates: Snowflake stays the warehouse and semantic views stay in charge of Snowflake metrics.

Why now. In 2026 Snowflake, Databricks and dbt each shipped their own context layer for agents. Each is right on its own platform, and each multiplies the places a metric can drift.

The first win. The board-deck metrics: Snowflake, dbt and one more platform, owners approving one definition each, and a list of every variant with its source.

What stays the same. Snowflake, semantic views, CoWork, CoCo and Horizon policies. Your team's tools stay, and the coding agent your engineers already use is the way in.

The path. Start with a pilot. It's $7,500 one-time and credited in full against the first year; see pricing.

The sentence for upstairs: "Snowflake ranks context for Snowflake; Data Workers gets one named owner to approve each definition once, and every agent on every platform uses it."

When Snowflake Horizon Context alone is enough

Horizon Context can be enough if everything that matters runs in Snowflake and your main need is answers in CoWork and CoCo. Once metrics are also defined in dbt, a Databricks workspace or a second warehouse, you need one approved definition that every agent reads, wherever it was written, and that's the job Data Workers does.

FAQ

What is Snowflake Horizon Context? Snowflake Horizon Context is a capability set inside Horizon Catalog that gives agents and BI a governed semantic foundation for Snowflake data. Announced at Summit 2026, its core (semantic views, Universal Search, CoCo semantic view discovery) is GA, and its third-party metadata connectors, Semantic Studio and estate-wide search are private preview. Data Workers is the cross-platform context layer teams run around it.

Snowflake Horizon Context vs Data Workers: which should I choose? Choose Data Workers if your definitions live on more than one platform, if you need provenance an auditor can follow, or if a named person has to approve what becomes canonical. Horizon Context on its own suits a Snowflake-only estate whose main need is answers in CoWork and CoCo.

What is Cortex Sense, and is there an alternative? Cortex Sense is Snowflake's runtime context layer, in private preview, that assembles context from query history, transformation models and BI metrics and ranks it for agents. Data Workers is the alternative for teams whose context spans platforms: it analyses the same Snowflake query history and adds named-owner approval and provenance across the estate.

Does Data Workers replace semantic views? No. Data Workers keeps semantic views as the source of truth for Snowflake metrics and lines up the definitions from dbt MetricFlow and Databricks metric views against the owner's approved one.

Can't we just export everything through Apache Ossie? Ossie is a good direction, and Snowflake can import and export semantic views as Ossie YAML today in preview. The import supports spec 0.1.1 and skips fields without a SNOWFLAKE or ANSI_SQL expression, so definitions written for other engines can arrive incomplete. Interchange also doesn't decide which definition is approved.

How much does Data Workers cost? Data Workers' Apache 2.0 core is free. A pilot is $7,500 one-time, Scale starts at $1,000 a month and Enterprise at $3,000 a month, billed annually, with unlimited seats and no usage meter. See pricing.

What does Data Workers store? Data Workers stores metadata and scrubbed facts about your data (definitions, lineage, owners and incident history), not copies of your tables. Enterprise can run in your own VPC.

Sources

Sources for Snowflake capabilities and statuses: Snowflake documentation, release notes, blog posts and press releases current as of October 2, 2026, including the Horizon Catalog press release (June 2, 2026), Horizon Context blog (June 2, 2026), Horizon Context product page, Cortex Sense blog (June 30, 2026), CoCo Desktop v1.21.6 release notes, CoWork press release, external lineage GA note (September 3, 2026), Semantic View Autopilot, Apache Ossie import, Apache Ossie announcement (July 8, 2026), managed MCP server, catalog-linked databases, DMF anomaly detection and the Service Consumption Table (effective October 2, 2026). Several Summit 2026 features show different statuses across Snowflake's own pages; we've used the more conservative one and named both where they differ. If we've got something wrong, tell us and we'll fix it.