I am old enough to remember when people questioned whether Google Cloud even had a future within Alphabet. Well now we have a pretty clear answer – yes. I originally began this post as a quick roundup of news from Google Next 2026, but given Google’s results dropped the following week, let’s look at them first.

In the first quarter, Google Cloud revenue jumped 63%, year over year, to $20 billion, in the parlance of the day – absolutely crushing it. To the moon, etc. Growth rates like that on an already hyperscale business is quite something. Google Cloud now accounts for 18% of Alphabet’s total revenue. Which is to say, it’s a keeper.

Sundar Pichai, Google CEO said:

“Google Cloud is differentiated because we are the only provider to offer first-party solutions across the entire enterprise. Our growth in revenue, operating margin and backlog highlights this differentiation.”

AWS and Azure also had excellent quarters, but Google’s growth, even though from a lower base, was still a clear marker of substantial progress. I often say the best packager in any tech wave wins and wins big, and Google is looking increasingly well positioned. Packaging and integration go together hand in hand – you want an offering that makes things easy for the customer, reducing cognitive and organisational overheads. But packaging and economies of scale are also closely entwined – Google is well placed here because it owns technology up and down the stack.

Google also really pushed its position as a “full stack” AI infrastructure provider- it has technology leadership that spans from custom silicon to productivity apps, and unlike Microsoft and AWS it has its own capable frontier model in the shape of Gemini.

It is agents and harnesses however that are really going to drive model growth.

The agent platform

At Cloud Next Google announced tools for agent management and orchestration, and demonstrated continuing strength and depth in data infrastructure. It also apparently reintroduced Knowledge Management as an enterprise concern for the AI era.

The agent story is on point because, frankly, agents are finally capable enough to do some real work (on their own). Developers noticed a step change in coding agents around the turn of the year, arguably as big a leap forward for AI capabilities as the launch of ChatGPT in November 2022.

You just have to use the tools to see the clear difference in capability, or listen to AI-savvy developers across the industry. We’re in a fundamentally different environment now – the code being generated now is of a much higher quality, and with agents, an entirely new degree of autonomy.

Devs also began to better understand the value of brute force, and single task iterative loops (see the “Ralph Wiggum” pattern, invented and popularised by Geoff Huntley) in getting agents to do what they wanted. Harnesses are also becoming more effective, for example in providing consistent developer experiences as models evolve. If agents are getting this good at building and deploying software, other business processes are also going to be affected. The infrastructure we rely on just wasn’t built with agents and models in mind though – scale, security and management challenges are all massively increasing.

Google introduced Gemini Enterprise Agent Platform, building on and replacing its Vertex AI platform, with new features in its Agent Development Kit, scale and memory improvements for its Agent Runtime, but most importantly from a manageability perspective – Agent Identity, Agent Registry, and Agent Gateway. The central idea of Agent Identity is that you can assign every AI agent a unique cryptographic identity. Google also announced Agent Simulation, Agent Evaluation, and Agent Observability. Evals are as important to LLM apps as unit tests are to current software development. Observability is of course more important than ever, given we need to understand outputs and behaviours in production.

Google’s Dev Rel team did a solid job explaining how all of these tools play together in a demo during the developer keynote on day two – with a scenario of planning a marathon in Las Vegas. Each step in the development process was outlined and explained during the keynote.

For example a demo featuring Agent Studio – a collaborative workspace for building new agents. Key to the demo flow as whole was making it clear that different tools will be used by different personae, including “low code” developers using natural language, people living in markdown for specs, specs that cover business rules, not just software guardrails. Prebuilt agents include code modernisation, financial analysis, and deep research.

We’re going to see a lot more marketing around agent capability from platform providers as agents become more capable and widely deployed – indeed it’s pretty much the 2026 summer keynote.

The agent permission, security and identity play

With agents you have a bunch of autonomous systems using non-deterministic models to try and achieve outcomes. These agents are capable of taking action – sometimes very bad actions, such as deleting production databases. They absolutely need guardrails, and a markdown file just isn’t going to cut it. That’s where tools like Agent Identity come in. Permissions will need to be tightly managed. Role based access control (RBAC) will be essential for this agent buildout. But things are made even more challenging because most agents are ephemeral. RBAC systems were built for employees, and perhaps contractors, not agents you spin up and dispose of in minutes. New scale challenges everywhere you look.

Simon Willison coined the phrase the lethal trifecta:

• Access to your private data—one of the most common purposes of tools in the first place!
• Exposure to untrusted content—any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM
• The ability to externally communicate in a way that could be used to steal your data (I often call this “exfiltration” but I’m not confident that term is widely understood.)

“If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.”

