The Industry Is Watching GPU Prices. Google Just Moved the Fight to the Judgment Layer.

There is a common criticism that comes out of large cloud events: “There were no real announcements.”

I understand the reaction. If you define an announcement as a brand-new primitive that did not exist the week before, then Google Cloud Next can feel underwhelming. Knowledge Catalog is Dataplex reframed. ADK is Vertex AI agent tooling consolidated. The Agentic Data Cloud is BigQuery plus the lakehouse plus the catalog presented as a unified surface. Agent Runtime is Cloud Run with agent-specific optimizations. The cross-cloud lakehouse is built on Iceberg and Cross-Cloud Interconnect, which already existed.

None of these are new primitives. All of them are remixes.

And the remix is the point.

I say this as someone who has been running a production AI system on Google Cloud for ten months. I was building on top of these capabilities — Cloud Run, Cloud Storage, Gemini, Vertex AI — and I did not see the architectural pattern until the conference reframed them. The pieces were under my feet the entire time. I was standing on the answer to my own grounding problem and did not recognize it because the platform had not yet explained itself that way.

That is what a good remix does. It does not introduce something new. It makes something that was already there visible — and in doing so, changes what an architect thinks is possible.

When a vendor announces a brand-new product, you are looking at a roadmap. When a vendor remixes existing capabilities into a new control point, you are looking at something closer to production-ready — because the underlying pieces have been running in production already.

Google Cloud Next had 250 announcements. The industry looked at them and asked, “What’s new?” The better question is: what is the strategic pattern?

The pattern is this: Google is systematically remixing existing platform capabilities into the borrowed judgment layers — Layer 1C and Layer 2C in the 4+1 model — while the market argues about the price of compute.

The $4/hour GB200 is real. The neocloud price war is real. And it is happening at a layer where Google does not need to win.

We Have Seen This Play Before

This is not a new strategy. It is the exact strategy public cloud has used since its inception as a category.

Cloud providers have always been happy to sell you bare metal infrastructure. There is nothing new about fast networking, compute, and storage. The industry made the mistake of thinking the cloud was just someone else’s data center. It was not. The cloud was managed services, identity frameworks, governance primitives, and operational abstractions that became so deeply embedded in how organizations ran their workloads that leaving meant rebuilding — not the infrastructure, but the operational logic on top of it.

The value was never the VM. The value was IAM, managed databases, serverless functions, identity federation, logging, monitoring, policy engines — the layers above the infrastructure that encoded how an organization operated. That is where the switching costs lived. That is where the margin lived. And that is what most enterprises did not understand until they tried to move.

Here is how completely AWS won this fight: how much do you pay for CPU in your Lambda functions? You do not know. You do not care. AWS succeeded in making the infrastructure layer invisible and the abstraction layer indispensable. The compute is commodity. The operational model built on top of it is not.

The AI infrastructure market is replaying the same pattern, compressed into a shorter timeline. The neoclouds are the new colocation providers — real value, real price advantage, real infrastructure. And the hyperscalers are doing exactly what they did last time: selling the commodity layer competitively while building the judgment layers above it where the real lock-in lives.

The only difference is the layers have new names. Layer 1C instead of the managed database nobody thought about leaving behind. Layer 2C built on top of IAM and policy engines, extending them into agent governance. Knowledge Catalog instead of the data catalog nobody opened. ADK instead of the agent framework every team was stitching together themselves. The pattern is identical. The question is whether CTOs will recognize it faster this time.

Where the Money Actually Flows

Start with Layer 0. The physical infrastructure. The network fabric, the data centers, the power, the cooling, the global footprint. Google will sell as much capacity as the market will absorb. Anthropic will buy as much as Google can sell at competitive rates. The labs (OpenAI, Anthropic) do not want to build data centers. They want to run models. Google is happy to be the foundation they run on.

Layer 0 is not where the margin fight happens. Layer 0 is scale and physical advantage. But it is where the neoclouds compete. CoreWeave, Lambda, Crusoe — they offer cheaper compute, and the price pressure is real. Google announced TPU 8t and 8i, Axion processors, Vera Rubin NVL72 instances. They will compete here. But Layer 0 is not where Google is trying to differentiate for the enterprise buyer.

