What changed at Google Cloud Next 2026
Google has done the thing it telegraphed for two years: it has stopped treating agents as an add-on and rebuilt the whole cloud AI surface around them. At Google Cloud Next 2026, Vertex AI — the brand that has carried Google's enterprise machine-learning story since 2021 — was renamed the Gemini Enterprise Agent Platform. In the same move, Agentspace, the standalone enterprise agent product, was folded into a single unified Gemini Enterprise offering. One console, one billing relationship, one place where models, tools and agents now live together.
For builders in India and the UK who have been stitching Vertex endpoints, custom orchestration and a grab-bag of tool integrations together by hand, this is both a relief and a warning. The relief is that the integration tax drops sharply. The warning is that the easier Google makes it to assemble an agent stack inside its walls, the harder it becomes to leave. Below is what was actually shipped, and the calls you need to make.
- It is a rename, not a retirement — existing Vertex projects, SDKs and endpoints keep working. Do not panic-migrate.
- A2A v1.0 is the headline — the Agent-to-Agent protocol is in production at 150 organisations. Cross-vendor agent interoperability is standardising in the open.
- Managed MCP arrives — Google now hosts MCP servers, with Apigee acting as an API-to-agent bridge. Convenient, and a soft lock-in if you are not careful.
- The Model Garden is the hedge — 200-plus models, including Anthropic Claude, behind one interface. Model portability, not platform portability.
Read the rename as a signal about where the gravity is moving, not as a migration deadline. The smart play this quarter is to adopt the open pieces — A2A, MCP, the Agent Development Kit — while treating the managed pieces as swappable conveniences. That keeps you fast today without surrendering your exit tomorrow.
The old-name to new-name map
Half the confusion in the room at Next was simply naming. Here is the translation so your architecture diagrams and your procurement paperwork line up.
| Before Cloud Next 2026 | After | What it is now |
|---|---|---|
| Vertex AI | Gemini Enterprise Agent Platform | The umbrella platform for models, tools and agents |
| Agentspace | Gemini Enterprise (unified) | Absorbed — no longer a separate product |
| Vertex Model Garden | Model Garden | 200+ models including Anthropic Claude |
| Ad-hoc agent builders | Workspace Studio | No-code agent builder for line-of-business teams |
| Bespoke tool wiring | Managed MCP + Apigee bridge | Hosted MCP servers; APIs exposed as agent tools |
| Pre-release agent SDK | ADK 1.0 (stable) | Agent Development Kit across four languages |
The supporting cast matters too. Project Mariner, Google's web-browsing agent, ships as a first-class capability for tasks that need to drive a real browser. And partner agents from Box, Workday, Salesforce and ServiceNow are available to drop into your workflows — which is genuinely useful if those systems already run your business, and a quiet deepening of platform gravity if they do not.
A2A v1.0 — the interoperability story that actually counts
The single most important announcement for anyone architecting a multi-agent system is that the Agent-to-Agent (A2A) protocol reached v1.0 and is in production at 150 organisations. A2A is the open standard for how one agent discovers, talks to and delegates work to another agent — across vendors, across clouds, across teams. Think of it as the HTTP of agent messaging: a shared contract so your orchestration agent can call a partner's billing agent without either side knowing the other's internals.
This is the part you should lean into. A2A is open and now versioned to 1.0, which means the protocol surface is stable enough to build on. For a fintech in Bengaluru wiring its underwriting agent to a third-party KYC agent, or a logistics firm in Manchester connecting its dispatch agent to a carrier's tracking agent, A2A means you are not hostage to a proprietary message format. The interoperability is in the open, not in Google's gift.
"We had three agents from three vendors and a translation shim between each pair — brittle, undocumented, ours to maintain. Moving the inter-agent calls onto A2A v1.0 deleted that shim layer entirely. The day we stopped owning glue code was the day the system got reliable."
— Anika, Verified Builder · Bengaluru, INManaged MCP — convenience now, portability later
The Model Context Protocol (MCP) is how an agent reaches its tools and data. Until now you ran your own MCP servers. Google will now host managed MCP servers for you, with Apigee acting as an API-to-agent bridge — point Apigee at an existing REST API and it exposes that API to your agents as MCP tools, no bespoke wrapper required.
This is a real time-saver. Standing up, securing and scaling MCP servers is undifferentiated work for most teams, and Apigee turning your existing API estate into agent tools is the kind of integration that used to eat a fortnight. But it is also where the soft lock-in lives. The MCP protocol is open; Google's hosting and bridging of it is not. The discipline that keeps you free is simple: keep your MCP tool definitions and server logic in your own repository so the same servers can run on your own infrastructure if you ever need to move.
Managed MCP plus the Apigee bridge is the easiest place to accidentally entangle your business logic with one cloud. If your tool definitions only exist inside Google's console, you have no exit. Treat managed MCP as a deployment target, not a source of truth — version your MCP servers in your own repo and you keep the convenience without the trap.
The Model Garden — a hedge, with limits
The headline number is 200-plus models in the Model Garden, including Anthropic Claude alongside Google's own Gemini family and a long tail of open-weight models. On paper this is a strong anti-lock-in story: you can route a reasoning-heavy step to Claude, a cheap classification step to a small open model, and a multimodal step to Gemini, all behind one interface, swapping the underlying model without re-plumbing your application.
Be precise about what that buys you, though. The Model Garden gives you model portability — you are not married to a single foundation model. It does not give you platform portability, because the orchestration, identity, billing and observability layers still sit with Google. A team in London that builds its entire agent runtime on the Gemini Enterprise platform and congratulates itself for using Claude has hedged the model risk and ignored the larger platform risk. Both are real; do not let one distract you from the other.
Want to discuss this with other verified Builders?
Every article on AI Tech Connect is written by a Verified Builder. Browse profiles, shortlist who you want to hire or collaborate with.
Browse Builders →Platform-versus-platform — where Gemini Enterprise sits
Consolidation is the theme of the year across all three big agent platforms. A quick comparison to ground your decision:
| Dimension | Gemini Enterprise | OpenAI / Azure | Anthropic / partners |
|---|---|---|---|
| Inter-agent protocol | A2A v1.0 (open) | Emerging, partly proprietary | MCP-led, A2A-compatible |
| Tool protocol | Managed MCP + Apigee | Function calling + connectors | MCP (open standard origin) |
| Multi-model | 200+ in Model Garden | OpenAI-first, some others | Claude-first, partner models |
| No-code builder | Workspace Studio | GPTs / Copilot Studio | Partner tooling |
| Lock-in shape | Deep, but on open protocols | Deep, ecosystem-driven | Lighter, protocol-driven |
The honest read: Google has chosen to build its moat on top of open protocols rather than instead of them. That is the best version of platform consolidation a builder can hope for — you get the convenience of one integrated stack, and the protocols underneath (A2A, MCP, ADK) are portable enough that a future migration is painful but not impossible. Compare that with platforms where the protocol itself is proprietary, and the difference in your eventual exit cost is large.
What platform consolidation means for a small team
If you are a five-person team in Pune or Bristol, the consolidation cuts both ways. The upside is concrete: one console instead of six, partner agents from Box, Workday, Salesforce and ServiceNow you can wire in rather than build, ADK 1.0 stable across four languages so you can pick the one your team already knows, and Workspace Studio letting a non-engineer prototype an agent before you commit engineering time. For a small team, that is weeks of integration work you no longer do.
The downside is platform gravity. Every managed convenience you adopt — hosted MCP, the Apigee bridge, the unified billing — is one more thread tying you to a single cloud. For a small team the answer is not to refuse the conveniences; it is to refuse to make them load-bearing. Build on the open protocols, keep your agent definitions and tool servers in your own repository, and treat Google's managed layer as a fast deployment target you could swap.
So — adopt now or wait?
Split the decision by layer rather than answering it all at once.
- Adopt A2A v1.0 now. It is open, versioned and proven in production at 150 organisations. The lock-in risk is low and the interoperability payoff is immediate.
- Adopt MCP now, managed MCP carefully. Use MCP as your tool protocol regardless. Use Google's managed hosting to ship fast, but keep the server logic portable.
- Use the Model Garden as a hedge, not a comfort blanket. Multi-model routing is real value; just do not mistake model portability for platform portability.
- Wait on deep Workspace Studio investment if your agents are genuinely complex — no-code builders are excellent for prototypes and line-of-business automations, less so for systems you will maintain for years.
Primary source: the Google Cloud Next 2026 announcements at cloud.google.com/blog. A2A protocol reference at a2a-protocol.org.