AWS Just Launched an Agent Registry: What Engineers Need to Know About Governing AI Agents at Scale

This Is a Governance Story, Not a Product Launch Story

On April 9, 2026, AWS released Agent Registry in preview through Amazon Bedrock AgentCore. The announcement is technically understated for what it actually represents. This is not a new way to build agents. It is a control plane for the agent landscape that enterprises have already built, and are building faster than any governance mechanism has been able to keep pace with.

The parallel to earlier infrastructure categories is worth drawing early. Container orchestration, service meshes, and API gateways all went through the same arc: initial adoption was rapid and chaotic, then control-plane products emerged, and governance tooling became a prerequisite for enterprise adoption at scale. Data governance followed the same pattern a decade earlier. Agent registries are on that same trajectory, and AWS is treating them accordingly.

Engineers, engineering managers, and platform teams who are already managing agent infrastructure need to understand what this system does, how the governance model works, and where it fits in the broader AgentCore stack before they evaluate it for their own environments.

Why AWS Agent Registry Matters Now

Enterprise AI teams have a sprawl problem. Over the past 18 months, organizations have moved from running one or two AI agents to managing dozens, sometimes hundreds, across business functions, teams, and cloud environments. Each team that builds a new agent typically has no visibility into what neighboring teams have already shipped. The result is predictable: duplicated capabilities, inconsistent ownership metadata, no shared approval standard, and a growing body of deployed agents that nobody has a complete picture of.

AWS frames the core problem as three compounding challenges: visibility, meaning knowing what agents exist across the organization; control, meaning governing who can publish and what becomes discoverable; and reuse, meaning preventing teams from rebuilding capabilities that already exist elsewhere.

The downstream consequences of ignoring those three problems are real. A security team cannot audit what it cannot see. A compliance function cannot enforce standards against agents it does not know about. A developer who cannot find an existing billing agent will build another one. As AI agent orchestration patterns mature, the need for a canonical registry of what is running, who owns it, and what it is authorized to do becomes more urgent, not less.

AWS also notes that no organization’s agent landscape lives entirely within one provider, and a registry that only covers part of the stack leaves the rest invisible. Invisible agents cannot be discovered, governed, or reused. That observation shaped the design of what they actually built.

What AWS Actually Launched

AWS Agent Registry is a fully managed, centralized catalog inside Amazon Bedrock AgentCore. It stores structured metadata records for every agent, tool, MCP server, agent skill, and custom resource an organization registers. Each record captures who published the entry, what protocols it implements, what capabilities it exposes, and how to invoke it.

The registry can be accessed via the AgentCore Console, AWS CLI, AWS SDK, or as an MCP server that builders can query and invoke directly from their IDEs. It supports both IAM and OAuth via custom JWT for access control.

There are two ways to get resources into the registry. The first is manual: provide metadata through the console or API, specifying capability descriptions, ownership information, compliance status, and usage documentation. The second is URL-based discovery, where teams point to a live MCP or A2A endpoint and the registry automatically retrieves the metadata, including tool schemas and capability descriptions, without manual entry.

Core Capabilities Engineers Should Understand

Several of the registry’s technical features deserve more than a surface-level read because the design decisions behind them have architectural implications.

Hybrid Semantic and Keyword Search

This is the discovery mechanism, and it is meaningfully better than tag-based or exact-match approaches. All queries use keyword matching, but longer natural language queries also use semantic understanding to surface conceptually related results. A search for “payment processing” surfaces tools tagged as “billing” or “invoicing” even if they are named differently. As the number of registered resources grows into the hundreds, this distinction between exact-match and semantic search becomes significant for whether the registry is actually usable in practice.

Approval Workflow with Full Lifecycle Tracking

Records move through a defined set of states: draft, pending approval, approved, rejected, and deprecated. Admins use IAM policies to define who can register resources and who can discover them. Every record must pass through the approval workflow before becoming discoverable organization-wide, and records are versioned to track changes over time. This lifecycle model transforms agent management from an informal practice into a repeatable, auditable process.

Multiple Resource Types in a Single Catalog

The registry handles agents, tools, skills, MCP servers, and custom resource definitions under one roof. Custom schemas let teams extend the metadata structure to match their own governance requirements, capturing fields like team ownership, cost center, deployment environment, or compliance certification status.

MCP-Native Access from IDEs

Any MCP-compatible client can query the registry directly, including IDEs such as Kiro and Claude Code. Developers can search the registry without leaving their development environment. The registry is not only a store for information about agents; it is itself part of the agent toolchain.

IAM and OAuth Authorization

Teams with custom identity providers can use OAuth-based access with custom JWT to build their own discovery interfaces without requiring IAM credentials. This matters for large enterprises where not every system will be operating inside AWS IAM natively.