Threats are growing all the time, partly because the tools are so powerful. Take OpenClaw, for example, designed as an AI personal assistant, arguably the fastest growing open source project in software history. OpenClaw reached 250,000 GitHub stars in about 60 days, surpassing React, which took over a decade to reach the same milestone. OpenClaw drove a spike in Mac mini sales as developers clamoured to use the software with a modicum of safety. The project went from launch to explosive growth to acquisition by OpenAI in about three months. Peter Steinberger, the lead developer, is now at the forefront of the movement to create agents that can do a range of tasks on behalf of the individual. For now it’s a developer play, but in the longer term it will be for enterprise users as well. It is a capable autonomous agent, built for messaging and integration to third party systems. But deploying it on your corporate network without a huge amount of supporting security infrastructure would be extremely foolish. It’s definitely not ready for the enterprise at this point. It’s simply too powerful as a lethal trifecta accelerant.

Agent sprawl drives the need for orchestration platforms

Orchestration platforms are increasingly a necessity because software developers are using teams of autonomous agents, sometimes working in parallel, but requiring asynchronous communication for handoffs and state management (memory) in the service of tasks and workflows.

This pattern reminds me of the evolution of containers and microservices. The container revolution began with devs running Docker locally on their laptop. As complexity compounded we needed an orchestration layer to manage all of these containers in production, which is how Kubernetes came into being. We’re now at a similar point with agents.

Agents as the primary driver of scale

Agents also drive much higher scale requirements. Look around the industry and you can see existing players and startups crushing it, or being crushed by, agent generated workloads. GitHub’s reliability issues are being exacerbated by agent-based software growth. There’s just so much software being built. Just look at Jarred Sumner of OpenAI, who just rewrote the entire Bun Javascript runtime in Rust, replacing the Zig implementation. One million lines of Rust code, all AI-generated. Regenerated is probably a better word than rewritten. Open Source projects are like Doctor Who now. Across the industry there are thousands of Sumners, also building huge code bases and new applications at an entirely new speed.

Token Economics and the Full AI Stack

Being an end to end stack player matters because it means you’re in control of costs of goods sold. You’re not reliant on third parties to serve customers, which is a clear economic advantage.

Control of cost is so important because the future of AI is going to be defined by token economics – that is, who can offer the greatest range of capabilities at the lowest cost. Anthropic and OpenAI are both going to raise prices in order to meet their sky high valuations. In recent months it’s become clear that the cheap token era is ending, even as some developers crow about “tokenmaxxing” as a badge of honour or productivity.

OpenAI and Anthropic need third parties to provide chips – NVIDIA. They also need cloud providers to provide compute, network and storage – business for the hyperscalers, as well as Coreweave and to some extent racle. Meanwhile AWS, Azure and GitHub are reliant on OpenAI and Anthropic (and their eye-watering balance sheets) to provide frontier models and associated services to their customers.

Owning a capable first party model is a crucial competitive advantage. At Next 2026 Google Cloud CEO Thomas Kurian announced that Google Gemini would be powering the next generation of Apple’s Siri service – see my post about it here. Gemini is now powering both Siri and AI services on Android phones worldwide — an almost incredible cloud win, given it covers most new phones being sold in the two key mobile ecosystems. Neither AWS nor Microsoft Azure could have won this deal given their reliance on third-party models.

What about the lower level stuff? Google has its TPU microprocessor architecture, which means that it’s not reliant on NVIDIA. AWS and Microsoft are investing in their own architectures optimised for model training. AWS will likely get there with Trainium, given the engineering process of its chip business – Graviton for general compute has been, and will continue to be, a huge differentiator for AWS as it seeks to lower the cost of compute for customers.

Google labelled its hardware advantage the AI Hypercomputer but we’ll largely stick to the agent story for the purposes of this post. It’s enough to say that AI is very specific in terms of compute patterns, and that’s why being in control of technology up and down the stack matters. And we haven’t even talked about the fact that Google Cloud also has a huge installed base of customers using its productivity tools. There is so much upside potential for integrations there.

But let’s cut to the chase. Enterprises are not going to take seriously the proposition that they should spend thousands of dollars per week per developer or agent. That’s not going to fly in Illinois, let alone Nairobi, Paris or Jakarta. I am old enough to remember enterprises balking at paying an extra $30 per calendar month per user for GitHub Copilot. So thousands of dollars per developer just seems unlikely at this point. Model choice is going to become more important, in this environment.

Data, Context and the new Knowledge Management

Data was the first business that Google Cloud landed in the enterprise, with companies making deep and strategic bets on Big Query, seeing Google as their “data cloud”. This beachhead is now increasingly realising gains in the AI space.

