A governance-first product announcement
Snowflake used its Expedition 2026 event on November 3 to ship a cluster of features that have almost nothing to do with making its AI agents smarter and almost everything to do with making them accountable. Cortex AI Gateway, first previewed in July, moved to general availability. It governs how agents connect to systems, keeps a record of what they did, and enforces spending limits so an agent cannot quietly run up a compute bill while completing a task nobody is watching closely.
Alongside the Gateway, Snowflake introduced Business Ontology, part of a broader Horizon Context capability inside its Horizon Catalog, now in public preview. It gives agents approved, standardized definitions of core business concepts such as net revenue, links those definitions to the actual tables and views that back them, and assigns an owner who is responsible for changes. That is a data governance feature wearing an AI announcement's clothing, and it is arguably the more consequential of the two.
Why the ontology layer matters more than the headline
Every enterprise that has tried to deploy an AI agent against real financial or operational data has hit the same wall: the agent can technically query the warehouse, but nobody can fully trust the answer, because the same business term is often defined three different ways across three different teams' tables. An agent that resolves ambiguity by guessing, or by picking whichever definition happens to be nearest in the schema, produces confidently wrong numbers at a speed that makes the error harder to catch than a human analyst's mistake would be.
Business Ontology attacks that problem directly by forcing a single, owned, auditable definition for the concepts agents are allowed to reason about. This is the unglamorous plumbing work that has to exist before an agent touching revenue, margin, or inventory figures is safe to run without a human checking every output. CIOs evaluating any AI agent platform, not just Snowflake's, should be asking the same question of every vendor: where does the agent get its definition of the numbers that matter, who owns that definition, and what happens when two systems disagree.
Keeping agents inside existing controls, not new ones
The rest of the announcement follows the same pattern of fitting agents into controls that already exist rather than inventing new ones. CoCo Cloud Agents, now generally available, run inside Snowflake-managed isolated environments rather than with open-ended access to a shared one. CoCo Automations, also available now, schedules routine tasks like health checks and failed-job investigations, and keeps a history that lets a team suspend or rerun a job rather than simply trusting it ran correctly.
CoCo GitHub Integration, in public preview, is the clearest example of the philosophy: when an agent proposes a code or pipeline fix, that proposal goes into the team's existing code review process. The agent does not get a side door around the review gate every human engineer already has to pass through. Engineers still decide whether an agent-proposed fix reaches production. That is a deliberately unambitious design choice, and it is exactly the right one for any organization not yet ready to extend production trust to a system that cannot be held accountable the way a person can.
The always-on bots are the part to watch, not deploy yet
Snowflake also previewed, without a general availability date, always-on CoCo and CoWork bots designed to take a stated goal and work on it continuously in the background. The detail that matters is what Snowflake says these bots will do when they hit a critical decision: return control to the user rather than proceeding autonomously, and inherit that user's own permissions rather than operating with elevated or pooled access. Several related gateway features sit alongside this in preview, including agent abuse detection, agent trace intelligence, and dynamic model routing, all still private preview rather than shipped, which signals Snowflake expects the control layer to keep expanding well past this release.
That inheritance model is a meaningfully different security posture than giving an agent a dedicated service account with broad access, which is how a lot of early agent deployments have been architected out of expedience. Permission inheritance means the agent can never do more than the specific person who activated it could already do themselves, which caps the blast radius of a misbehaving agent at one user's existing access rather than at whatever the agent's own account happened to be provisioned with. It is a private preview feature, not a shipped product, so judge the architecture now and the execution later.
What CIOs should take into their own agent rollout
Snowflake's own materials contain no adoption numbers, no customer-reported time savings, and no cost figures attached to any of these features. That is worth stating plainly rather than letting the announcement's framing imply otherwise: this is a governance architecture release, not a results release, and the two should not be confused when the capability eventually shows up in a sales deck with a growth chart attached to it. Vendors routinely let an architecture announcement borrow the credibility of a results announcement, and the responsible read of this one keeps those two categories separate until a named customer reports an actual number.
The decision in front of most CIOs right now is not whether to adopt agents, that decision has largely already been made by the business functions requesting them. It is whether the platform underneath those agents enforces ownership, auditability, and permission scoping by default, or whether governance is something your own team will have to bolt on after the fact once an agent has already made a decision nobody can fully explain. Snowflake's bet is that the second path is where most enterprises currently sit, and that selling the fix to that gap is more valuable right now than selling more raw agent capability.
