Snowflake CoCo Keeps Inference Inside the Perimeter

Any platform lead sitting on a 2026 budget line for "AI coding assistance for the data team" now has a specific vendor question to answer in the next 90 days: does the agent run inside your governance boundary, or does it ship your schema and query history to somebody else's inference endpoint. Snowflake just made that question harder to dodge. The launch of CoCo, its coding agent for data engineers, is less a product story than a procurement story.

What Happened

On September 4, Snowflake sales engineer Jeremiah Hansen published a post introducing CoCo, an AI coding agent aimed squarely at data engineers building reproducible pipelines. As StartupHub.ai reported, Hansen frames the pitch around reproducibility rather than raw code generation, which is a notable rhetorical move in a market where every vendor is still competing on tokens-per-second and benchmark scores.

CoCo ships in three surfaces that share the same underlying intelligence: a CLI for terminal work, a VS Code-based Desktop client, and a no-install version embedded inside Snowsight for long-running cloud tasks. The architectural headline is that inference stays inside Snowflake infrastructure. Schemas, warehouse configurations and query history are processed under the same governance and classification policies the customer already has in place, not routed to a third-party model provider.

The agent comes preloaded with built-in skills for Dynamic Tables, Snowpipe Streaming, Openflow, Spark migration, dbt, Snowpark and DCM. Those skills activate when a prompt matches the domain, so the agent isn't loading every capability into context on every call. Hansen is candid about the failure mode: agents are nondeterministic by design, and letting one write directly to production without dbt, schemachange, Flyway or Terraform in the loop produces fragile deployments. Snowflake's answer is packaging. Team conventions live in SKILL.md files. Plugins bundle skills together with subagents, slash commands, hooks and MCP servers, then get deployed as versioned units through a registry with cortex plugin validate, install and update commands.

Technical Anatomy

Strip the marketing layer off and CoCo is really two design decisions stapled together. The first is where inference physically runs. The second is how team knowledge gets encoded and versioned.

On the inference boundary: most generic coding agents work by shipping context to an external LLM API. For a data engineering workload, that context includes table schemas, column names, sample rows, query history, and often the query plan itself. That's the exact payload a regulated iGaming operator, a payments processor, or a bank's analytics team cannot legally hand to a third party without a data processing agreement, and often not even then. Snowflake keeping inference inside its perimeter means the classification tags a customer already applied under existing governance policy continue to apply during the agent's reasoning step. That's not a nice-to-have. It's the difference between "we can pilot this" and "legal killed it in review."

On the packaging layer: SKILL.md is essentially a convention-as-code file. It encodes how a specific team writes dbt models, names Dynamic Tables, structures Snowpark jobs. A plugin wraps one or more skills together with the executable machinery, subagents that handle subtasks, slash commands for operators, hooks for lifecycle events, and MCP servers for external tool access. The registry model with validate, install, update is borrowed straight from package manager thinking. That matters because it means a platform team can version its house rules the same way it versions Terraform modules or dbt packages. See the dbt docs for the maturity that pattern has reached in the transformation layer; CoCo is trying to import that same discipline into agent behavior.

Hansen's warning about nondeterminism is the honest part. No amount of skill packaging makes an LLM deterministic. What it does is constrain the blast radius. If the agent must produce dbt models or schemachange migrations rather than raw DDL fired at production, you get code review, CI, and rollback as free byproducts of the existing deployment pipeline. That's the actual reproducibility claim. Not that the agent is repeatable, but that its outputs land inside systems that already are. Snowflake's own platform documentation is where the boundary between agent output and governed deployment ultimately gets defined.

Who Gets Burned

Three groups feel this move immediately.

First, the independent AI coding agent vendors targeting data teams. Any startup whose pitch was "we plug into Snowflake and give your engineers Copilot-for-SQL" just watched the platform owner ship a native, in-perimeter competitor with preloaded skills for the exact Snowflake surfaces they were wrapping. The build-vs-buy math for a Head of Platform shifted overnight. If you already pay Snowflake seven figures a year, adding a first-party agent that inherits your governance policies is a much shorter procurement cycle than onboarding a new vendor, negotiating a DPA, and standing up network egress rules for a third-party inference endpoint.

Second, Databricks-heavy shops running mixed workloads. The Snowflake pitch is now "your agent stays inside the fence." That's a competitive framing Databricks will have to answer, and the answer will probably involve deeper integration between coding agents and the Databricks governance layer. Teams currently choosing between platforms for a new greenfield analytics build should expect the agent story to become part of the RFP within the quarter.

Third, the hiring market for senior data engineers. If CoCo actually delivers on skill-based automation for Spark migration, dbt authoring, and Snowpipe Streaming configuration, the marginal value of a mid-level data engineer who mostly writes boilerplate transformations drops. The premium moves to engineers who can author SKILL.md conventions, design plugin architectures, and enforce the deployment discipline Hansen flagged as the remaining gap. This is the same bifurcation the software engineering market went through with Copilot, arriving now for data platform roles.

The CFO at any Snowflake customer should be asking their VP Data this week whether the current external AI coding tool contract can be terminated for convenience, and what the credit-consumption profile of CoCo actually looks like against that saved license spend. Nobody has published unit economics for CoCo inference against Snowflake credits yet, and until that math is on the table, "it's included in the platform" is a marketing sentence, not a budget line.

Playbook for Data Teams

For platform leads evaluating this in the next sprint, the sequence matters.

Start by inventorying every existing AI-assisted data tool your team uses and mapping which ones send schema, query history, or sample data outside your Snowflake perimeter. That inventory is the compliance case for piloting CoCo, and it's the ammunition you need if procurement pushes back on switching costs.

Next, do not let CoCo write directly to production. Hansen said it, and he's right. Wire the agent's output through dbt, schemachange, Flyway or Terraform depending on which layer it's touching. Treat agent-generated code exactly like intern-generated code: code review, CI checks, staged rollout. The reproducibility claim only holds if you supply the deterministic wrapper.

Then invest engineering time in writing SKILL.md files that encode your team's actual conventions. Naming patterns for Dynamic Tables, warehouse sizing heuristics, tagging standards. This is where the platform team earns its keep in the agent era. Generic skills produce generic code. Encoded conventions produce code that passes your review.

Finally, watch the plugin registry maturity closely. A versioned, validatable plugin system is the difference between agents-as-toys and agents-as-infrastructure. If Snowflake ships a real ecosystem here, third-party skill authors will follow, and the lock-in gets deeper. If the registry stagnates, CoCo remains a first-party convenience feature and the market stays open. Budget accordingly.

Key Takeaways

• CoCo runs inference inside Snowflake's perimeter, removing the third-party LLM data exfiltration problem that blocks most generic coding agents from regulated workloads.
• Three surfaces (CLI, VS Code Desktop, in-Snowsight) share the same intelligence, with the Snowsight version aimed at long-running cloud tasks.
• Built-in skills cover Dynamic Tables, Snowpipe Streaming, Openflow, Spark migration, dbt, Snowpark and DCM, activated by prompt matching rather than always-loaded context.
• Reproducibility comes from the deployment wrapper (dbt, schemachange, Flyway, Terraform), not from the agent itself; Hansen was explicit that agents remain nondeterministic.
• The SKILL.md plus plugin registry pattern with validate, install, update commands is the actual strategic bet: package management discipline applied to agent behavior.