You're on Snowflake Horizon Context: Give Every Cortex Sense Conflict an Owner, and Fix the Data Under It

Your team already curates context in Snowflake. Semantic views hold the governed metrics. Universal Search finds the right table, view or agent by meaning. AI-generated documentation and column lineage say what each object is and where it comes from. CoCo (formerly Cortex Code) finds semantic views on its own, CoWork (formerly Snowflake Intelligence) answers business users from them, and the Snowflake-managed MCP server hands that context to agents outside Snowflake. If you joined the Cortex Sense private preview, it mines analyst query history, transformation models and BI metrics, ranks signals "by relevance, authority, popularity and freshness", and asks a human builder when two disagree. Horizon Context is where your Snowflake meaning lives and gets ranked. Data Context Wizard is where every agent reads it, next to your other engines' definitions, with a named owner on every fact. Data Workers is the agentic data platform that then acts on the data underneath, with approvals and a receipt.

The day-two question with any context layer is what happens when it finds a conflict. Cortex Sense is right to stop and ask. Data Workers adds the evidence from every engine, a named owner who decides once, and a crew that fixes the model under the semantic view so the conflict does not come back.

Key takeaways

• •Horizon Context keeps its job. Semantic views, Universal Search, Cortex Sense, CoWork and CoCo stay as they are. Data Context Wizard takes that context in today from the semantic view DDL or Ossie YAML your team exports, and your team's assistant can use the Snowflake-managed MCP server alongside it.
• •Snowflake context meets every other engine. Each semantic view metric is reconciled with its counterparts in Databricks, dbt or SQLMesh, so a disagreement shows up the morning it starts.
• •Conflicts get an owner and evidence. A conflict goes to the metric's named owner in Spellbook with lineage on both sides and the source change behind it. The decision is recorded once.
• •Data Workers fixes what is underneath. The fix lands upstream, as a diff or DDL for the view's owner, behind an approval, and is verified after it ships.
• •Start with a pilot. Read-only on the semantic views behind one domain, then one change class, on the ladder from L0 manual to L4 autonomous.

Snowflake Horizon Context is where your meaning lives. Data Workers is where every agent reads it, and the crew that keeps it right.

Snowflake built Horizon Context as "a connected, governed semantic foundation with active context for AI and BI" inside Horizon Catalog. The design suits a warehouse that serves agents: definitions sit next to the data, Snowflake roles govern them, and every Snowflake agent reads the same context. Cortex Sense adds what most teams never had time to write by hand, mined from the queries people run.

Most estates also hold meaning outside the account: a Databricks metric view for the churn model, a SQLMesh or dbt project that defines the models every semantic view reads, and source systems that change their own shape. Data Workers covers that side with one context, one approval flow and one audit trail.

Here is a Tuesday with Data Workers connected, an illustration, not a customer case.

Nothing in Snowflake failed. Cortex Sense spotted the disagreement and asked, the right behaviour for a context engine. Data Workers added the source change behind it, the lineage into both engines, the person who owns the answer and the fix in the model, so the next ranking pass starts from one definition.

Why doesn't Snowflake just do this itself?

Because Horizon Context is built to be the best place for an agent to read Snowflake, and Snowflake keeps it focused there. Cortex Sense ranks and asks rather than decides, a careful choice: a context engine that silently picked a winner between two finance definitions would be guessing on a question that belongs to the business. Its metadata connectors (private preview) bring metadata in, by design.

Settling a conflict for good is a different product. The other definition often lives in another vendor's engine, the cause sits in a source system or transformation repository Snowflake does not run, and the fix means editing that repository with approvals, rollback and receipts. That cross-engine layer, with a named owner on every decision and a crew that acts on the data, is the product Data Workers is. For the full side-by-side, read Snowflake Horizon Context vs Data Context Wizard.

Every tool owns a slice. Data Workers covers the whole lifecycle

Horizon Context owns one slice of the lifecycle, and owns it well: context for agents inside Snowflake. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail.

How Snowflake Horizon Context and Data Workers work together

People keep asking in CoWork and CoCo, and engineers in Claude Code, Cursor or Codex. Spellbook Data Catalog (in preview) is where the data team looks: every definition, its owner and every open conflict. Between them, Data Context Wizard holds one governed context graph, the Data-Agents Swarm does the work with more than 20 specialist agents, the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember), and per-domain guardrails hold approvals, receipts and rollback.

How Horizon's context comes in. Your team exports your semantic views (SHOW SEMANTIC VIEWS, DESCRIBE SEMANTIC VIEW, GET_DDL) under a dedicated read role, or its assistant reads them over the Snowflake-managed MCP server, whose SYSTEM_EXECUTE_SQL tool is read-only by default, and hands them to Context Wizard. The Data Workers Snowflake connector adds tables, grants and query history, and analyze_query_history shows which definitions people actually query. Each fact lands in Context Wizard with provenance: the view, the owner, the DDL version and when it was read.

