Matching Isn’t the Move

The dominant reading of April 22 compresses the three-way contest into a leader-and-laggards shape. Google moved first on federation, the thinking goes, so the incumbents are now racing to match. The narrative is tidy. It is also wrong. Databricks shipped Unity AI Gateway on April 15 — seven days before Google. Agent Bricks Supervisor went GA in February. Snowflake Build London concluded on February 5 with Cortex Code, Semantic View Autopilot, and a $200 million OpenAI partnership. None of this is reactive. It is the visible output of eighteen months of work toward the same structural transition Google just named. When Google finally announced, the incumbents were already on the ground with different architectures. The question for enterprise architects is not who’s catching up. It is what each vendor is actually betting on.

The Catch-Up Illusion

The easiest way to misread the three-way race is to treat Google’s announcement as the trigger and the incumbents’ responses as the reaction. That framing holds only if you ignore the calendar. Databricks shipped Unity AI Gateway a week before Google. Agent Bricks Supervisor went GA in early February. Snowflake’s Build London conference concluded a full ten weeks before April 22 with the four announcements that define its 2026 posture. None of these moves is a response to April 22. They are the visible output of a year-long build arc toward the same structural transition.

What the timeline tells you is that all three vendors saw the same thing at roughly the same time: the substrate would converge, the moat would move up a layer, and whoever built the best runtime on top would define the next five years of enterprise data cloud competition. Each placed a different bet on what “best” means for different enterprise shapes. Each constructed a different architecture.

Three Bets on the Same Substrate

With the substrate common across all three vendors, differentiation has nowhere to go but up. The three architectural bets reveal themselves cleanly in what each vendor chose to lead with in the first four months of 2026. Read the emphasis, and the bet is unambiguous.

Google bets on reach. Knowledge Catalog reads Databricks Unity Catalog and Snowflake Polaris as peers via Apache Iceberg REST. Spanner Omni, Cross-Cloud Interconnect, BigQuery fluid scaling — every piece of the April 22 announcement is engineered for a world where enterprise data lives in fragments across clouds, catalogs, and platforms. Reach means the agent can reason across everything the enterprise owns, regardless of where it sits.

Databricks bets on depth. Unity AI Gateway extends Unity Catalog’s governance posture from data access to agent action. On-behalf-of authentication means every LLM call, MCP invocation, and external API request carries the identity of the human who initiated the workflow. Every action is lineage-tracked. Every tool call is observable in a single governance frame. Depth means every agent action is audit-grade.

Snowflake bets on access. Cortex Code writes SQL from natural language. Semantic View Autopilot auto-curates semantic views. Snowflake Postgres (via the Crunchy Data acquisition, integrated natively) removes the operational-analytical ETL seam. The $200M OpenAI partnership makes GPT-class models first-class inside Cortex AI. Access means the agent layer is usable by SQL-native teams without a platform-engineering team in the loop.

None of these is a copy of the others. None is a scramble to match Google’s move. Each is a fully-formed architectural thesis about what the agentic runtime layer will actually do for enterprise customers — and which customers will pay most for it.

Databricks Bets on Depth

The April 15 Unity AI Gateway release is the most architecturally revealing product announcement of Databricks’ quarter. Read as a feature launch, it extends Unity Catalog’s governance model to cover how agents call LLMs and external tools. Read as a strategic posture, it is a bet that governance sophistication — not federation reach — is what enterprise customers will pay for when they move agent workloads from pilot into production.

The mechanism matters. When an agent running inside Agent Bricks invokes an LLM or a third-party MCP server, Unity AI Gateway performs on-behalf-of authentication back to the human user who initiated the workflow. Every call is scoped to that user’s permissions. Every tool invocation is lineage-tracked against the same identity that authorized the original agent. Every LLM call is observable in the same governance frame as every data query. The agent can act, but it acts as the user — not as a service account with ambient authority.

