What Snowflake actually shipped at Summit 26 on June 2
At Snowflake Summit 26 in San Francisco on June 2, Snowflake announced that Snowflake CoCo — the product formerly known as Cortex Code — has graduated into the company's agentic control plane for enterprise AI. The positioning is deliberate, and it is a meaningful shift from how Cortex Code was framed at last year's Summit. CoCo is not pitched as a coding assistant inside the warehouse; it is pitched as the unified, governed environment where builders manage workflows across data, models, and apps — which is the language of a platform, not of a feature.
The operational shape, summarized from the Snowflake announcement and the practitioner write-ups in the hours after the keynote:
- Native desktop application that functions as a full IDE — file tree, multi-tab editor, integrated terminal, agent chat surface, the inference plane wired to the customer's Snowflake account by default.
- Cloud agents that run inside Snowflake's compute substrate, with the agent's tool-call surface scoped to the customer's data perimeter and the audit trail wired into the existing Snowflake governance layer.
- Agent SDK for developers who want to embed CoCo's agentic engine — planning, tool invocation, file edits, multi-turn sessions, the governance handshake — into their own applications and services.
- VS Code and Claude Code plugins so the agentic surface lives in the IDE the engineer already uses, with the data perimeter and the governance plane still owned by Snowflake rather than re-implemented by the IDE.
- Mobile app and Slackbot coming later in 2026, scoped at control and light-touch authoring rather than full IDE parity.
- Snowflake Datastream, a new fully managed Apache Kafka service that brings real-time data ingestion under the same governance plane as the warehouse and the CoCo agent fleet. The framing is explicit: agents need to act on the data as it arrives, not on the data as it landed yesterday in a batch table.
- 7,100 Snowflake customers already building on CoCo, with Fanatics, Thomson Reuters, and WHOOP named among the early adopters at the keynote.
The headline framing — the agentic control plane for enterprise AI — is correct as a sales line and slightly understated as a description of the architectural change. The structural event is not that Snowflake shipped a coding agent. The structural event is that Snowflake collapsed the boundary between the data platform the business runs on and the agentic runtime that operates on the business's data. That boundary has been the single largest source of integration work in enterprise agentic AI for two years.
Why "agentic control plane on top of the warehouse" is structurally significant
For the last twenty-four months, every regulated-enterprise agentic AI project has had roughly the same shape. The customer wanted an agent that could do things on top of the operational data — answer questions about the business, draft documents grounded in real records, take routine actions, hand off to a human when the trajectory was unclear. The data lived in the warehouse — Snowflake for a meaningful fraction of the Fortune 500. The agent lived somewhere else — a LangGraph application, a Bedrock deployment, a Foundry endpoint, an in-house orchestration plane. Connecting the two was the work.
The work meant standing up a tool-call surface that exposed the data to the agent in a controlled way; wiring the auth surface so the agent's permissions were a subset of the calling user's permissions; instrumenting the audit pipeline so every query the agent made, every row it touched, every record it modified was logged into the customer's compliance surface; managing the lineage between the agent's intermediate reasoning and the final output so the regulator could trace why the agent made a given recommendation. Each of those layers was a multi-week engineering deliverable. Combined, they were the dominant line item in the cost of putting a regulated agent into production, and the dominant reason the time-to-production for these projects measured in quarters rather than weeks.
CoCo as an agentic control plane on top of the warehouse compresses that integration work to platform plumbing. The tool-call surface is the warehouse's native access primitives, scoped by the warehouse's existing role and policy model. The auth surface is the customer's existing Snowflake identity surface, including the OAuth, SCIM, and SSO integrations the customer has already audited. The audit trail is the existing Snowflake access-log surface, with new event types for agent action rather than a parallel system to maintain. The lineage is the existing Snowflake lineage surface, extended to cover the agent's tool-call graph. None of that is the customer no longer needs to think about governance; all of it is the customer no longer pays specialist-firm rates to build the governance plane from primitives.
The compression matters. The work that an AI specialist firm would have priced at three to six months of engineering for a regulated-enterprise Snowflake-aligned deployment gets shipped as platform feature. The remaining work — the eval discipline that grades the agent honestly on the customer's workload, the rubric authoring that governs the senior-review queue, the routing policy that decides which agent class lives inside CoCo and which lives outside, the workflow design that turns the platform is available into the business is getting value — does not disappear, but it is a different fraction of the total engagement, and the procurement-conversation shape moves accordingly.
What changes about the make-vs-configure conversation for the Snowflake install base
Four shifts that follow when the agentic control plane is inside the data platform the customer already operates.
The make-vs-configure boundary moves up the stack. Work that was previously make — build the data-aware tool-call surface, wire the auth handshake, instrument the audit pipeline, design the lineage capture — becomes configure inside CoCo. Work that was previously configure — author a SQL query, build a small dashboard, write a quick stored procedure — becomes the agent does it directly through the natural-language surface. The boundary between we need an AI specialist firm to build this and our existing Snowflake team can configure this shifts upward. The CIO who walks into the FY27 budget without recognizing the shift will keep paying specialist-firm rates for work that is now in scope for the data platform team.
Datastream changes the freshness floor of what agents can act on. Most production agentic workloads inside enterprises today operate on data that landed in the warehouse last night, last hour, or — for the better-instrumented teams — in the last few minutes through a CDC pipeline the platform team owns. Datastream pulls the Apache Kafka layer inside the same governance plane as the warehouse and CoCo, which means the agent's now and the business's now converge. Workloads that were previously infeasible because they required low-latency reasoning over a stream — fraud-detection escalation, real-time inventory rebalancing, incident-response triage, customer-support routing on live signal — move from we can't do that with the current platform to that's a CoCo workflow on top of a Datastream topic, governed by the same policy surface as everything else we run. The teams that recognize this shift early get to define the workload patterns that the rest of the install base will copy in 12 months.
The portfolio of agent-class deployments inside the same customer collapses. Most Snowflake customers building agentic capability today operate three to five separate agent deployments — one in LangGraph for the support workflow, one in Bedrock for the research workflow, one in Foundry for the document workflow, one homegrown for the finance workflow — each with its own operational surface, its own observability layer, its own eval harness, and its own data-perimeter handshake to the warehouse. CoCo as a unified control plane consolidates the operational layer without forcing the customer to standardize on a single agent runtime. The portability story improves; the operational tax shrinks; the per-workload cost-per-successful-task becomes computable on a single dashboard rather than reconstructed from a half-dozen log streams.
The 7,100-customer adoption curve creates a network effect that compounds. When the install base of a platform reaches the most of the Fortune 500's data teams already work in it threshold, the platform's primitives start to function as industry standards rather than vendor differentiators. CoCo's agent SDK, its workflow conventions, its lineage and governance model, its data-perimeter handshake — once enough customers have built on them, the third-party ecosystem starts shipping integrations to those primitives rather than around them, and the platform's gravitational pull on the procurement conversation gets stronger every quarter. The teams that build on CoCo this quarter participate in defining those conventions; the teams that wait will inherit them.
What this does not change
Three honest caveats, because the temptation will be to read the announcement as the end of the build-your-own era.
It does not eliminate the multi-platform reality. Most enterprises with a Snowflake footprint also have a meaningful footprint in one or more of Databricks, Microsoft Fabric, BigQuery, and a long tail of operational systems whose data does not live in Snowflake. CoCo is the agentic control plane for the data inside Snowflake, with extension points to reach the rest. The portability story has to be designed in: which workflows live natively inside CoCo, which span CoCo and an external orchestration plane, which run outside the Snowflake perimeter entirely with CoCo as one tool in the kit. The customer that treats CoCo as a complete answer will build a platform-locked operational layer the next time the data architecture shifts; the customer that treats CoCo as the dominant home for a specific class of workloads and designs the soft boundaries deliberately keeps the optionality.
It does not collapse the BYO-model question underneath. CoCo is BYO-model in principle, with the customer choosing the underlying LLM provider per agent class and the platform handling the orchestration and governance underneath. That is the right architectural choice and a meaningful one. It is also a choice that has to be made deliberately: which models live on the routing matrix, how the eval harness grades them on the workloads that matter, how the routing policy handles the inevitable relative-capability shifts as Claude Opus 4.8, MAI-Thinking-1, GPT-5.5, Gemini 3.5 Pro, and the open-weights frontier cohort move relative to each other through the rest of 2026. The team that signs the procurement contract assuming CoCo will pick the right model for us will discover, three quarters in, that the platform picked whichever model the platform vendor's partnership prioritized this quarter, and the discovery will not be pleasant.
It does not eliminate the eval discipline at the workload-specific boundary. A platform that ships agentic primitives is not a platform that ships agents that work on your business. The eval discipline that grades the agent honestly on the customer's data, the rubrics that govern the senior-review queue, the gold sets that calibrate multi-judge agreement — those still have to be built, and the platform vendor cannot build them. The teams that deploy CoCo without the eval discipline get the familiar failure mode of the first wave of enterprise agentic AI: a capability that looks impressive in a demo, that decays in three weeks, and that no one trusts in six.
Where Sonnet Code fits
A data platform shipping an enterprise-grade agentic control plane with native governance and a real-time streaming substrate is the easy half of the Snowflake-customer agentic AI story. The hard half is the engineering and human-judgment work that turns the platform is configured into the agents are doing what the business needs, evaluated honestly, observed continuously, and governed by a senior-review queue calibrated for the failure modes that actually occur. AI development at Sonnet Code is the engineering half: extending CoCo's BYO-model surface with a routing layer that treats Claude Opus, MAI-Thinking-1, Gemini 3 Pro, and the open-weights frontier cohort as peer endpoints with workload-specific selection; designing the Datastream + CoCo workflow patterns that bring real-time signal into the agentic surface inside the Snowflake perimeter; wiring the agent SDK into the customer's existing operational observability surface so the cost-per-successful-task attribution per agent class and per workflow is a first-class metric rather than a reconstruction project; and structuring the portability layer so the customer-owned signal — the workflow definitions, the rubrics, the gold sets, the policy graph — is not platform-locked even when the operational layer is. AI training is the human-judgment half: the senior engineers, the domain experts, the bilingual reviewers who design the gold sets for the agentic workflows on top of the customer's actual data, calibrate the senior-review queue for the failure modes a CoCo-governed agent produces, author the rubrics that the eval harness runs against, and serve as the senior-judge pool whose calibrated decisions make the difference between the platform demoed well at Summit and the platform is compounding capability against the business's metrics through the back half of 2026.
The boundary between enterprise data platform and agentic runtime just stopped existing for the Snowflake install base. The teams that walk into Q3 with the routing layer extended, the Datastream workflow patterns designed, the eval matrix recalibrated, and the senior-review queue calibrated for CoCo-flavored failure modes are the teams that turn the Summit announcement into a real, compounding, defensible capability advantage. The teams that defer the eval discipline will keep paying specialist-firm rates for the integration work the platform now ships — and will keep watching the buyer down the road who figured it out a quarter earlier define the workload patterns the rest of the install base will inherit.
