Agent registry

An agent registry is a system of record that lists every AI agent an organization runs, along with its owner, purpose, model, tools, permissions and current status. It answers two questions that get surprisingly hard once more than a handful of agents exist. Which agents do we have, and what can each one do?

Registries usually show up as a response to agent sprawl. Agents get built by platform teams, by business units on low-code tools and inside third-party software. Without a central record, security can't scope an incident, compliance can't show which agents touch regulated data, and developers rebuild agents that already exist.

What an agent registry records

Each entry starts with identity and ownership. That means a unique ID for the agent, separate from any human account, plus a named owner and team. Ownership changes need tracking too, because an agent whose sponsor has left the company is effectively unowned.

Next comes reach. The registry lists the tools, APIs and data sources the agent can use, based on what it's authorized to do rather than what it claims it can do. It also records configuration, such as the model and version, where the agent runs and the policies bound to it.

Last is lifecycle status, the agent's current state, such as pending approval, active, suspended or retired. Each change should carry a timestamp and the name of whoever made it.

Cloud providers now ship this as a product. Google Cloud's Agent Registry documentation describes a central catalog for storing, finding and governing agents, tools and MCP servers across projects.

How a registry supports governance

A registry only helps governance if it sits in the path of deployment, not off to the side. Registration shouldn't equal activation. An agent can be recorded, reviewed and approved before it becomes live, which turns the registry into the checkpoint where ownership and permissions get checked.

It also makes lifecycle problems easy to see. Zombie agents, whose credentials stay live after their job has ended, stand out when every agent has a status. So do permissions granted at setup and never revisited. Both are nearly impossible to find when the only inventory is a pile of API keys in different places.

Some registry tools also try to find shadow AI, meaning agents nobody formally approved. Pulling them into the record means the registry covers the agents that actually exist, including the ones that skipped review.

Agent registries for discovery

The term has a second meaning in multi-agent systems. There, a registry is a directory that lets one agent find another and learn how to call it. In the A2A protocol, each agent publishes an Agent Card, a JSON file that works like a machine-readable business card, listing its skills, endpoint and the authentication it requires.

The A2A guide to agent discovery describes a few ways to find those cards. A public agent can serve its card at a standard path, /.well-known/agent-card.json, on its own domain. Companies can also run curated registries that collect cards and let clients search by skill, tag or provider. The spec doesn't define a standard API for those registries yet, so implementations vary.

The two meanings are starting to merge, with one catalog serving both. They still do different jobs. A discovery registry tells agents how to reach each other. A governance registry tells people who's accountable and what's permitted.

Common gaps in agent registries

A registry is only as accurate as what goes into it. If registration is manual, the record drifts as teams add tools, swap models or widen permissions without updating it. Entries generated from deployment pipelines and identity systems stay current far more reliably.

Self-description is another limit. An Agent Card states what an agent says it does. It doesn't prove the agent behaves that way, and a misconfigured or malicious agent can publish a card that looks fine. Trust decisions need verified identity and observed behavior, on top of declared skills.

Coverage is the last gap. Agents built into vendor software may share little or no metadata, leaving holes the registry can flag but not fill.

What an agent registry means for customer service

Support teams tend to add agents one use case at a time: refunds, then order changes, then billing questions. A registry keeps that growing set explainable. When a security lead or auditor asks which agents can issue refunds or read payment data, the answer should come from a query, not a week of interviews.

The registry is also the reference data for broader AI agent governance. Identity systems issue credentials to the agents it lists, and policy engines look up an agent's rules before allowing an action. When an agent needs to be paused or retired, the registry is where that change should start.

For a deeper dive, download Decagon's guide to agentic AI for customer experience.