Agent Registry

A governed, queryable catalog of every agent in the organization, recording what each one does, who owns it, what it touches, and when it was last reviewed, so that everything else governance wants to do has something concrete to bind to.

Understand This First

• Shadow Agent — the upstream antipattern an Agent Registry corrects.
• Agent Sprawl — the population-scale antipattern an Agent Registry bounds.
• Bounded Autonomy — the policy layer that operates over registry entries once they exist.

Context

A team is past its first agents. The PR triage bot ships, the on-call noise filter ships, the deployment helper ships, the data-pipeline cleanup agent ships. Six months in, more product teams have built their own. Some agents are blessed by platform engineering. Many were spun up by individual engineers who needed something fast and used the tools their laptops already had.

This is the moment when “we run a few agents” turns into “we run more agents than anyone can name from memory.” The org chart, the credential vault, and the security-review queue weren’t designed for this category of resident. The question has shifted from can we run agents? to how do we keep track of them?, and the organization doesn’t yet have the record system that question demands.

This pattern is operational. It applies once an organization has more than a handful of agents in production, or expects to within a quarter. Below that scale, a shared spreadsheet is enough. Above it, the spreadsheet rots and the population starts hiding from itself.

Problem

Without a system of record, governance cannot answer the basic questions. How many agents do we run? You get ranges, not numbers. Who owns this one? The engineer who left two months ago. What does it have access to? Whatever credentials it was handed, possibly forever. Has it been reviewed? Nobody knows. Did the team down the hall already build the same thing? Probably, but you find out when both break the same way at the same time.

All of those gaps share one upstream cause: the inventory doesn’t exist. Every governance pattern in this section assumes the agents are known. When they aren’t, none of those patterns apply, and nobody sees the gap until an incident drags it into view.

Forces

• Speed of creation versus speed of governance. Spinning up an agent takes minutes. Standing up the platform that governs it takes months. If the registry is slower than the shadow path, the shadow path wins.
• Visibility versus enforcement. Teams won’t disclose what they think will be punished. But policies that don’t bind to a known target enforce nothing. The order matters: discovery first, enforcement second.
• Lightweight versus complete. A short intake form gets adoption. A 14-field intake form with a two-week SLA gets bypassed. The registry has to know enough to govern, but not so much that registering becomes the obstacle.
• Local convenience versus organizational view. Each team would rather track its own agents in its own way. Each auditor needs one consolidated answer. The registry resolves that tension by being a single source of truth, even when teams maintain local detail.
• Static record versus living system. A registry that nobody updates rots faster than humans expect. Last-review dates, ownership transfers, and decommissioning all need a regular cadence, or the entries lie.

Solution

Build a queryable catalog of every agent before you build the policies that act on it. Start the registry with a short, opinionated metadata schema, sometimes called an agent card, and require an entry before an agent can run in production. Pair the launch with an amnesty window so existing agents come into the inventory without penalty. Then layer governance on top, in this order: bounded autonomy, least privilege, approval policy, observability.

Every entry captures, at minimum:

• Name and version. What this agent is and which build is running.
• Owner. A specific human accountable, not a team mailing list. Ownership transfers explicitly.
• Description and declared capabilities. What the agent does and what it can take action on.
• Endpoint or invocation surface. Where it lives and how callers reach it.
• Credentials and data scope. What it touches, scoped down with Least Privilege.
• Supported protocols. MCP, A2A, or others, so other agents and tools know how to talk to it.
• Trust credentials. Verifiable identity that ties the runtime back to the entry.
• Last review date. A live field, not a launch field.

The registry combines four operational moves. Inventory is the floor: every agent must appear before it runs in production. Discovery before access is how the registry pays for itself. New consumers find agents through the registry rather than Slack threads, and the registry can gate discoverability with collections or zero-trust policies, so unauthorized agents are not just blocked but invisible. Approval workflow plugs into the organization’s existing governance process; submission is fast (the shadow path wins on latency, not on quality), but production-discoverability requires a sign-off. Audit trail records every read, every write, every approval, so the registry is also the evidence base when an auditor asks what changed.

The discipline is sequencing. The cross-cutting rule is registry first, policy second. A policy with no registry to bind to enforces nothing. A registry with no policy is still useful, because at minimum the team can count its agents, find the one it needs, and name an owner. So count first.

How It Plays Out

An engineering manager at a startup runs an agent audit after reading about Shadow Agent. She expects to find half a dozen. She finds twenty-seven, most built by one engineer who learned that Claude Code could automate his Jira triage, on-call noise filtering, PR reviews, and weekly reports. The audit is the founding entry list for the new registry. The first registered agent is the engineer’s own one-person fleet, brought in under amnesty rather than punished, and the engineer becomes the registry’s first power user. Within a quarter, the registry holds forty entries, two of them flagged for decommissioning because nobody now needs them. The fleet shrinks for the first time in two years.

