Already on Snowflake? What Data Workers Adds on Top of Cortex Agents, CoWork, CoCo and Horizon

You run Snowflake as your warehouse. You probably also have dbt, Airflow, a Databricks workspace the ML team uses, Postgres and SaaS sources coming in through Fivetran or Openflow, and Tableau or Power BI on top. The incidents and the access-request backlog pile up where those systems meet.

Here's a question we got from a customer recently, close to verbatim: "From what I'm reading, Snowflake's agents support MCP and can collaborate across platforms. Is that not the case?"

It is the case. Snowflake has had a GA managed MCP server since November 2025, Cortex Agents can call remote MCP servers, and at Summit 2026 it rebranded its agent products as CoWork (formerly Snowflake Intelligence) and CoCo (formerly Cortex Code) and launched Horizon Context as a governed context layer. If you're a Snowflake shop, you have more agent infrastructure than you did a year ago.

CoWork is the right tool for asking questions of well-modeled semantic views. It's the wrong system of record for running an estate. Nothing in Snowflake's agent stack owns fixing a problem, and nothing outside the account is governed by it.

Ask CoWork about Snowflake data. Ask Data Workers about the whole estate, and hand it everything that has to be fixed, approved or paid for.

Key takeaways

• •Data Workers turns your Snowflake estate into an autonomous data platform. Cost optimization, migrations, incidents, governance and catalog upkeep run on their own, across every cloud you use, at whatever autonomy level you choose per domain.
• •Horizon stays the lock on Snowflake objects, semantic views stay the source of truth, and CoWork stays the place to ask questions. Data Workers is the back office for everything that needs fixing, and the review queue for anything that writes back into Snowflake.
• •Snowflake agents act inside Snowflake. Outside it, they reach other systems through MCP connectors or stored procedures that call external APIs. That's a tool call, not a governed operation with blast-radius scoping, review and verification.
• •Snowflake has no documented equivalent of an ops agent that owns incident-to-resolution. Data Workers' Autonomous Data-Conductor runs detect → diagnose → fix → review → verify across Snowflake, dbt, Airflow, Databricks and BigQuery.
• •Horizon Context is Snowflake-first. Its third-party metadata connectors are in private preview and metadata-only. Data Context Wizard is one governed graph across every platform from day one.
• •The cost curves point in opposite directions. Cortex Agents and CoWork bill per token in AI credits, and their tools also use warehouse compute. Data Workers is a flat platform fee with unlimited seats and no usage meter.
• •MCP isn't the difference. The difference is who owns the operating model: one vendor's perimeter, or a neutral layer across all of them.

This guide compares what Snowflake covers with what Data Workers adds. For the step-by-step path from a traditional data team to an autonomous data platform, read From Snowflake to an autonomous data platform. For the leadership view, read You built on Snowflake. Now make it agentic & autonomous.

Six things you get on top of Snowflake

1. A data platform that runs itself, not just a smarter account. CoWork and Cortex Agents make the Snowflake account agentic: people ask, and agents help. Data Workers goes further. The back office (governance, compliance, pipelines, catalog upkeep, cost and incidents) runs on its own, and your team moves up an autonomy ladder from observe-only to fully autonomous one domain at a time. Snowflake has no ops agent at all today. No platform vendor offers an autonomous data platform across a mixed estate.

2. One control plane across every cloud, with no migration. Connect Snowflake, Databricks, BigQuery, dbt, Airflow and your BI tools. Nothing moves. You get one context graph, one review inbox and one autonomy policy across all of them. Snowflake's catalog links let you read other platforms. Data Workers lets you run them.

3. Credit spend that keeps going down. The Cost Savings & Cleanup agent breaks your bill down by table, query, team and pipeline across Snowflake, Databricks and BigQuery. It finds idle and oversized warehouses, tables nobody has queried in months, and duplicate pipelines, and it archives only after checking dependencies. Our design target is a 25–40% cut in warehouse spend. That's a target we're engineering toward, not a billed average. Snowflake budgets can cap Cortex spend, but they can't see the Databricks bill next door.

4. Migrations you approve instead of staffing. Redshift, Teradata, Oracle or on-premise workloads into Snowflake, or workloads moving between Snowflake and Databricks. The Data Migration agent assesses the estate, translates SQL and procedural logic, re-translates anything that fails validation, and proves parity with row counts, checksums, statistical profiles and referential-integrity checks. It then cuts over incrementally while the legacy system stays live. Each wave is a single approval in Spellbook. Our target is 4–8 weeks for work that usually takes consultants 6–12 months.

