AWS launched Agent Registry on April 9 as a preview feature inside its Bedrock AgentCore platform. The product is a centralized catalog where enterprises can discover, share, govern, and reuse AI agents, tools, MCP servers, and agent skills across their organizations. The critical design choice: it indexes agents regardless of where they were built or where they run, covering AWS services, other cloud providers, and on-premises environments.
The announcement targets a problem that has become operational rather than theoretical. As enterprises scale from pilot projects to hundreds or thousands of agents, platform teams lose visibility into what exists, who published it, and whether it duplicates work another team already shipped. According to AWS’s blog post, this creates three compounding failures: invisible agents can’t be governed, ungoverned agents can’t be audited, and unaudited agents running in production represent unquantified risk.
What Agent Registry Actually Does
The registry stores structured metadata for every agent, tool, MCP server, agent skill, and custom resource an organization registers. Each record captures who published it, what protocols it implements, what capabilities it exposes, and how to invoke it. Two registration paths are available: manual entry through the console, SDK, or API, or automatic ingestion by pointing the registry at an MCP or A2A endpoint and letting it pull in the details.
SiliconANGLE reported that the registry uses hybrid search combining keyword and semantic matching. A search for “payment processing” surfaces tools tagged as “billing” or “invoicing” even when names differ. The intent is to make discovery the default behavior before building: search first, build only if nothing vetted exists, then register what you built for the next team.
Governance operates through IAM policies that control who can register agents and who can discover them. Every record follows a lifecycle: draft, pending approval, discoverable. Records are versioned, can be deprecated, and carry custom metadata for ownership, compliance status, and deployment environment. The New Stack noted AWS’s framing: “agents shouldn’t be secret.”
The registry is accessible through the AgentCore Console, APIs, and as an MCP server. Any MCP-compatible client can query it directly, including Kiro and Claude Code. For organizations using custom identity providers, OAuth-based access allows teams to build their own discovery interfaces without IAM credentials.
Early Adopters and the Scale Problem
Two enterprise customers offered specifics. Zuora, which according to AWS runs 50 agents across Sales, Finance, Product, and Developer teams, described the registry as giving principal architects “a unified view to discover, manage, and catalog every agent, tool, and skill in use.” Southwest Airlines’ VP of AI and Intelligent Platforms, Justin Bundick, told SiliconANGLE the registry “will prevent agent sprawl across the organization while establishing the foundation for scaling thousands of agents with enterprise-grade governance from day one.”
These numbers are consistent with broader data. A Salesforce 2026 Connectivity Benchmark Report found the average enterprise now runs 12 AI agents, with 50% operating in isolated silos and no coordination between them. At 12 agents, a spreadsheet works. At 50 (Zuora) or “thousands” (Southwest’s stated goal), it doesn’t.
The Competitive Landscape: Seven Vendors, Seven Different Layers
AWS is not the first vendor to recognize that agent cataloging is infrastructure. As The AI Economy analysis detailed, at least seven major players are building overlapping but non-identical governance products:
Microsoft launched Agent 365 this week as a governance and lifecycle management platform for enterprise AI agents, with Reply as launch partner. Microsoft also ships Entra Agent ID, which treats agents as managed identities alongside human users in the directory. This gives Microsoft a two-layer approach: identity at the Entra level, governance at the Agent 365 level.
Google paired its Cloud API Registry with Vertex AI Agent Builder to create a curated catalog of approved tools and agents within the Google Cloud ecosystem.
ServiceNow announced on April 9 that its entire product portfolio is now “AI-enabled,” with a new Context Engine and Build Agent Skills capability. Multiple analysts describe ServiceNow as positioning itself as the “control plane for agentic business,” according to No Jitter, approaching the problem from workflow orchestration rather than infrastructure.
JFrog extended its software supply chain security platform to cover AI workloads with an AI Catalog that governs internal and third-party models, agent skills registries, and MCP servers.
Kong extended its existing API gateway governance to MCP servers and agent-to-agent communication.
Okta built Okta for AI Agents, tackling the problem from the identity and authentication layer.
Collibra applied its data governance framework to agent metadata, approaching the problem from data lineage and compliance.
The pattern is clear: each vendor is extending its existing domain expertise into agent governance. AWS extends cloud infrastructure management. Microsoft extends identity and enterprise productivity. ServiceNow extends workflow orchestration. JFrog extends software supply chain. Kong extends API management. Okta extends identity. Collibra extends data governance.
Why No Single Vendor Can Own This
A Gartner VP analyst, Sumit Agarwal, wrote in CIO Dive on April 8 that CIOs need six distinct technical capabilities embedded in their AI architecture: guardrails, observability, traceability, centralized AI gateways, AI catalogs, and AI wrappers. An AI catalog, Agarwal wrote, provides “a single registry of all AI models, agents, tools and use cases” with “metadata, documentation and ownership details.”
Agent Registry is squarely in the “AI catalog” bucket. But Agarwal’s taxonomy makes the competitive dynamics obvious: no single vendor covers all six layers. AWS Agent Registry handles cataloging and some governance, but it is not an identity system, not an observability platform, and not a guardrails engine. Microsoft covers identity and governance but doesn’t own the infrastructure layer for non-Azure agents. ServiceNow covers workflow and compliance but not cloud infrastructure.
The AI Economy concluded that “enterprises won’t be choosing among them so much as assembling several simultaneously.” This matches the historical pattern in cloud security, where organizations run separate products for identity management, network security, compliance monitoring, and incident response, each from a different vendor.
The Cloud-Agnostic Bet
The most strategically significant design choice in Agent Registry is cloud agnosticism. AWS is explicitly indexing agents built on competing platforms and in on-premises environments. This is unusual for AWS, which typically optimizes for depth within its own ecosystem rather than breadth across competitors.
The calculus is straightforward: if the registry only covers AWS-native agents, it fails at its stated purpose. No enterprise’s agent landscape lives entirely within one provider. A registry that indexes 60% of an organization’s agents and leaves the other 40% invisible creates a false sense of completeness that may be worse than having no registry at all.
AllToc framed it plainly: “The registry signals that AWS is treating agent management as infrastructure, not an ad hoc application feature.” The open interoperability framing, with native MCP and A2A protocol support, positions this as a standards-based layer rather than a proprietary lock-in play.
Whether that positioning holds depends on execution. AWS said it plans to expand the registry to automatically index any agent deployed through its own services, including Amazon Quick Suite and Kiro. Cross-registry federation, letting organizations connect multiple registries and search across them as one, is on the roadmap. Operational intelligence from AgentCore Observability will eventually surface alongside registry records: invocation counts, latency, uptime, and usage patterns.
The Boring Infrastructure Phase
Agent Registry launched in preview in five AWS regions: US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Tokyo), and Europe (Ireland).
The timing of this announcement alongside ServiceNow’s full-portfolio AI enablement and Microsoft’s Agent 365 launch points to a broader shift. Three major enterprise vendors shipped agent governance products on the same day. The race is not to build the smartest agent. It is to build the infrastructure that makes thousands of agents manageable. Registries, catalogs, lifecycle management, approval workflows: this is the plumbing phase that precedes mass enterprise adoption.
For platform teams evaluating these products, the practical question is not which registry to pick. It is which layers of the governance stack each vendor covers and how many products you need to assemble before you have full visibility into what your agents are doing. Based on the current market, the answer is at least three.