Google is world class at managing, and managed databases – Spanner is a globally distributed database offering near absolute transaction guarantees. It’s unique. It’s also increasingly appropriate for AI workloads, with multimodel capabilities including Spanner Graph, vector search and built-in full-text search. Google also offers Postgres in a couple of flavours, and Valkey for caching. You can have CloudSQL for MySQL if you’re looking for it, and for those so inclined of course you can get managed Oracle databases.

So what did Google announce at Next in the data space, to build on these strengths?

The key announcements were about what Google is calling the Agentic Data Cloud – key components of which are Knowledge Catalog, the cross-cloud Datalake, and the Agent Data Kit (meeting devs where they are, ensuring that Claude Code, Codex etc can do a solid job of accessing Google data services).

The Knowledge Catalog is essentially an AI-maintained index of all your enterprise data, structured so agents can actually use it. This is a modern, AI-inflected take on the classic Knowledge Management projects of the early web era.  We’re talking about Ontology with a capital O again.

Yasmeen Ahmad, managing director of Agentic Data Cloud at Google Cloud, is one of the best communicators in the industry. She introduced the data infrastructure section of the keynote, bringing the announcements to life with… Frozen Yoghurt. Yep – not a holiday booking, or revamping a camping company e-commerce site, but Froyo.

When you’re a food retailer you want to make sure you can meet people’s dietary needs – gluten and dairy free are both growth markets. Allergy information however might all be in a bunch of PDFs – it’s classic unstructured data, or what Ahmad calls dark data.

So what if the system identifies potential allergens? That’s new knowledge you can take advantage of for product management. So AI has enriched the knowledge catalog. But then you want to correlate that with a bunch of customer information about allergies. That might be in your system of record. But what if that database was hosted in AWS?

With Google’s Cross Cloud Datalake you can access data directly in third party clouds, using the Apache Iceberg standard. Finally you want to query the data before making a new product decision, so you use your favourite agent, and it’s ready to provide the correct answers based on your enterprise data via the Agent Data Kit. Great demo.

So the idea is that first you build a Knowledge Catalog. You don’t even build it. AI does.

I talked to Andi Gutmans, who runs Google’s data infrastructure and storage businesses. He said that humans are not going to be able to scale to the amount of data and events we’re talking about. Ontology is going to have to be machine learning based. Given the failure of Ontology efforts in corporations over the last few decades, partly because it’s just a hassle to annotate enterprise data with technologies like RDF, it would be hard to argue with him. Ontology, he argued, is actually an agent problem, so he has put together an “AI forward team to work on enrichment”.

The product design goal is essentially smart storage – a file lands, it’s instantly tagged, enriched and made agent ready. Every file or interaction should help the model learn about your business semantics. That’s where valuable context comes in. Google cited Virgin Media O2 as an early customer of the Knowledge Catalog, which it’s using across 20k different assets.

Of course you need a really good search engine on top of that ontology. Apparently Google has some proprietary search technology that is quite good.

We keep coming back to this question of human scale vs the scale that agents are going to drive. What does it look like to run an infrastructure business when a swarm of agents at a customer are going to spin up a hundred thousand databases in an hour and tear them all down again?

This is key to how Gutmans is architecting Google’s data products – agents take action, they don’t just make enquiries. Gutmans said Google Cloud is therefore now working towards an expectation of customers managing zettabytes rather than exabytes. Agents driving unprecedented data scale, just as they drive the need for compute, and transactions.

Rebuilding in flight

One thing I can’t stop thinking about that Andi told me:

“Now – I need to rebuild a lot of stuff we built a year ago.”

That’s the point. Everything – literally everything, is now about rebuilding in flight. You need to update your priors every day with AI, agent, and LLM progress, and that often means restarting projects because they simply don’t meet the new requirements. For an enterprise software business this is super hard. There are new product management disciplines required when the targets are moving so fast. This is going to find out a lot of companies, which are going to struggle with this rate of change and how to manage it. The days of ship it and then run it for the next decade are behind us. And if you don’t have an incredibly solid foundational platform, making these changes is all the more risky.

Related to this is the need to meet customers where they are. If enterprises thought shadow IT was hard, just wait til they start getting their heads around the new rates of tool adoption.

In a conversation at Next Peder Ulander, VP of marketing said:

“Years ago you could say here is an enterprise tool, and here is what you use at home.
It used to be – find a tool you like to work with, and maybe bring it into work two years later. Now it’s now the next year, it’s the next day.”

That’s the reality, and it’s a reality that agents are only accelerating. The tools are more capable than ever, the opportunities to improve business processes using autonomous agents is increasingly clear. People aren’t going to wait for traditional enterprise sales cycles to start using the tools. Vendors are going to need to respond with strong product led growth plays from the bottom up, supported with the usual large deal size top down procurement. The market is moving incredibly quickly, and Google Cloud is very well positioned for the agent era.