Over the past three weeks, Snowflake and Databricks held their annual flagship conferences in San Francisco. Together, they announced dozens of new products, features, partnerships, and platform capabilities.
Two platforms that spent a decade building from different starting points, one out of the data warehouse, the other out of the lakehouse, arrived at nearly identical product bets.
The product bets were consistent across both platforms: agents as the primary compute unit, MCP as the protocol layer, governance extended to AI systems, and tighter controls on model access and spend. Each platform pushed further into the other's territory to keep more workloads in-platform.
When two platforms independently converge in the same direction, it usually means the market has already decided.
The message from both events was the same: the conversation is moving from building AI systems to operating them.
Three Signals That Actually Matter
1. Agents Are Becoming Core Infrastructure
A year ago, both companies were centered on data pipelines, warehouses, and analytics workloads. At their 2026 conferences, agents headlined both keynotes.
Snowflake rebranded Snowflake Intelligence into CoWork and Cortex Code into CoCo. Databricks expanded Agent Bricks, introduced Genie One, and reported more than 100,000 agents built on its platform, processing over a quadrillion tokens annually.
Agents are workloads, not features attached to them.
Both platforms also shipped a semantic context layer, Snowflake with Cortex Sense and Databricks through Genie's ontology layer, and the motivation is the same in both cases. Without semantic context, agents don't know what the data means in business terms. They have no shared definition of what a metric means, which tables are authoritative, or how your org structures its data. The result is iterative, exploratory queries on every run. Agents figure their way to an answer each time from scratch rather than starting from shared understanding. That's a quality problem and a cost problem. Cortex Sense addresses this by auto-assembling data, business definitions, and operational knowledge for agents, raising benchmark accuracy from 24% to 86% on structured context tasks.
On the Databricks side, Document Intelligence also went GA this cycle: ai_parse_document, ai_extract, and ai_classify are now available as SQL functions, closing the gap with Snowflake SQL AI functions. Worth knowing they exist and tracking their adoption as another inference-billed workload type: now, your very SQL workloads can carry AI inference costs.
What that means for spend: your warehouse and lakehouse bill is about to bifurcate. Agent-driven compute wasn't a meaningful line item a year ago. Based on the adoption trajectories both platforms cited, it will be a top-three spend category for many teams by end of year. The catch is that once agent calls blend into your analytics baseline, separating them retroactively is genuinely hard. In our experience, attribution difficulty increases roughly 10x once the workloads are mixed. The teams that tag agent workloads with a distinct query tag or cluster policy today, while volumes are still small enough to audit, will have the data they need when the bill scales.
2. MCP and Governance Are Moving in Different Directions
Six months ago, MCP was still an emerging protocol discussed mostly in developer circles. At both conferences, it showed up as infrastructure. The two platforms are building around it very differently, though.
Snowflake acquired Natoma, an MCP gateway that connects agents to enterprise systems. The strategic intent is clear; how Natoma gets embedded into Snowflake's product is less so.
Databricks' direction is more explicit. Unity AI Gateway is designed to be the base AI orchestration layer, governing AI workloads inside and outside Databricks. MCP services are managed assets within that gateway, alongside models and agents. The ambition is to govern the entire AI stack, not just what runs on Databricks.
This difference reflects something deeper about how the two platforms are built. Snowflake has always operated as a more closed, integrated environment. Databricks built a modular, exposed engine designed to be assembled with external tools. That DNA shapes how each platform is approaching AI governance now. Snowflake governs what runs inside Snowflake. Databricks wants to be the governance layer for workloads that run anywhere.
Both platforms also expanded their governance models to cover AI systems directly. Snowflake introduced AI Agent Identity, per-agent cryptographic identity with RBAC and dynamic masking, alongside AI Security Posture Management. Databricks expanded Unity AI Gateway with agent tracing and identity integrations. Governance now covers what is running autonomously inside the system, not just who authorized it to run.
That shift changes cost accountability. With agent identity, AI spend can be attributed directly to the agent, not just the team or environment that deployed it. The first 90 days of broad agent identity adoption will surface every org's runaway agent, the one looping on a poorly-bounded task, quietly burning 10 to 100 times a normal workload. Billing pipelines that capture agent_id now, before that incident lands on a finance dashboard, are worth the setup time.
On the spend control side: Databricks' Unity AI Gateway shipped enforced spend caps, cost attribution by user, team, tool, and use case, and smart routing that selects models on a quality-vs-cost basis. It's the strongest in-platform AI spend tooling either vendor has shipped. It's also blind by design to the majority of what most enterprises are actually spending. Unity AI Gateway governs AI spend inside Databricks. It does not cover direct Anthropic calls, OpenAI usage, Bedrock traffic, or Snowflake Cortex. For most enterprises running both platforms, that's somewhere between 50 and 80 percent of the total AI bill outside any cap-and-route mechanism.
The model mix is only getting wider. Databricks' roster now includes Kimi, Grok, OpenAI, Anthropic, Gemini, and Qwen. Snowflake deepened its Anthropic partnership, with Claude powering CoWork and CoCo. Most enterprises at scale are already mixing four to six models. The cost difference between the right model for a task and the default selection can be large. A Claude Opus call running a short classification task is roughly a 50x overspend compared to Haiku for the same job. The same mis-sizing logic that applies to an EC2 instance applies at the inference layer.
One more nuance worth flagging: Smart Routing's model recommendations are advisory. The bill lands as the code authored it, not as the gateway suggested. Visibility into the better option is not the same as acting on it. Teams that want to close that gap need a workflow to act on routing recommendations, not just a dashboard to read them.
The MCP orphaned-asset problem is worth tracking in parallel. Every prior abstraction layer produced what I'd call an orphaned-asset tax: Lambda functions, Kubernetes namespaces, dbt models, and inference endpoints all accumulated abandoned instances within roughly 18 months of going mainstream. The pattern is consistent: easy to create, no built-in retirement signal, slow to clean up. MCP servers are next in line. They're trivial to register, there's no native lifecycle management, and most teams will accumulate them faster than they document them. Early signals will show up in usage logs as inactive or orphaned endpoints. The cleanup process is easier to build before the proliferation than after it.
3. Both Platforms Are Racing to Own the Real-Time Layer
One of the less-discussed moves from both summits was a shared push toward sub-second analytical query performance.
Databricks shipped Lakehouse//RT. Snowflake has been investing in Interactive Warehouses. Neither is strictly new territory, but the timing and framing from both platforms signals something: the traditional BI boundary is no longer where either company wants to compete.
Part of what's driving this is external pressure. ClickHouse has demonstrated that mature platforms can deliver sub-second latency on analytical queries at scale. That's a benchmark both Snowflake and Databricks now have to answer.
The more consequential driver is agentic applications. Pre-aggregating data for known dashboards was a reasonable optimization when queries were predictable. Agentic applications don't have predictable queries. They respond to dynamic user inputs and need fast answers across data that hasn't been pre-shaped for any specific question. Sub-second latency matters differently when the query pattern is unknown at design time.
The storage duplication risk that follows: Databricks has continued investing in Lakebase, a transactional database designed to be agent-native. Agents can provision and operate on it with controlled risk alongside its analytical layer. Mirroring data between Lakebase and the analytical layer for performance is a natural pattern and a reliable way to accumulate redundant copies with no clear owner. The governance question shifts from "where is this stored?" to "which copy is the source of truth, and what reads from the others?" Row lineage tooling exists to answer this, but only if it's enabled from day one and someone owns reading it.
What Neither Platform Shipped
Neither platform shipped carbon or sustainability reporting at the workload level. As agentic compute scales, that gap will widen.
Neither shipped enforced cross-platform AI spend controls. Every enterprise running both Snowflake and Databricks still needs an aggregation layer outside either console to see the full picture.
The FinOps visibility story is worth unpacking specifically. Databricks announced FOCUS support at FinOpsX 2025, but it was never shipped as a product feature. What shipped instead was a GitHub repo you can deploy to your Databricks environment to produce the report yourself. The implicit stance: FinOps visibility is a data problem, and since Databricks is a data platform, they expect you to build it there. That works for visibility. For optimization and data curation, understanding which spend is worth cutting and actually acting on it, a BI query against your own warehouse won't give you what you need. That's a different class of problem.
And Snowflake didn't ship an answer to Unity AI Gateway's enforced spend caps at the AI layer. That's a gap worth watching in the next quarterly release cycle.
What Tech Leaders Should Do Now
The operational patterns that create problems at scale are already forming. The window to get ahead of them is now, while agent volumes are still small enough to instrument cleanly.
The immediate priorities: tag agent-driven workloads today, before they blend into the analytics baseline. Build MCP server lifecycle management before the endpoints accumulate. Attribute AI spend at the agent level, not just the team level. Track per-model unit economics against the actual task, not the default selection. Identify which data copies are sources of truth before duplication compounds.
What we've seen consistently at PointFive is that the teams who treat these as month-one problems end up with cleaner environments and more actionable data. The ones who treat them as year-two cleanup projects end up doing forensic accounting on a bill that's already scaled.
Visibility is improving inside individual platforms. The harder problem is understanding how those systems interact.
The next wave of AI maturity will be defined by whether organizations can operate across systems that were never designed to be operated together.
Ariel Lichterman is Cloud and AI Research Lead at PointFive.