Layer 1A in the 4+1 model is data storage and governance — where your data sits, how it is organized, how it is protected. In 2026, this is table stakes. S3-compatible, Iceberg-capable, fast, reliable, portable. Every serious vendor passes this test. Layer 1A is the qualifying round, not the differentiator.

The models are good enough. Gemini, Claude, GPT, Llama — for most enterprise use cases, the model is not the bottleneck. Google knows this. That is why the keynote was not a benchmark competition against Anthropic or OpenAI.

The keynote was about something else entirely.

The Keynote Was Not About the Labs

Here is what was different about Google Cloud Next compared to most AI conferences this year.

The keynote did not center model performance. It did not center the labs. It did not spend its time on benchmark comparisons against Anthropic or OpenAI.

It centered the space between “I got a demo working” and “this runs in production across my enterprise.”

That is the gap where every enterprise is stuck right now.

The demos at Next showed agents pulling the right facts from scattered systems in real time, handling 80,000 patient handoffs per day at HCA Healthcare, orchestrating multi-agent procurement workflows at Unilever. None of that is a model problem. All of it is a production infrastructure problem — governed context, agent orchestration, trust models, audit trails, identity frameworks, cross-cloud data access.

Google spent three days in Las Vegas making the case that they are the platform that closes the production gap. And the production gap lives at Layer 1C and Layer 2C — exactly the layers where Google remixed existing capabilities into new control points.

Layer 1C: The Remix That Changes What Architects See

I wrote about this in detail [in my Knowledge Catalog analysis]. The short version:

I run a production AI system — the Virtual CTO Advisor — on Google Cloud. I have been building on this platform for ten months. During that time, I struggled with the grounding problem — how to make the system reason from my body of work with the right authority, freshness, and source hierarchy. I tried Google Search grounding. I tried Vertex AI Search at $1,500 a month. I tried lower-friction retrieval options. None of them solved the deeper problem, which was not retrieval. It was authority.

The entire time, the building blocks for the solution I needed were sitting inside the platform. Dataplex had metadata and lineage. Data Catalog had discovery. BigQuery had the semantic relationships. Gemini had the intelligence to build the graph. Cloud Storage had the substrate.

I did not see it. Not because I was not looking — I was actively trying to solve this problem. I did not see it because those capabilities presented themselves as data governance plumbing, not as an AI grounding architecture. I was looking for a RAG solution. The answer was a catalog-and-graph solution. And the platform did not make that visible until the remix.

That is the point. Google did not invent metadata at Next. They did not invent lineage, cataloging, semantic relationships, or governance. Those pieces were already present. What Google did was remix them into the Knowledge Catalog — and in doing so, made a previously hidden architecture visible.

Before the remix, those capabilities looked like data governance tools. After the remix, they look like the authority layer for AI grounding. That is not a cosmetic change. It changes what an architect sees when looking at the platform. It changes which problems feel solvable and which paths feel buildable.

If I missed this pattern after ten months of building on the platform, most enterprise architects evaluating GCP from the outside have not even started to see it.

The Knowledge Catalog is not a storage product. It is an authority product. It does not store your data. It becomes the place where meaning, authority, lineage, and source relationships are modeled — which sources are canonical, which definitions apply, which relationships should travel with the answer, which context is safe to expose to a model.

And it works cross-cloud. Google’s lakehouse queries Iceberg data sitting in AWS or Azure without moving it. The data stays where it is. The judgment layer runs on Google.

That is not a storage play. That is a lock-in play at the layer where lock-in actually matters. And the fact that it is built on capabilities that have been running inside Google for years is what makes it credible. This is not a roadmap. This is a reframing of production infrastructure.

My grounding problem is a small version of the broader enterprise problem. I thought I needed to buy or build private RAG infrastructure. What I actually needed was an authority layer — a way to model which sources matter, which versions are current, and which context has standing. Google’s remix made that visible. Now apply that same pattern to every enterprise trying to move from demo to production. The problem is the same. The scale is different. And the borrowed judgment cost is higher.