How it is reconciled. Context Wizard reads the same concept from your other engines: Databricks metric views through the Databricks connector, dbt MetricFlow definitions through its importer, and source changes from Postgres through Debezium. Data Workers connects to SQLMesh and Dagster over their APIs today. resolve_metric returns every candidate when a name is ambiguous, and trace_cross_platform_lineage follows each one back to its source. A conflict goes to the Promotion Inbox in Spellbook and never promotes itself. Only a named person settles it; mark_authoritative records the definition the owner approved, and flag_stale_context marks one whose tables changed since it was last checked.

How it acts. Fixes land where the definition lives: a diff on the transformation project for its owner to merge, or CREATE OR REPLACE SEMANTIC VIEW DDL for the view's owner to deploy. The owner's approval and Snowflake's roles stay in charge, by design. After the change ships, Data Workers re-runs its checks on the changed tables and leaves a receipt, and the view's owner confirms the verified queries still answer the same. The Cortex Agents MCP guide shows the reverse path, with Data Workers as a tool CoWork can call.

Setup today. Follow the client setup docs: clone the open-source repository and add Data Workers agents to your MCP client next to Snowflake's managed MCP server. Example .mcp.json for Claude Code (placeholders):

{
  "mcpServers": {
    "snowflake": {
      "type": "http",
      "url": "https://<account_url>/api/v2/databases/DW_META/schemas/MCP/mcp-servers/HORIZON_READER",
      "headers": { "Authorization": "Bearer ${SNOWFLAKE_TOKEN}" }
    },
    "dw-context-catalog": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-context-catalog"] },
    "dw-schema": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-schema"] },
    "dw-quality": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-quality"] }
  }
}

On the Snowflake side, give the MCP server a SYSTEM_EXECUTE_SQL tool with read_only: true (the default) and, if you like, a CORTEX_ANALYST_MESSAGE tool, and connect with Snowflake OAuth or External OAuth (Okta, Entra ID) as a user whose default role is least-privilege. A server takes at most 50 tools, and Snowflake notes that fewer tools keep selection accurate. List each server's tools with /mcp in your client, then ask: "Read the semantic views in PRODUCT.SEMANTIC, find every other definition of active_workspaces across our engines, and show me where they disagree and why." For more on the Snowflake side, see the MCP server for Snowflake guide.

The climb, L0 to L4. Autonomy is set per domain, on top of Snowflake's own roles.

• •L0 manual. Conflicts surface when two dashboards disagree or Cortex Sense asks; someone traces them by hand.
• •L1 observe. Data Workers reads every engine's definitions and reports conflicts with evidence. It changes nothing.
• •L2 propose. Data Workers drafts the fix, a diff or semantic view DDL, for the metric's owner.
• •L3 act reversibly. For change classes with a clean record, such as rerunning the affected models after an approved fix, Data Workers queues the rerun through the orchestrator and verifies the values in every engine.
• •L4 autonomous. For a scoped domain like late loads into one schema, Data Workers queues reruns and verifies them on its own, with a receipt for each. Definition changes, descriptions and synonyms included, stay drafts for the owner at every level, and approved facts land in the Context Wizard graph.

Making a definition authoritative stays a human decision at every level. Read is it safe to let AI agents change production data for the safety model and where does our data go for data and credentials. Related guides: what Data Workers adds on Snowflake, you're on Snowflake semantic views, you're on Databricks Genie Ontology, you're on the dbt Semantic Layer and the hub, bring your own context.

What changes for your team

Horizon Context tells every Snowflake agent what your data means. Data Workers gives the data team a crew that keeps the data under that meaning right.

• •Context conflicts. The owner sees lineage on both sides, decides once, and every engine follows.
• •Incidents. A CoWork answer that moves overnight is traced to its source change, fixed and verified.
• •Data quality. Tables behind every certified semantic view carry running checks.
• •Cloud spend. Snowflake credits are traced to the query and dbt model behind them, and each fix goes to its owner drafted.
• •Audits. Every definition carries its source, owner, last approver and lineage.
• •Migrations. Tables move in approved waves, each planned with its parity checks; the DDL that repoints each semantic view goes to its owner, and the verified queries rerun after.

Keep Snowflake Horizon Context, or consolidate?

Keep Snowflake Horizon Context if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.

For most Snowflake shops the answer is to keep it. Horizon Context is where CoWork, CoCo and Cortex Agents read your meaning. What teams consolidate is everything around it: the spreadsheet mapping each semantic view to its Databricks counterpart, the second glossary, the hand-run checks on fact tables, and the Slack thread where conflicts wait. If you are weighing building this layer yourself on Snowflake's MCP server and a coding agent, read build it ourselves with Claude Code and MCP servers first: reading context is the easy part; reconciliation, ownership, approvals and rollback are the work.

The case for your CFO

The outcome: you invested in Horizon Context so CoWork and every Snowflake agent answer from governed meaning. Data Workers makes that meaning hold across every engine you run, so active workspaces in CoWork matches the churn model and the board pack, and a named person signed off on it.

