AI agents are getting easier to build. Managing them is getting harder.
A year ago the hard part was making an autonomous system plan, call tools, and finish a task. That problem is mostly solved. The hard part now is that organizations are no longer running one agent. They are running a growing estate of agents, tools, MCP servers, identities, and runtimes spread across teams — and they have lost track of which ones exist, what they can touch, and who is accountable for them.
The emerging AI agent infrastructure stack is the market formalizing an answer to that problem, layer by layer. Google Cloud’s Agent Registry is one of the most concrete pieces of it yet: a vendor primitive that treats a fleet of agents as something to be inventoried and governed, not just deployed.
What Google Cloud Agent Registry does
Google describes Agent Registry as “a centralized catalog that lets you store, discover, and govern Model Context Protocol (MCP) servers, tools, and AI agents within Google Cloud.” It sits inside the Gemini Enterprise Agent Platform — formerly Vertex AI — which Google positions as a place to “build, scale, govern and optimize agents,” a one-stop shop for an organization’s autonomous agents.
The platform is organized into four pillars: Build, Scale, Govern, and Optimize. Agent Registry is the Govern pillar, alongside Agent Identity and Agent Gateway, and the docs call it “the governance pillar and unified inventory of your agents, servers, and endpoints.” Around it, Google has expanded managed connectivity: more than 50 Google-managed MCP servers are now generally available or in preview, giving agents a standardized way to reach external tools, data, and Google Cloud services.
Read plainly, the product solves a real and growing operational problem. As an agent estate scales, you need to answer:
- Which agents, tools, and MCP servers exist?
- Who owns each one, and which are approved?
- Who or what is authorized to discover and call them?
- Which runtimes are connected, and how is the fleet monitored?
Once agents can take actions, agent discovery stops being a convenience feature and becomes a governance concern. A registry is the right tool for that concern. None of what follows is a criticism of the product. It is an observation about the boundary of what a registry, by its nature, can do.
A registry governs the actor
Everything a registry does is organized around the agent as an identity. It assigns an agent an owner, a version, a set of scoped permissions, and an authorization to run. It records who called what. It lets an admin revoke an agent, gate access to a tool, or block an unapproved MCP server. This is identity and authorization governance, and it is genuinely valuable: it shrinks the attack surface, kills shadow agents, and gives a security team a place to stand.
But notice the shape of every one of those controls. They all evaluate the actor, and they all evaluate it at the gate — before the agent runs. Is this agent approved? Is it scoped correctly? Is it allowed to call this tool? Pass the gate and the agent goes to work. The registry’s job is finished the moment execution begins.
A registry answers one question: is this agent allowed to operate? That is a question about the actor, decided before the work happens. It is necessary. It is also only half of the problem.
The diff it cannot see
Here is the failure a perfectly configured registry waves straight through.
An agent is registered. It is owned, versioned, scoped to exactly the right repositories, and fully authorized to commit code. It does its job. In doing its job, it adds a dependency an architectural decision record prohibits, routes around an approved service boundary, or re-implements a pattern the team had already standardized somewhere else in the codebase.
The registry’s verdict: approved actor, valid action, green. Every control fired correctly. The agent was who it claimed to be, it was allowed to do what it did, and the audit log faithfully recorded all of it. The architecture’s verdict: violated.
This is the failure mode that does not look like a failure. The code compiles. The tests pass. The pull request is authored by a trusted, registered agent. Nothing in the identity layer is built to notice that a syntactically valid, fully authorized change just contradicted a decision the team made on purpose. Multiply it across a fleet — Google itself frames this as fleets of agents — and two registered agents can implement conflicting patterns in parallel, each one approved, each one green, the system drifting off its own design one locally-reasonable commit at a time.
Operational trust is not architectural alignment. Certify that every agent in the fleet is approved, scoped, and audited, and the architecture is still completely unprotected — because nothing in the registry reads the repository’s constraints or returns a verdict on the change.
Two orthogonal axes, not a ladder
The tempting way to read this is as a maturity curve: registries today, deeper governance later. That framing is wrong, and it is wrong in a way that costs you. Registry governance and architectural governance are not two points on one line. They are two different axes.
One axis is about identity and authorization: which agent, owned by whom, allowed to run. It draws a perimeter around the actor, at gate time, before execution. The other axis is about intent and conformance: what the diff actually did, and whether it still matches the system the team designed. It returns a verdict on the artifact, at evaluation time, on the change itself. A registry can be fully mature on the first axis and the second axis is still at zero.
Same agent, two independent verdicts: allowed to run, and allowed to land
This is the same distinction two markets of agent governance draws between runtime and architectural governance, and the same one the agent manager as a control plane draws between supervising agents and enforcing on their output. A registry is the cleanest example yet of the pattern: it is an excellent control plane for the fleet and a non-control for the codebase.
Why the constraints live in the repo, not the registry
If a registry cannot see the diff, the obvious next thought is: then attach the architectural rules to the registry. Make the central catalog enforce them. This is the wrong move, and it is worth being precise about why.
A central registry is a chokepoint. An agent is authorized there once and then executes somewhere else — in an IDE, a CLI, a CI job, a local runtime, an endpoint. The governance perimeter is moving to the endpoint precisely because that is where the work actually happens, and a cloud catalog has no presence there. The one artifact every one of those execution surfaces reads is the repository. So that is where the constraints have to live.
What architectural governance requires is the team’s decisions compiled before generation into deterministic, machine-evaluable constraints that run at hooks and in CI and return the same verdict regardless of which registered agent produced the change. Not prose in a wiki an agent is supposed to honor. Not a human reviewer expected to catch an ADR violation buried in a green pull request. An evaluation on the artifact that propagates to every surface the fleet touches, and that can explain, through enforcement provenance, exactly which decision a change violated and where that decision came from.
Register the agent in the cloud; enforce the architecture in the repo. The registry governs the fleet. The repository is where the verdict on the work has to be rendered, because that is the one place every agent and every CI surface actually reads.
Both, not either
This is not an argument against agent registries. An enterprise running a fleet of autonomous agents needs to know which agents exist, who owns them, and which are allowed to run — and Google Cloud Agent Registry is a serious answer to that need. Filing it under a “Govern” pillar is honest: it is real governance of the fleet as a set of actors.
It is simply governance on one axis. The other axis — whether the code, configs, and migrations the fleet generates still hold the line on the architecture they touch — is not something a registry was ever built to cover, and it does not arrive later as the registry matures. It is a different layer, running in a different place, answering a different question. Adopt the registry and your fleet is accountable. Add architectural governance and the systems that fleet is rewriting stay yours.
A registry tells you the agent was allowed to act. It cannot tell you the system still matches what you decided after it did. Knowing which agents are authorized is the first half of agent fleet governance. The verdict on what they changed is the half that protects the architecture.