5. Incidents closed, not alerted. A Data Metric Function that fires becomes a resolution loop, not a ticket. The Conductor traces the cause wherever it lives, has the right agent fix it, and confirms the DMF is green again, with a receipt on every change.

6. Governance and compliance by default. Access requests go from ticket to approved grant through Snowflake RBAC, with a receipt. Masking and row-access policies are proposed as sensitive columns appear. Audit evidence is assembled from receipts instead of being hunted down every cycle.

Behind all six are 20+ specialist agents, one context graph across every platform, and the coding agent your team already uses (Claude Code, Codex or Cursor) as the way in. Spellbook is where you look: every asset, every change and every receipt, with one-click rollback.

One incident, five systems

Here's a scenario most Snowflake shops will recognize (an illustration, not a customer case):

• •01:15. A key column in a Postgres source changes type. The Airflow task that loads it fails after its retries, and nobody is paged.
• •06:00. A Data Metric Function on ANALYTICS.FCT_REVENUE flags freshness, and anomaly detection flags a row-count drop.
• •07:30. The ML team's Databricks churn model reads the same table through an Iceberg catalog link and scores on yesterday's data.
• •09:00. Finance asks CoWork why revenue looks flat.

CoWork gives you the best explanation of the symptom. Data Workers closes the ticket. The rest of this guide is about that difference.

What Snowflake covers, as of September 2026

Semantic views in particular are a genuinely strong trust anchor for NL-to-SQL. We use them rather than compete with them.

Here's the side-by-side. We scored eight outcomes a data leader actually buys. Snowflake leads on its home ground: answers on semantic views and AI functions inside SQL. On metric definitions we're even, because we ingest semantic views as the source of truth. The other five are about fixing, governing and paying for what happens across the estate.

The scores measure scope (what each side covers), not answer quality, and they're our directional judgments, not benchmarks. We've shown the reasoning so you can argue with any line.

CoWork and Cortex stop at the account edge

Every limit below comes from Snowflake's own documentation. None of them is an oversight. Snowflake's agents are designed to make the Snowflake account the governed perimeter, and they do that well.

1. Acting outside Snowflake is a tool call, not an operation

Cortex Agents reach other systems in two ways: MCP connectors and stored procedures that call external APIs. Both let an agent do something elsewhere, like open a Jira ticket or post to Slack. Neither gives you what an operator needs before changing production: impact analysis across the systems involved, a review step, a verified outcome, and a rollback. We found no native, governed way for a Snowflake agent to change a Databricks job, an Airflow DAG or a BigQuery table.

2. CoCo writes code; it doesn't run your estate

CoCo is a capable coding agent, and its dbt and Airflow skills are useful. But it's an engineer's tool. It works on code in a local repository or in Snowsight, when a person asks it to. Snowflake's April blog mentions "support for AWS Glue, Databricks and Postgres", but the docs don't say whether CoCo acts on those systems or only writes code that targets them. Either way, nobody is on call when the engineer logs off.

3. No ops agent owns detect-to-resolve

Data Metric Functions and anomaly detection will tell you a table went stale or its row count dropped (anomaly detection is still in preview and covers row count and freshness only). What happens next is on your team. Databricks has at least announced an ops agent (Genie ZeroOps). We found no Snowflake equivalent that owns incident-to-resolution. Observability for external Iceberg tables is in private preview.

4. Context is Snowflake-first

Horizon Context and Cortex Sense build context from what Snowflake can see: its metadata, query history and semantic views. Connectors for other sources (Postgres, SQL Server, Tableau, Power BI, dbt) are in private preview and metadata-only, and Databricks and BigQuery aren't on that list. If half your revenue definitions live in Databricks metric views or LookML, Snowflake's context layer can't see them yet.

The overlap, honestly

What it costs as agents do more of the work

Snowflake has no seat fee for its agents. The meter is consumption:

• •Cortex Agents and CoWork bill per million tokens in AI credits, at $2.00 per credit on global routing and $2.20 regional.
• •Tools cost warehouse compute on top. Custom tools, code execution and Analytical Search all run on a warehouse.
• •Cortex Analyst, called directly, bills per 1,000 messages.