The risk story: the real exposure is two engines quietly answering the same question two ways, found after a board deck ships. Snowflake roles, policies and the MCP server's read-only settings stay as they are. Autonomy is set per domain, from L0 manual to L4 autonomous: at L1 Data Workers only reads and reports; at L2 it drafts changes your owners apply. Every change has a named approver and a rollback path, and every receipt shows what changed, who approved it, which checks ran and how to undo it. Zero migration: Snowflake, your transformation project and your deploy process stay where they are.

Why now: every platform in your estate shipped its own context engine this year. The more agents read from them, the more a disagreement between engines costs. The first win is the semantic views behind one domain, read-only, every open conflict in front of its owner. What stays the same: Horizon, Cortex Sense, your semantic views, roles and review process. For the numbers, see the ROI of agentic data operations. Start with a pilot (pricing); the pilot is credited in full against the first year.

The sentence to repeat upstairs: "Horizon stays where Snowflake's agents read our context; Data Workers makes every engine agree with it, with an owner's approval and a receipt on every change."

Getting started

Start with a pilot. Pick the semantic views behind one domain, such as product usage or revenue, bring them into Data Workers from your team's export, next to the other engine that holds the same metrics, and let it put each conflict in front of its owner with the evidence. Then turn on the first change class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.

FAQ

Does Data Workers replace Horizon Context or Cortex Sense? No. Horizon Context stays where Snowflake's agents read context, and Cortex Sense keeps ranking it. Data Workers reconciles that context with your other engines and acts on the data underneath.

Cortex Sense already flags conflicts. What does Data Workers add? An owner and the evidence. Cortex Sense asks its builder which signal is right. Data Workers routes the conflict to the metric's named owner with lineage into every engine and the source change behind it, records the decision, and fixes the model so the conflict does not return.

How does Data Context Wizard read Horizon's context? Over the Snowflake-managed MCP server with a read-only SYSTEM_EXECUTE_SQL tool, or SQL under a read role (DESCRIBE SEMANTIC VIEW, GET_DDL), plus tables, grants and query history through the Data Workers Snowflake connector. It does not need a Cortex Sense API: it finds conflicts from the definitions it reads.

Will Data Workers change our semantic views? Only through their owners: as a diff for the owner to merge when the view is built from your transformation project, or as CREATE OR REPLACE SEMANTIC VIEW DDL for the view's owner to deploy. Data Workers doesn't deploy semantic view DDL itself at any level. Approved definitions land in the Context Wizard graph, and your team's MCP client can apply the DDL where your Snowflake MCP server allows writes.

Horizon's metadata connectors will bring in dbt and Tableau. Do we still need this? Those connectors bring metadata into Horizon for Snowflake's agents, which is useful. Data Workers covers the engines you run beyond them, settles disagreements with a named owner, and fixes the data under the definition.

Which definition wins when Snowflake and Databricks disagree? The one your owner approves. Data Workers shows both with their lineage, records the decision and proposes the change that brings the other engine in line.

Sources

• •Snowflake blog, June 2, 2026, Horizon Context (definition; labelled GA there: CoCo semantic view discovery, Semantic View Autopilot, AI-generated documentation, column lineage, MCP; private preview: estate-wide search, metadata connectors for PostgreSQL, SQL Server, Tableau, Power BI and dbt, Advanced Semantics, Semantic Studio), https://www.snowflake.com/en/blog/horizon-context-governed-context/ (checked Oct 2, 2026)
• •Snowflake product page, Horizon Context (statuses as labelled there: Universal Search GA; MCP integration and CoCo public preview; Semantic View Autopilot private preview. Where the June 2 blog and this page disagree, this page avoids the label), https://www.snowflake.com/en/product/features/horizon-context/ (checked Oct 2, 2026)
• •Snowflake blog, June 30, 2026, Cortex Sense (sources, ranking "by relevance, authority, popularity and freshness", conflicts surfaced to the human builder, private preview from mid-July 2026; no Cortex Sense API described), https://www.snowflake.com/en/blog/enterprise-ai-agents-grounded-context/ (checked Oct 2, 2026)
• •Snowflake documentation, Snowflake-managed MCP server (tool types CORTEX_AGENT_RUN, CORTEX_SEARCH_SERVICE_QUERY, CORTEX_ANALYST_MESSAGE, SYSTEM_EXECUTE_SQL and GENERIC; read_only defaults to true; maximum 50 tools per server; 250 KB truncation; DEFAULT_ROLE; Snowflake OAuth by default, optional External OAuth, programmatic access tokens), https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp (checked Oct 2, 2026)
• •Snowflake documentation, Universal Search (object types incl. semantic views and agents), https://docs.snowflake.com/en/user-guide/ui-snowsight-universal-search (checked Oct 2, 2026)
• •Snowflake release note, September 3, 2026, external lineage GA, https://docs.snowflake.com/en/release-notes/2026/other/2026-09-03-external-lineage-ga (checked Oct 2, 2026)
• •Data Workers client setup docs, https://dataworkers.io/opensource-docs/client-setup/, and the open-source repository https://github.com/DataWorkersProject/dataworkers-claw-community (start-agent.sh and the tool definitions named above) (checked Oct 2, 2026)