Snowflake now has the context to tell enterprises what work should not exist. Its latest announcement uses that context to automate the work instead.

At Expedition 2026, Snowflake announced three things: a Business Ontology framework, expanded agent governance through Cortex AI Gateway, and autonomous data engineering, where agents build, monitor and troubleshoot data pipelines with less human intervention.

The pattern is familiar. Salesforce has its AI Control Plane, ServiceNow has AI Control Tower, and SAP has governed Joule agents. Every platform is racing to become the place where agents run and are controlled. None of them is asking which work the agents should be doing in the first place.

The automation reflex

Faster troubleshooting still assumes the failure. An agent that repairs a broken pipeline faster accepts that the pipeline will break. It makes failure cheaper to handle. It does not ask why the failure keeps happening.

I have watched this reflex play out in every wave of IT operations, from runbook automation and scripting to AIOps. The ticket gets resolved faster, the incident closes sooner, and the work that caused both stays exactly where it was. Agents make the reflex more powerful, not less.

Governing agents like employees preserves the work. Snowflake describes giving agents the kind of oversight applied to employees: access rules, monitoring, cost controls, audit trails. That is sensible. But it treats agents as digital labor slotted into today’s operating model. It governs the work. It does not question it.

Context from the top, telemetry from below

Business Ontology is the most important part of the announcement. It lets an organization set approved definitions for its business concepts, so two agents don’t give incompatible answers from the same accurate data. That is top-down context: what revenue, a customer or a claim actually means in this business.

The platform already holds the bottom-up half. Snowflake sees every pipeline run and failure, the lineage from source to report, and which tables and metrics are queried, by whom and how often.

Put those together and you have what elimination needs. When I built an AI-native operations platform, the hardest part was assembling exactly this: business context on one side, operational history on the other, joined well enough to say which work serves the business and which doesn’t. We called it historical intelligence, and it decided what to eliminate before anything was automated. Snowflake has both halves in one place.

The questions that context can answer

With ontology and telemetry joined, a data platform could answer elimination questions instead of only automation ones:

  • Which pipelines, tables or metrics map to no approved business concept, or have no consumer? Retire them. Every one an agent maintains is cost with no outcome.
  • Which recurring failures trace back to the same upstream source or contract? Fix the cause once, rather than having an agent troubleshoot the symptom forever.
  • Which near-duplicate metrics exist only because definitions diverged? Once the ontology settles the definition, collapse them.

Only what survives those questions should be automated. Only what can’t be automated should go to a human. That order is the difference between an agent-run estate and a smaller, better one.

Why the platforms won’t lead with it

Consumption pricing rewards more work. It pays for more compute, more pipelines and more agent activity. Elimination cuts all three. A vendor billed on usage has little reason to tell you a third of your usage shouldn’t exist.

Ontology is not purpose. It defines what a term means, not which business outcome that term should move. A clean definition of “claim” says nothing about whether claims take too long to settle, or whether the data flowing around them shortens that time. Elimination needs that last link from data to outcome. Without it, you can tidy definitions and still keep running work that doesn’t matter.

What enterprises should do

Don’t wait for the platform to ask the question. Before you switch on agents that build and repair pipelines:

  • 1. Build historical intelligence first. Use run history, failure history and consumption data to find what is unused, duplicated or failing for the same reason again and again.
  • 2. Eliminate before you automate. Retire what serves no outcome, fix recurring causes at the source, and only then hand the remainder to agents, with humans assisting where judgment is needed.
  • 3. Tie the work to business KPIs, and buy it that way. Ask vendors what outcome they guarantee, not how much activity they will run. Outcome-based terms are the only ones that reward elimination.

Snowflake has built the context layer the industry needed. The question is whether it gets used to run more work faster, or to run less work that matters more. The platforms will default to the first. Enterprises should insist on the second.

Sources

This article is part of the Enterprise Intelligence series on building intelligence that drives peak business performance.