That's fair for Snowflake-resident work, and budgets and per-user quotas can cap it. But as agents do more of the operating work, the credit line grows, even when the actual fix lives in Airflow or Databricks. Data Workers is priced the other way round: the Apache 2.0 core is free, 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 key. The only Snowflake credits Data Workers uses are for the queries it runs under the role you grant.

The fastest first win: access requests and credit spend

Two jobs pay back quickly on a Snowflake estate:

• •Access requests closed end to end. The Access & Governance and Identity agents take a request from the ticket, check it against policy, propose the grant, route it for approval, apply it through Snowflake RBAC, and keep the receipt.
• •Credit spend cut across platforms. The Cost Savings & Cleanup agent finds idle and oversized warehouses, unused tables and duplicate pipelines, in Snowflake and in whatever runs next to it, and proposes each change for approval.

What each Data Workers product adds on a Snowflake stack

Spellbook Data Catalog, the agentic catalog, vs. Horizon Catalog

Horizon is a strong governance catalog for Snowflake: lineage, classification, policies, and Iceberg interoperability through Polaris. Like every traditional catalog, though, it's fundamentally an inventory, a record of what exists and who may touch it.

Spellbook Data Catalog is what a catalog becomes when agents are doing the work: the control plane where that work is proposed, approved, rolled back and audited (see our whitepaper, From the Traditional Data Catalog to the Agentic Data Catalog).

• •Agents maintain the metadata (descriptions, owners, lineage, quality status) under the same governance as any other change.
• •Asset pages cover the whole estate. A deep-wiki page for a Snowflake table shows the Openflow or Fivetran source upstream, the dbt model that builds it, the Databricks feature pipeline that reads it through an Iceberg catalog link, and the dashboards that depend on it.
• •One inbox for all agent work, across every platform: approve, steer, send back or roll back.
• •An authority guard enforced in code. No agent can promote its own output to canonical.
• •Horizon stays authoritative for Snowflake. Approved access changes are applied through Snowflake's own policies, not through a shadow permission system.

Spellbook is in preview today.

Data Context Wizard vs. Horizon Context and Cortex Sense

Cortex Sense and Horizon Context confirm what we've argued since day one: agents are only as good as the context they can trust. We've made the case at length in Why the Data Layer Needs Its Own Context Layer. Data Context Wizard differs in three ways:

• •Cross-platform from day one. Snowflake, Databricks, BigQuery, dbt, Airflow, BI tools and existing catalogs all feed one graph, with 50+ connectors and no migration. Semantic views come in through OSI as first-class sources.
• •Provenance on every fact. Every fact records its source, author, confidence, when it was observed, and its tenant. Re-observed facts gain confidence instead of multiplying.
• •Scored and gated trust. A multi-signal authority score orders what a human reviews, and a named human approves what becomes authoritative. Auto-collected context is useful. Auto-promoted context is how a wrong definition quietly becomes the company's definition.

The graph scrubs PII before storage, isolates each tenant, keeps a tamper-evident audit, and supports GDPR right-to-be-forgotten.

The Data-Agents Swarm vs. Cortex Agents and CoCo

Cortex Agents is a runtime for building agents, and CoCo is a copilot for engineers. The Data-Agents Swarm is 20 specialized agents that already do the work, across 50+ integrations. On a Snowflake estate, a few stand out:

• •Cost Savings & Cleanup agent. Warehouse right-sizing, unused tables, runaway queries and duplicate pipelines, across Snowflake and every other platform you pay for, so a saving in one place isn't a cost moved somewhere else.
• •Schema Evolution agent. It catches an upstream contract change before it breaks the Snowflake table, the dbt models built on it, and the Databricks and BI consumers downstream.
• •Data Access & Governance, Identity and Data Security agents. They handle access requests end to end: check the policy, propose the grant, get approval, apply it through Snowflake RBAC, and keep the receipt.
• •Data Migration agent. It plans and verifies migrations into Snowflake, or out of it, in reviewable batches.

The swarm is MCP-native. A Cortex Agent can call Data Workers agents through Snowflake's MCP connectors, and CoWork users can reach them the same way.

Autonomous Data-Conductor: the piece Snowflake doesn't have

Autonomous Data-Conductor is the orchestrator that owns the outcome, not the step. When a DMF fires on a Snowflake table, the Conductor traces the cause upstream: a renamed column in a Postgres source, say, or a failed Airflow task. It directs the right agents to fix the problem where it lives, scopes the blast radius first, gets the approval the domain requires, and then verifies that the downstream number is right again. Every change leaves a signed receipt and can be reversed in one click, and the outcome is written back to the context graph so the next occurrence costs less.