CloudTrail Audit Logging

All registry access and administrative actions are logged through AWS CloudTrail. For regulated industries, this is not optional infrastructure; it is a compliance requirement, and having it built in rather than retrofitted reduces the integration burden considerably.

How the Governance Workflow Works

The approval workflow is the operational heart of the registry. Understanding it is important for platform engineers who will be designing the governance model for their organization.

An administrator creates a registry and uses IAM policies to configure who can publish records and who can discover them. Publishers submit records, which begin as drafts. A curator, typically someone in a platform or architecture role, reviews pending submissions and either approves or rejects them. Only approved records become visible in organization-wide search. The registry also provides integration hooks for existing approval workflows, so organizations that already have an approval process for software deployments can connect the agent registry into that same process.

The lifecycle does not stop at approval. Records can be deprecated when agents are retired or replaced. Versioning tracks changes to records over time. Deprecated records are not deleted; they remain auditable but are excluded from discovery, maintaining historical traceability while keeping the active catalog clean.

For organizations subject to regulatory requirements around AI systems, this combination of structured approval, versioning, deprecation, and audit logging transforms what was previously tribal knowledge into documented, auditable governance. It is the same discipline that enterprise data governance frameworks brought to data assets, now applied to the agent layer.

Why MCP Is Central to This Story

The Model Context Protocol is not incidental to this launch. It is structurally embedded in how the registry works, and that changes how you should think about what AWS has actually built.

Most organizations encountering the registry will first think of it as a place to register MCP servers alongside agents and other resources. That is true, but only half the picture. AWS has also exposed the registry itself as an MCP endpoint. Any MCP-compatible client can query and invoke the registry directly, including IDEs such as Kiro and Claude Code. This means the registry is not just an admin console that happens to catalog MCP servers; it is a first-class participant in the MCP ecosystem that developers interact with directly from their toolchain.

“The registry is not only a place to store information about agents. It is itself part of the agent toolchain.”

The practical effect is that discovery becomes part of the development workflow rather than a separate administrative step. A developer in an IDE can query the registry, find an existing agent or tool, and invoke it without switching context. The registry becomes the mechanism by which reuse actually happens in practice, not just in principle.

AWS also supports the Agent-to-Agent (A2A) protocol natively alongside MCP, signaling an intent toward protocol-based interoperability rather than AWS-proprietary integration patterns. For enterprises that need their agent infrastructure to work across vendors, frameworks, and deployment environments, that orientation matters. Understanding how agent orchestration patterns interact with standardized protocols like MCP is becoming a practical engineering skill as these systems enter production.

AWS’s Provider-Agnostic Design

The registry indexes agents regardless of where they are built or hosted: AWS, other cloud providers, or on-premises. Your registry can reflect your full agent landscape from day one, not only the pieces that happen to run on AWS.

This is a deliberate architectural choice worth taking seriously rather than reading as marketing. Real enterprise environments are almost never single-cloud or single-framework. A team using LangChain on Azure, another using Bedrock Agents, and a third running on-premises inference infrastructure are all part of the same organization’s agent landscape. A registry that only surfaces AWS-native agents provides an incomplete picture and therefore incomplete governance.

By supporting manual registration and URL-based endpoint discovery for any MCP or A2A-compatible resource, AWS makes it possible to catalog the full landscape. Whether organizations will actually register their non-AWS agents is an organizational question, not a technical one, but the capability to do so is present from day one.

Where Agent Registry Fits in the Broader AgentCore Stack

Agent Registry is one component in a larger platform that AWS has been assembling under the AgentCore umbrella. Seeing how the pieces connect clarifies why the registry matters as infrastructure rather than as a standalone tool.

Taken together, these components form a platform for enterprise agent operations: build with the runtime, expose through the gateway, authenticate with identity, catalog in the registry, and audit with CloudTrail. The registry is one layer in that stack, but it is the layer that provides visibility across the others. For engineering managers and tech leads making the case for agent governance investment, this stack architecture is the framing that connects individual components to a coherent platform strategy.

What This Means for Platform Engineers and AI Teams

The operational implications are concrete for teams already managing agent infrastructure or planning to scale it.

Discover before you build. The registry creates a default workflow: search first, build only if nothing exists. Zuora, an AI-first monetization platform deploying 50 agents across Sales, Finance, Product, and Developer teams, uses the registry to give principal architects a unified view to discover, manage, and catalog every agent, tool, and skill in use. The key outcome is that teams find and reuse existing assets rather than rebuilding from scratch. That pattern does not emerge on its own; it requires a registry that is actually populated, searchable, and trusted.