That architecture answers a specific enterprise question: when an agent takes an action with business consequences, can the enterprise prove who authorized it, what policies applied, and whether it complied with the governance posture of the organization? For a regulated industry customer — financial services, healthcare, pharma, government — that question is not optional. It is procurement. Databricks is not trying to out-federate Google. It is betting that where governance is the binding constraint, the runtime with the deepest control-plane wins — and it has the deepest existing Unity Catalog deployment footprint from which to extend that bet.

Agent Bricks Supervisor, which went GA in February, extends the same governance model to multi-agent orchestration. When one agent delegates to another, the supervisor records the delegation, tracks the chain of authority, and enforces policy at each hand-off. The governance posture does not end at the single-agent boundary. Unity Catalog Business Semantics, open-sourced in Apache Spark the same week as Google’s announcement, completes the picture: metric views, lineage, and metric governance available to any engine reading Unity.

The bet has a specific shape. If the binding constraint is audit-grade governance and compliance lineage, Databricks is the runtime to evaluate first. If the binding constraint is something else, Databricks’ governance-depth advantage reads as overbuilt.

Snowflake Bets on Access

Snowflake’s posture reveals itself most cleanly at Snowflake Build London, which concluded February 5. Four announcements landed together: Cortex Code, Semantic View Autopilot, Snowflake Postgres (the Crunchy Data acquisition integrated natively), and the $200 million OpenAI partnership. Read individually they look like feature updates. Read together they are a coherent architectural thesis: where time-to-value is the binding constraint, the runtime that wins is the one where business users get useful work out of agents without a platform engineering team in the loop.

Cortex Code translates natural language to SQL directly in the Cortex AI environment. Semantic View Autopilot auto-curates semantic views from underlying data, collapsing the most expensive part of analytical-layer preparation. Snowflake Postgres removes the operational-analytical ETL seam that has defined enterprise data architecture for a decade — OLTP and OLAP now share a query surface. The OpenAI partnership ensures the most commercially preferred frontier models are available natively inside Cortex, with no external routing, no custom integration, no model-gap risk.

Snowflake’s strategic thesis is visible in the emphasis. The runtime that wins, under this reading, wins on the shortest distance between business question and useful answer. SQL ergonomics, immediate model access, one-click semantic curation — the architectural bet is that production agent deployment bottlenecks on business-user adoption, not on governance depth. Enterprise customers who ship agents fastest capture the first wave of competitive advantage. Snowflake is engineering for that tempo.

Horizon Catalog and Apache Polaris governance federation remain the governance substrate underneath. Both are credible. Neither is what Snowflake is leading with. The strategic signal is consistent: Snowflake believes the audit-grade-governance race is a secondary concern for most enterprises, and it is over-indexing on the use-case-immediacy race instead.

The bet has a specific shape. If the binding constraint is AI-native product velocity and business-user adoption, Snowflake is the runtime to evaluate first. If the binding constraint is audit-grade governance or fragmented-estate data topology, Snowflake’s advantages read as a different competition.

Three Shapes, Three Constraints

The three bets map to three enterprise archetypes that need fundamentally different things from an agentic runtime. The mapping is not marketing segmentation. It is architectural alignment between what the enterprise actually needs and which bet answers that need.

The federated enterprise. Data scattered across AWS, Azure, Google Cloud, on-premises. Multiple catalogs. Fragmented acquisitions history. The binding constraint is: can the runtime even read our data without a two-year migration project? Google’s reach bet answers this question. Knowledge Catalog’s bi-directional federation and Spanner Omni’s cross-cloud posture are engineered for exactly this problem. Databricks and Snowflake both reach across clouds, but Google currently leads in federation surface area.

The regulated enterprise. Financial services, healthcare, pharma, government. Data is consolidated, often on one primary platform. The binding constraint is: can we prove to auditors what each agent did, on whose behalf, with what permissions? Databricks’ depth bet answers this question. Unity AI Gateway’s OBO authentication, cross-layer observability, and multi-year Unity Catalog deployment footprint are engineered for this problem. Google and Snowflake are credible but neither matches the audit-grade integration depth.