Layer 2C: The Same Remix, One Layer Up

ADK — the Agent Development Kit — reached v1.0 at Next. Alongside it: Agent Studio, Agent Runtime with sub-second cold starts, Agent Memory Bank, Agent Sandbox, Agent Identity, Agent Gateway, and the A2A protocol running at 150 organizations.

The same remix pattern applies. ADK is not a brand-new agent framework. It is the consolidation of capabilities Google has been building across Vertex AI, model serving, and orchestration tooling into a coherent developer surface. Vertex AI became the Gemini Enterprise Agent Platform. Google Agentspace was absorbed into Gemini Enterprise. The pieces were already there. The remix made them legible as an agent production stack.

And again — the fact that these are remixed capabilities, not new ones, is the signal to pay attention, not dismiss. The underlying pieces have been running inside Google. The remix means Google believes the enterprise market is ready to adopt them. That is a maturity signal, not a marketing signal.

Brian Delahunty, Google Cloud VP of Engineering, offered the clearest definition of an agent I have heard: “An agent is a piece of software that is capable of figuring out the steps required to achieve an outcome using the tools available to it, without you telling it specifically how to use those tools.”

That definition matters because the governance questions are embedded inside it. If the agent figures out the steps, who defines what normal behavior looks like? ADK includes agent anomaly detection — monitoring behavior against a baseline. Whose baseline? Google’s.

If agents delegate to each other via A2A, who owns the inter-agent trust model? That was the thinnest part of the Next presentation. When a vendor glosses the hardest problem, that is where you push.

If Agent Gateway handles authentication and Agent Identity assigns IAM credentials per agent, those are genuinely good ideas. They are also decisions you are delegating to Google’s enforcement model. Which of those decisions touch regulatory, clinical, or financial domains where your organization cannot outsource the authority?

If ADK agents discover tools dynamically at runtime through an API registry, the agent selects the tool and you see the outcome. The selection reasoning lives inside the platform. Is that visibility sufficient for your compliance requirements?

These are not theoretical questions. HCA Healthcare answered them by making an explicit architectural choice: control over autonomy. They retained authority over the output validation layer — citation agents that ruthlessly cut any generated content that cannot be tied back to a source record — while delegating orchestration to the platform.

That is the decision every enterprise needs to make before picking a tool. Not which agent platform is best. Which decisions you are prepared to delegate, and which ones you need to own.

That is the DAPM question applied to the agent layer. And Google just built the platform that forces you to answer it.

What the Neoclouds Cannot Sell You

Here is the part the industry is not seeing.

The neocloud value proposition is real at Layer 0. Cheaper compute. Faster GPU access. Better price per FLOP. If you are training a model or running batch inference, that price matters.

But Layer 0 alone does not get you to production.

The CTO who buys $4/hour GB200s from a neocloud still has to answer: who provides my context authority layer? Who provides my agent orchestration and governance layer? Am I building a Knowledge Catalog equivalent myself? Am I stitching together open-source agent frameworks and hoping the governance story holds up when the auditors arrive?

A neocloud does not give you a managed semantic graph. It does not give you agent anomaly detection. It does not give you cross-cloud authority resolution. It does not give you A2A with 150 organizations already running the protocol. It does not give you Agent Identity with IAM-level enforcement per agent.

That is not a criticism of neoclouds. It is a structural observation. They are competing at Layer 0. And the CTOs who are making infrastructure decisions based on compute price without answering the 1C and 2C question are going to discover that gap the hard way — the same way I discovered it when I tried to move vCTOA off Google Cloud and the judgment did not travel with the data.

The Strategic Pattern

Strip away the 250 announcements and the pattern is clear. Google remixed existing capabilities at the two layers where enterprise lock-in actually lives.

Layer 0: Google sells to everyone. Anthropic will buy as much as Google can build at competitive rates. The labs do not want to build data centers. They want to run models. The neoclouds compete here — cheaper compute, faster GPU access. The margin is in scale and physical advantage, and it is compressing.

