Gemini Enterprise Agent Platform: Google makes Agent Gateway, Identity and Registry the mandatory layer
20 May 2026. At the I/O keynote on 19 May, Google introduced the Gemini Enterprise Agent Platform — the evolution of Vertex AI with Managed Agents API, Agent Studio, a 2.0 release of the Agent Development Kit and the governance trio Agent Identity, Agent Gateway and Agent Registry. The architecturally interesting story is not the model, but that agentic governance is being bundled as runtime primitives in a platform package for the first time.

What happened
At the Google I/O 2026 keynote on 19 May, Google introduced the Gemini Enterprise Agent Platform as the evolution of Vertex AI — and for the first time bundled a full governance layer for agents into one platform package. New are the Managed Agents API, Agent Studio (the low-code path), a 2.0 release of the Agent Development Kit (ADK) and the three mandatory building blocks Agent Identity, Agent Gateway and Agent Registry, complemented by Agent Runtime, Agent-to-Agent Orchestration, Agent Observability, Agent Simulation and Agent Evaluation. Antigravity 2.0 serves as the shared protocol layer between locally developed and managed-deployed runtimes.
The bigger picture
Architecturally, this is not a model story but a governance story. In production agentic systems, identity has usually been a shared service account, the tool catalogue implicit, and audit an afterthought. Google now pushes this layer to the front as a mandatory trio: a unique identity per agent, a central policy enforcement point for every tool and MCP server call, and a searchable catalogue of all agents and tools. Structurally it is a service-mesh-plus-IAM pattern transposed onto the agent context — and it is the first complete attempt by a major hyperscaler to anchor agentic governance not in documents, but in runtime primitives.
What it means for the German Mittelstand
For the German Mittelstand this matters because the gap between “we tried out an agent” and “we let an agent touch production systems” sits exactly in governance. Three points become concrete. First, identity: a unique Agent Identity makes the question “who did this?” answerable in the audit log, without falling back on a shared service account. Second, gateway: a central policy point for tool calls is precisely what § 30 BSIG-neu (the German NIS-2 transposition) and Art. 26 EU AI Act demand for high-risk systems — enforceable, not merely documented. Third, registry: a searchable inventory of all agents, tools and MCP servers is the prerequisite for a clean record of processing activities under Art. 30 GDPR and, where applicable, for sectoral obligations such as BaFin/MaRisk or KAIT.
The reflex has to sit in front of the architecture decision. The platform package runs on Google Cloud — anyone who deploys it should clarify the third-country question and data residency with their data protection officer before the first agents go live. Vertex AI offers EU-regional ML processing for selected Gemini models, but not consistently across all of them. A data protection impact assessment with the concrete region and the concrete model selection belongs in front of the architecture design, not behind it. Whoever relies on the standard press release buys themselves a supply-chain and third-country question in the stack that becomes more expensive later than it is today.
What it means for technical development
Two observations place the package technically. First, the Agent Gateway becomes the controllable rail for MCP tool calls — precisely the operational layer that MCP as a specification (with the Linux Foundation Agentic AI Foundation since December 2025) has been missing in practice. Google’s gateway is vendor-specific, but the pattern (mesh-style enforcement for agent tool calls) is generic and will reappear across the other platform stacks — Bedrock AgentCore and Azure AI Foundry have comparable building blocks already in preparation.
Second, the Managed Agents API and Antigravity 2.0 signal a convergence: develop locally, deploy to a managed runtime on a shared protocol layer. This mirrors the container-mesh playbook of the early 2020s — this time not for workloads, but for autonomously acting software. Anyone staying on the code-first path keeps building with ADK 2.0; anyone needing low-code takes Agent Studio; both paths run over the same Identity, Gateway and Registry primitives. The stack unifies along the governance layer, not along the model.
Concrete recommendation
In this order. First, honestly inventory where your stack already contains agentic components — even simple LLM-driven tool calls count. Second, define minimum criteria for an agent governance layer (Identity, Gateway, Registry) vendor-neutrally — not as a Google decision, but as an acceptance threshold for every platform selection (Vertex AI, AWS Bedrock AgentCore, Azure AI Foundry, your own stack). Third, clarify third-country transfer, data residency and DPIA need with your data protection officer — this decision sits in front of the architecture decision, not behind it. The interesting question is not which hyperscaler delivers the prettier Agent Studio. It is whether your governance layer is described in such a way that you could change vendors tomorrow without losing the audit trail.
This post reflects our technical and strategic assessment. It does not replace legal advice or a data protection impact assessment.
Sources
- Google Cloud Blog — Introducing Gemini Enterprise Agent Platform (19 May 2026)
- Google Blog — Gemini Enterprise Agent Platform lets you build, govern and optimize your agents (19 May 2026)
- Google Blog — Introducing Managed Agents in the Gemini API (19 May 2026)
- Google Cloud Blog — I/O '26 news for agent developers on Google Cloud (19 May 2026)
About the author
Kim Hartwig
Kim is responsible for day-to-day operations and provides strategic support to our clients on a daily basis. Her expertise in computational linguistics combines an understanding of communication with technical know-how.