A larger enterprise standardizes on a cloud-vendor agent registry. AWS, Microsoft, and Google all shipped products in this category in 2026, each with the same shape: an agent card schema, identity-bound entries, a discovery layer, and a governance hook. Every team registers its agents through approval workflows. The registry becomes queryable from IDE clients, so a developer asking “is there an agent that already does X?” gets the answer in seconds. The deployment-time question shifts from “how do I build this agent?” to “is there one I should use?” Duplication, which previously took an incident to expose, now shows up in search.

A platform team at another company tries to do this carefully and fails for an instructive reason. They build a heavyweight registry with a 14-field intake form, a two-week approval SLA, and a separate ticketing system. The intent is good. The result is that the shadow path is still faster, so teams keep building agents outside the registry. Three months later, the registry has 12 entries and the API gateway shows traffic from 90 unrecognized consumers. The team rebuilds the registry around a five-field intake form and same-day approval for routine cases. The next sprint, registered entries cross 70. The lesson is structural: a registry that is slower than the shadow path doesn’t fail because of bad policy. It fails because of bad latency.

Consequences

Wins. Governance becomes enforceable once the inventory exists. The agent the team down the hall built shows up in search, so duplication stops being invisible. Ownership survives staff turnover because the entry carries a name that updates when people change roles. Downstream patterns gain a stable target: Bounded Autonomy, Least Privilege, Approval Policy, and Observability all bind to registry entries instead of guessing at the population. Agent-to-agent discovery becomes a query against the registry instead of hardcoded URLs. Security audits stop relying on engineer memory.

Costs. Every agent now has a registration tail, and the team has to treat that tail as part of shipping rather than as paperwork. The registry itself is platform work that lags product work by design. That lag is the structural reason Agent Sprawl exists in the first place, and standing up a registry doesn’t make it go away. Integration with identity (cloud IAM roles, OAuth subject-actor binding, verifiable credentials) is real work, not a checkbox. Entries go stale faster than humans expect, so review cadence has to be on the calendar.

Failure modes to name.

• Registry as bureaucratic ordeal. Heavyweight intake, slow approvals, parallel ticketing. The shadow path beats it on latency and the registry rots. The fix is operational, not philosophical: shorten the form, automate the approval for routine cases, integrate with the tools teams already use.
• Registry as audit theater. Entries exist, nobody reads them, nothing is enforced. The registry passes inspections but does no work. The fix is the discovery layer: make the registry the only way developers find agents, and entries get pressure-tested by use.
• Registry without identity. Entries can’t bind to actual agent runtime, so policies have no target. The fix is verifiable credentials: every registered agent gets an identity, the runtime presents it, and policy decisions have something to check against.
• Registry-vs-policy inversion. Building enforcement before the inventory. Without a registry, the policy has nothing to enforce against, and the population it tries to govern is partial.

Related Patterns

Sources

The agent-registry concept emerged simultaneously across the major cloud providers in the first half of 2026. AWS introduced its Agent Registry as part of Amazon Bedrock AgentCore, framing it as centralized discovery and governance over “agents, tools, skills, MCP servers, and custom resources.” Microsoft’s Entra Agent Registry took the identity-bound view, defining the agent card metadata schema, agent collections, and zero-trust discovery. Google Cloud’s Gemini Enterprise Agent Platform shipped a registry component as part of the same wave. The shared shape across vendors is what gave the term standing as a category rather than a product feature.

Independent press analysis sharpened the diagnosis the registry exists to fix. InfoQ’s coverage of the AWS launch summarized the problem in one sentence: “nobody knows what exists, who owns it, whether it’s approved, or whether the team down the hall already built the same thing.” That sentence is the registry’s working brief.

Vendor-neutral writing on the pattern also matured during the same period. TrueFoundry’s “What is AI Agent Registry” describes the registry as “a phone book or AI agent discovery platform for autonomous agents,” and walks through the agent card schema in a form that maps onto every vendor implementation. The deeper governance framing appeared in The New Stack’s 2026 work: registries as one of the categories of hidden infrastructure debt that organizations accrue when they deploy agents without the supporting platform. That framing was first cited in this book in Organizational Debt and is the bridge between the agent-registry pattern and the organizational-debt concept.

The discovery and identity primitives the registry rests on come from outside the agent context. The IETF’s draft Agent Name Service supplies the discovery-layer naming, and W3C Verifiable Credentials supply the trust primitive that registry entries reference when policies have to bind to a real, presentable identity. The book’s treatment of those primitives lives in the security-and-trust patterns the registry depends on.

Further Reading

• AWS, “AWS Agent Registry for centralized agent discovery and governance is now available in Preview” — the canonical product announcement, useful for the agent-card schema and the discovery-layer view.
• Microsoft Learn, “What is the Microsoft Entra Agent Registry?” — the cross-ecosystem registry, identity-bound, with detailed agent card and agent collections sections.
• TrueFoundry, “What is AI Agent Registry — A Complete Guide” — vendor-neutral introduction to the agent card schema and registry capabilities.
• InfoQ, “AWS Launches Agent Registry in Preview to Govern AI Agent Sprawl across Enterprises” — independent press analysis that frames the registry as the response to sprawl.