Layer 1A: Data storage and governance. Table stakes in 2026. S3-compatible, Iceberg-capable, fast, portable. The models are good enough for most enterprise workflows, and the serving layer can run on anyone’s Layer 0 infrastructure. Neither Layer 0 nor Layer 1A is where Google is trying to differentiate.

Layer 1C: Knowledge Catalog, Smart Storage, Cross-Cloud Lakehouse, BigQuery Graph, LookML Agent. Remixed from Dataplex, Data Catalog, BigQuery metadata, Gemini, and existing governance tooling. This is where Google is building enterprise lock-in. Not by trapping your data — by becoming the place where your data’s meaning, authority, and relationships are modeled.

Layer 2C: ADK, Agent Platform, Agent Runtime, Agent Identity, Agent Gateway, A2A, Agentic Defense. Remixed from Vertex AI, Cloud Run, IAM, and model serving infrastructure. Same play, one layer up. Not by trapping your agents — by becoming the governance infrastructure your agents depend on.

For enterprise AI, the profit is in the judgment layers. The infrastructure layers are the foundation that makes the judgment layers possible. But they are not where Google is trying to differentiate.

And the cross-cloud lakehouse is the judo move. Google is saying: we do not even need your data to move to GCP. Leave it in AWS. Leave it in Azure. We will bring the judgment layer to your data. The data stays where it is. The catalog, the reasoning, the governance — that runs on Google. That is where the value lives. That is where the switching costs are real.

The remix pattern is what makes this credible. Google is not asking enterprises to adopt unproven products. They are asking enterprises to adopt a new framing of capabilities that are already embedded in the platform. And once you adopt that framing — once you start thinking about your data through the Knowledge Catalog’s authority graph, once you start building agents through ADK’s orchestration model — the judgment you are borrowing has been baking inside Google’s infrastructure for years. It just did not have a name enterprises could point to.

The Question for Every CTO

The “race to zero” framing only works if you think AI infrastructure is Layer 0.

Google Cloud Next just demonstrated that they are competing at 1C and 2C — where the stickiness is not price. It is judgment.

The $4/hour GB200 does not matter if your authority model, your agent orchestration, your anomaly baselines, and your inter-agent trust policies are all encoded in Google’s stack. You are not migrating a VM. You are migrating how your organization thinks.

So the evaluation framework is not “which cloud has the cheapest GPU.” It is:

For each layer of the 4+1 model, who is your provider? What judgment are you borrowing from them? And what would it cost — not in dollars, but in architectural rebuild — to leave?

If you are on a hyperscaler, the answer may be the same vendor across multiple layers. Understand what that coupling means for your decision authority. Go in with eyes open, the way HCA did.

If you are on a neocloud, you might have a great answer at Layer 0 and no answer at Layer 1C and 2C. Understand what that means for your path to production. The compute savings do not help if you cannot get from demo to deployment.

And if your organization cannot answer who has decision authority for Layer 1C and Layer 2C, it does not matter which vendor you pick. You have already ceded the most important part of your AI system to whoever made it easy first.

That is the lesson of Google Cloud Next. Not 250 new products. 250 remixes — and the ones that matter most are the ones that productized borrowed judgment at the layers the industry is not watching.

The fight moved upstack. The neoclouds are competing where the margin is compressing. Google is competing where the judgment is accumulating. And most of the industry is still watching GPU prices.

Work Through This With Peers

I run vendor-sponsored Buyer Room sessions where senior technology leaders — CTOs, VPs of Infrastructure, Enterprise Architects — work through real evaluation decisions together. The vendor sponsors the session and gets structured feedback from the room. The participants get a peer conversation with leaders navigating the same architectural choices, with no sales pitch and no slide decks.

The next Buyer Room is focused on AI infrastructure layer ownership: where your organization is borrowing judgment, where that borrowing is intentional, and where it happened by default.

If you are a technology vendor building at Layer 1C or 2C and want structured CxO feedback on your positioning, or if you are a senior technology leader who wants to work through the borrowed judgment question with peers, reach out directly: [email protected].