The product-velocity enterprise. SaaS companies, consumer-facing products, fast iteration cycles. Agents must ship quickly, models must change frequently, business users must get results without data engineering bottlenecks. The binding constraint is: how fast can a non-engineer get a useful agent into production? Snowflake’s access bet answers this question. Cortex Code, Semantic View Autopilot, native OpenAI access, and Snowflake Postgres’ operational-analytical convergence are engineered for this workload profile. Google and Databricks are credible but neither matches the time-to-value.

For enterprises running serious runtime evaluations, the order of the five decision questions matters as much as the questions themselves. Data topology dominates. Workload profile narrows. Governance, model access, and exit plan refine.

• 1
  Data topology Where does our data actually live — single platform, fragmented estate, or multi-cloud? The answer determines whether federation reach matters more than governance depth. The federated enterprise that picks a depth-first runtime will spend the next 18 months paying migration costs; the consolidated enterprise that picks a reach-first runtime will pay for capabilities it cannot use.
• 2
  Agent workload profile What workloads are we actually running — regulated, analytical, customer-facing, cross-system orchestration? Different workloads have different binding constraints. A bank’s loan-approval agent and a SaaS company’s customer-support agent impose fundamentally different architectures on the same runtime.
• 3
  Governance posture Do we need audit-grade action traceability, or directional access controls? This determines whether Unity AI Gateway’s OBO authentication is a must-have or a nice-to-have. Regulated enterprises cannot treat this as nice-to-have; product-velocity enterprises often should.
• 4
  Model access flexibility Best-of-breed model swap as frontier models release, or stability? Snowflake-OpenAI is the strongest single bet. Databricks and Google are more model-agnostic. The enterprise that believes frontier capability will keep shifting wants agnosticism. The enterprise that believes the top-tier is stable wants tight native integration.
• 5
  Substrate exit plan If we migrate runtimes in 2028, what actually has to move? The substrate convergence is the insurance policy. Data stays put, catalogs are portable, table formats are open. Runtime commitment is where the real migration cost lives — agent lineage, decision traces, governance policies, HIL escalation records.

What None of Them Answers Yet

The three-bets framing is useful for selecting a runtime in 2026. It is not sufficient for understanding where the architecture converges in 2028. For that, the agentic runtime needs to be defined — not as a product category, but as a load-bearing architectural layer with specific, enumerable requirements.

Post 1 in this series named this with a forward-reference: the agentic runtime is better understood as decision infrastructure. That claim needs earning. Decision infrastructure is not a reframe or a rebrand. It is a specification.

The five are not a taxonomy. They are a load-bearing specification — each one a named failure mode when absent. Strip permission and agents act without institutional authority; at enterprise scale, this is a non-starter in regulated workflows and a liability in every other workflow. Strip decision-trace persistence and the enterprise loses the ability to answer “what did the system decide, when, and why” — no auditability, no post-incident reconstruction, no legal defensibility. Strip policy enforcement independent of agent execution and governance collapses into agent prompts; policy becomes unreviewable, unversioned, and unenforceable across agents. Strip human-in-the-loop capture and the enterprise has no structured escalation path when autonomous confidence runs past acceptable thresholds; every edge case becomes a production incident. Strip orchestration and the other four have nothing to operate on. The test is not whether these five are elegant. It is whether a serious enterprise can operate agents at scale without any one of them. The answer, in each case, is no.

Map each vendor’s bet against the five components and the pattern becomes unmistakable. Google’s Gemini Enterprise ships strong orchestration and federation-scope permission. Decision-trace persistence exists as observability — but observability is not decision persistence. Debug logs are not decisions-as-entities; traces you can query for performance tuning are not traces you can query for audit-grade decision reconstruction. Policy enforcement runs through agent configuration rather than through an independent policy plane — but policy in agent configuration is not an independent policy plane. Policy embedded in the agent is policy that changes when the agent changes, policy that cannot be enforced across agents, policy that auditors cannot review outside the runtime. The gap is structural on components three and four.