Standardize ownership metadata from day one. The registry enforces the inclusion of ownership metadata as part of record creation. When an agent misbehaves in production, knowing immediately who owns it, what compliance status it carries, and what version is deployed can reduce incident response time from hours to minutes.

Version and deprecate deliberately. The lifecycle model with versioning and deprecation gives platform teams the mechanisms to manage agent turnover without leaving ghost entries in the catalog. Deprecated records are excluded from discovery but remain auditable, maintaining historical traceability while keeping the active catalog clean.

Integrate with existing governance workflows. Southwest Airlines is deploying the registry for enterprise-wide agent governance across multiple platforms. According to Justin Bundick, VP AI and Intelligent Platforms at Southwest Airlines, the registry solves the critical discoverability challenge while enabling managed governance with standardized ownership metadata and policy enforcement across the organization’s entire agent estate.

Competitive Context: AWS Is Not Alone

AWS is not building agent governance infrastructure in isolation. Microsoft Azure and Google Cloud both have agent registry offerings in various stages of development. The fact that all three major cloud providers are now investing in control-plane products for AI agents signals that governance has become a competitive layer in enterprise AI platforms, not an optional feature.

The pattern is familiar from earlier infrastructure categories. Container orchestration, service meshes, and API gateways all went through the same arc: initial adoption was chaotic, control-plane products emerged, and governance tooling became a prerequisite for enterprise scale. Agent registries are following the same trajectory, and the speed of that trajectory is faster this time because the underlying agent adoption curve is steeper than anything that preceded it.

What distinguishes the AWS approach is the combination of provider-agnostic registration, MCP-native access, deep integration with existing AWS enterprise infrastructure including IAM, CloudTrail, and EventBridge, and native support for both MCP and A2A protocols. Whether that combination is more compelling than competing offerings will depend on where an organization’s existing infrastructure already lives.

Open Questions and What Comes Next

The preview announcement includes roadmap items that signal where AWS sees the category heading.

Automatic indexing at deployment. AWS is building toward indexing agents the moment they are deployed, which would eliminate the manual registration step entirely. Agents built through Amazon Quick and Kiro are explicitly named as future targets for automatic indexing.

Cross-registry federation. This would let organizations connect multiple registries and search across them as a single catalog, which matters for large enterprises with separate registries per business unit, environment, or subsidiary.

Custom taxonomies and structured metadata schemas. Organizations would be able to define the categories and metadata fields that match their own governance model rather than conforming to a predefined structure.

Operational telemetry integrated into records. AgentCore Observability will surface invocation counts, latency, uptime, and usage patterns alongside registry records, so that entries show not only what exists but whether it is actively working and how it is performing in production. This addition would transform the registry from a static catalog into a live operational dashboard for the agent estate.

External partner catalog connections. AWS has indicated early partner interest in connecting external agent catalogs, which would extend discovery beyond the organizational boundary to include third-party agent ecosystems.

Each of these roadmap items addresses a genuine gap in the current preview. The trajectory suggests AWS intends for the registry to become the canonical source of truth for enterprise agent operations, not just a catalog that complements the runtime. For engineers building the skills to work with systems like this, the MLOps engineering roadmap provides a useful frame for how operational disciplines evolve as AI systems mature in production.

Key Takeaways for Engineers

Agent governance is moving from spreadsheets and tribal knowledge into dedicated platform services. That transition is now happening fast enough that “we manage agents informally” is starting to carry the same operational risk that “we manage deployments informally” carried before CI/CD infrastructure made structured release processes the default.

MCP interoperability is becoming a practical enterprise requirement. The fact that the registry itself is an MCP endpoint, queryable from IDEs, makes the protocol part of the everyday development workflow rather than an integration concern reserved for platform teams. Engineers who understand how MCP works at a technical level are better positioned to design and evaluate systems that depend on it.

The most important operational insight from this launch is the reordering of the build cycle: discover, then build. A registry is only useful if it actually changes behavior. If teams search the registry before starting new agent development and find existing capabilities they can reuse, the registry is working. If teams build first and register after the fact, the catalog stays incomplete and the sprawl problem persists.

For engineers and engineering managers working on or transitioning into agentic AI, understanding how to design, configure, and govern multi-agent systems at the platform level is becoming a core competency. IK’s Agentic AI for Software Engineers course covers the architectural patterns behind systems like this one, including how agent orchestration, identity, and governance layers fit together in production deployments. Engineering managers building the organizational case for these investments will find the Agentic AI for Engineering Managers course directly relevant to the governance and cost-justification questions this launch raises.

AWS Agent Registry: Quick Reference

Key Terms

Questions to Ask Before Registering an Agent in Production