Autonomy guardrails and security

Snowflake's agent governance is solid inside its perimeter. Agent Identity gives agents first-class identities, Cortex AI Guardrails filter prompts and responses, CoCo has plan-mode approvals, and AI Observability traces what agents did. Those controls govern an agent's session inside Snowflake.

Data Workers governs work across the estate, and makes autonomy something a team earns step by step:

• •Autonomy is set per domain, from L0 (manual) to L4 (fully autonomous). Access provisioning can close on its own while net-new pipelines still wait for a human.
• •New deployments start observe-only.
• •Blast radius is scoped across platforms before any write, not just inside one account.
• •Every change gets a signed receipt and one-click reversal.
• •No agent can approve or promote its own work. This is enforced in code.
• •Least privilege. Data Workers acts with the Snowflake roles you grant it, so Snowflake's policies still apply to everything we touch there.

"Snowflake agents support MCP and cross-platform collaboration. Isn't that the same thing?"

This is the customer's question, and here's the answer we gave.

Yes, Snowflake's agents can use MCP and reach tools outside Snowflake. We don't treat MCP connectivity as a differentiator, and nobody should. The difference is connectivity versus an operating model.

With Snowflake, the agent lives in Snowflake and reaches outward: "My agent can access another system." With Data Workers, the estate might include Snowflake, Databricks, dbt, Airflow, a separate catalog and three BI tools, and we maintain context across all of it, coordinate specialized agents across it, execute governed changes in whichever system is involved, verify the outcome, and feed what happened back into shared operational memory. That loop, event → cross-system context → decision → coordinated action → verification → retained knowledge, is the product. MCP is just one of the protocols it uses.

How it fits together

There's no migration. You connect Data Workers to Snowflake with a scoped role, then add your dbt project, your orchestrator and your other platforms. Data Context Wizard builds the graph, every agent starts observe-only, and the first things you see are the cross-platform lineage and incident history that Horizon alone can't show you. Autonomy grows domain by domain from there.

When Snowflake alone is enough

• •Everything runs inside Snowflake. No Databricks, no BigQuery, and dbt running as dbt Projects on Snowflake.
• •Your only need is Q&A on data that never leaves Snowflake. CoWork on well-built semantic views is a strong experience.
• •You have the people to handle incidents yourselves, and you're comfortable with CoCo assisting them.

Data Workers is worth it when more than one platform is in your critical path; when incidents start in dbt, Airflow or a source system rather than in Snowflake; when you want governance, compliance, pipeline management and catalog upkeep to run autonomously rather than with assistance; or when you need graded, reversible autonomy with receipts that satisfy an auditor.

FAQ

Does Data Workers replace Horizon Catalog? No. Horizon stays the enforcement point for Snowflake objects. Spellbook is the agentic control plane across the estate, and it applies approved changes through Snowflake's policies.

Do we have to rebuild our semantic views? No. Data Context Wizard ingests them, including through OSI, and treats them as the source of truth for Snowflake metrics.

Can Cortex Agents or CoWork call Data Workers? Yes. The swarm is MCP-native and can be registered as a custom MCP connector.

Is Data Workers open source? The core is Apache 2.0 and free to run. See pricing for what the enterprise platform adds.

Does Data Workers bypass Snowflake RBAC? No. It acts with the roles you grant, and every change to a Snowflake object is applied through Snowflake's own policies.

What happens if an agent gets something wrong? Every write is scoped before it runs and goes to review at whatever autonomy level you've set for that domain. It leaves a signed receipt and can be reversed in one click. No agent can approve its own work.

What does Data Workers store? Metadata and scrubbed facts about your data (definitions, lineage, owners, incident history), not copies of your tables. PII is scrubbed before anything is stored, tenants are isolated, and Enterprise can run in your own VPC or on-premise.

Does it run on Snowflake credits? Only the queries it issues against Snowflake, under the role you grant. Orchestration and reasoning run in Data Workers, not in your warehouse.

Sources for Snowflake capabilities and statuses: Snowflake documentation, release notes and press releases current as of September 29, 2026, including Cortex Agents, MCP connectors, managed MCP server, CoWork, CoCo, Horizon Context, anomaly detection and Cortex pricing. Several Summit 2026 features show different statuses across Snowflake's own pages; we've used the more conservative one. If we've got something wrong, tell us and we'll fix it.