Databricks has strong permission (Unity AI Gateway OBO), strong policy enforcement (Unity Catalog is the policy plane for both data and agent action), and partial decision-trace persistence via MLflow lineage extending into Unity. HIL capture through Agent Bricks Supervisor is maturing. The structural gap is federation reach — Databricks can read across clouds, but cross-cloud read capability is not architectural federation. Architectural federation means the runtime treats cross-catalog, cross-cloud data as peers at the compiler level, with policy and permission composing across the federated view. That is not where Databricks centers its architecture. For the federated enterprise, this is not a feature gap; it is a different architecture.

Snowflake has strong orchestration (Cortex, semantic layer, Autopilot) and strong model access (OpenAI native). Decision-trace persistence does not exist as a first-class layer. The architecture captures query history and lineage — but query history is not decision trace. Query history tells you what ran; decision trace tells you what the system decided, against which policy, with what alternatives considered, and why. They are different entities, and shipping the first does not ship the second. Policy enforcement independent of agent execution is the weakest of the three relative to Databricks: Horizon and Polaris are credible data-governance layers, but data governance is not agent-action governance. HIL capture is not a 2026 architectural emphasis.

What ties the five components together, across agents and over time, is not itself one of the five. It is the persistence layer that holds the decision history, the applicable policies, the escalation records, and the composed reasoning traces — and makes them queryable, cross-referenceable, and durable beyond any single agent session. Decision traces without a persistence layer are logs. With it, they become infrastructure. Luminity’s broader work calls this layer the context graph: a substrate above the runtime that makes decision infrastructure coherent across agents, across sessions, and across governance boundaries. Partial emergence is already visible — Unity Catalog’s lineage graph, Snowflake Horizon combined with Polaris governance federation, Google’s Knowledge Catalog with Dataplex lineage. Each is a fragment of what the full requirement will look like. None of the three is the substrate itself. The context graph is not an alternative to decision infrastructure. It is what decision infrastructure becomes when the five components are made durable. What the market is currently shipping is the shape of the requirement. What will ship next is the requirement consolidated into a named architectural layer — and the vendor that ships it first defines the battle that comes after this one.

Eighteen Months, Not Five Years

The substrate battle took five years to resolve. The runtime battle will not get five years. Three structural reasons compress the timeline.

First. The substrate is common ground now, which means it cannot serve as a differentiation vector. Every vendor knows it. Every vendor is under pressure to move up. The incentive gradient is steep.

Second. Enterprise commitments made in 2026 become migration costs by 2028. Runtime choices carry forward into every agent an enterprise ships. The decisions are sticky in a way that data-format choices never were. The market will force early commitment.

Third. The substrate battle converged on open standards — Iceberg, Iceberg REST, MCP. The runtime battle has no equivalent open standard yet. In the absence of a standard, commercial commitments accelerate architectural lock-in. Enterprises that defer runtime commitment past 2027 will find the market resolved without them.

What this compresses toward is not a single winner. It is a shape: three primary runtimes, each optimized for a binding constraint, with the gap between them defined by how completely each vendor builds decision infrastructure. The vendor that ships full decision infrastructure first — all five components, production-grade, composable across the context graph — does not just win enterprise runtime choice. It defines the battle that comes next.

The market’s direction of travel is not an open question. Decision infrastructure is a load-bearing specification at enterprise scale, not a feature selection. Any runtime that does not converge toward these five components will be replaced by one that does. Vendors who treat the five as optional will cede the regulated and federated workloads where the specification is binding — and those workloads are where the long-horizon commitment sits. The market will not standardize around better tools. It will standardize around decision infrastructure, and the vendors that do not converge toward it will not define the runtime layer. That is the inevitability the eighteen-month compression is running on.

For enterprise architects evaluating runtime commitments in 2026, the practical conclusion is narrower than the strategic reading suggests. There is no universal best runtime. There are three architectural bets matched to three enterprise shapes. The decision moves in one direction: pick the binding constraint first. The vendor follows. The substrate carries the portability. The runtime carries the commitment. And the context graph — when it arrives — carries what comes next.