AWS Agent Registry Launches to Tame AI Agent Sprawl, But Only Within AWS

AWS introduced Agent Registry in preview this week, a managed service inside Amazon Bedrock designed to catalog and govern enterprise AI agent fleets across five regions: US West (Oregon), US East (N. Virginia), Europe (Ireland), Asia Pacific (Tokyo), and Asia Pacific (Sydney). The service provides a unified directory capturing metadata on agent capabilities, identities, integrations, and compliance status. But there's a catch that undermines the entire premise: Agent Registry operates exclusively within AWS infrastructure, meaning enterprises running agents across Google Cloud or Azure will need separate registries from each vendor. The solution to agent sprawl may be registry sprawl.

"Agent Sprawl is an emerging structural problem," says Gaurav Dewan, Research Director at Avasant. "What we see consistently across enterprises is that agents proliferate much faster than traditional applications because they are easier to build. As a result, ownership becomes ambiguous as they move into production while increasing costs, risks, and duplication until finance, security, or related incidents force attention." AWS's answer is a centralized catalog, but only if you're willing to consolidate your entire agent infrastructure inside one hyperscaler's ecosystem.

What Changed

AWS launched Agent Registry as part of its Amazon Bedrock AgentCore portfolio, positioning it as the control layer for enterprises grappling with unmanageable AI agent growth. The service is now in preview across five regions, offering a structured directory where teams can register agents regardless of the underlying model or framework. Unlike traditional application registries, Agent Registry is model-agnostic, meaning it can catalog agents built with OpenAI, Anthropic, Cohere, or proprietary models, as long as they operate within AWS boundaries.

The registry captures structured metadata including ownership details, compliance status, cost center assignments, and custom taxonomies defined by the enterprise. According to AWS, organizations "will be able to define categories and taxonomies that match how your organization thinks about agents, backed by structured metadata schemas capturing ownership, compliance status, cost center, and whatever else your governance model requires."

Access points include the AgentCore console, REST APIs, SDKs, and a Model Context Protocol (MCP) server for programmatic integration. The service supports both manual registration, where teams explicitly catalog agents via console or API, and automated ingestion through MCP or Agent2Agent (A2A) endpoints (protocols that let agents communicate directly with each other) that detect and register agents as they interact with external systems. Authentication relies on OAuth-based mechanisms, and the registry tracks agent interactions while remaining anchored to AWS infrastructure.

How It Works

Agent Registry provides two registration pathways. Manual registration requires teams to submit structured metadata via the AgentCore console, APIs, or SDKs, explicitly defining each agent's capabilities, owner, compliance requirements, and integrations. This approach gives granular control but scales poorly for enterprises managing hundreds of agents. Automated ingestion, by contrast, uses MCP or A2A endpoints to detect agents as they communicate with external services, registering them dynamically based on interaction patterns. This reduces administrative overhead but depends on agents exposing standardized communication protocols.

Once registered, agents appear in a unified directory accessible through multiple interfaces: the AgentCore console for human operators, REST APIs for programmatic access, SDKs for embedded governance workflows, and MCP servers for agent-to-agent discovery. Enterprises can define custom taxonomies, organizing agents by business function, compliance tier, or cost allocation. AWS's structured metadata schema supports fields like owner identity, deployment environment, model provider, and approval status, creating a governance layer that mirrors traditional IT asset management but tailored to the ephemeral, distributed nature of AI agents.

Registration Method	Mechanism	Use Case	Scalability
Manual	Console, APIs, SDKs with explicit metadata	Legacy agents, on-prem systems, external clouds	Low (admin-intensive)
Automated	MCP or A2A endpoint detection	AWS-native agents, high-velocity deployment	High (protocol-dependent)

The registry integrates tightly with AWS-native services, particularly in identity and runtime management. Authentication uses OAuth, and the service tracks agent interactions with external systems, though the registry itself never leaves AWS infrastructure. Enterprises can query the registry to identify redundant agents, flag compliance violations, or allocate costs to specific departments. Charlie Dai, Principal Analyst at Forrester, characterizes the approach as reinforcing Bedrock as "the control plane for enterprise AI agent deployment and oversight," positioning AWS as the orchestration layer even when agents consume third-party models.

Who Benefits

Enterprises facing the operational chaos Dewan describes, where agents proliferate faster than traditional applications, are the immediate beneficiaries. Finance teams struggling to allocate AI spending across departments gain visibility into which agents are consuming resources and who authorized them. Security teams can enforce compliance policies, flagging agents that access sensitive data without proper governance or tracking which agents interact with external APIs. IT operations teams, particularly those managing hybrid environments, get a centralized view of AWS-hosted agents, though visibility ends at the AWS boundary.

The governance layer matters most for regulated industries where audit trails and ownership transparency are non-negotiable. A pharmaceutical company deploying agents to analyze clinical trial data needs metadata proving which agent accessed which dataset, when, and under whose authority. Agent Registry provides that audit trail for agents running on AWS, capturing each interaction timestamp, data source identifier, and authorized user credential. For organizations already committed to Bedrock as their AI platform, the registry extends existing workflows rather than introducing new tooling. Teams accustomed to AWS IAM, CloudWatch, and Cost Explorer will recognize the governance model.

But the service's AWS-only scope limits its utility for enterprises pursuing multi-cloud or hybrid strategies. Dewan notes, "While the service will natively index and manage agents deployed within AWS environments, integration with external or on-prem agents will likely require manual registration. Cross-cloud or federated discovery capabilities are not yet clearly established." A company running agents on AWS for customer support, Google Cloud for data analytics, and Azure for developer tooling would need three separate registries, each with its own metadata schema and access controls. The promised solution to agent sprawl risks becoming registry sprawl, where governance tools fragment across hyperscalers.

The Competitive Picture

AWS is not alone in recognizing agent sprawl as a structural problem. Google Cloud is extending Vertex AI with agent orchestration and monitoring capabilities, while Microsoft positions Azure AI and Copilot Studio as a unified platform for building and governing enterprise agents. All three hyperscalers are converging on registry-based governance, but none offer cross-cloud federation.

The competitive dynamic creates a lock-in decision disguised as a management tool. Enterprises committed to AWS Bedrock gain the tightest integration: Agent Registry natively indexes Bedrock agents, leverages AWS IAM for authentication, and ties into Cost Explorer for billing. But that integration vanishes the moment an agent runs elsewhere. Dewan's observation about manual registration for external agents highlights the friction: every on-premises agent, every Azure-hosted workflow, every Google Cloud function requires explicit cataloging, negating the automation benefits that make registries appealing in the first place.

AWS has signaled that external registry support is planned, enabling multi-registry search capabilities where Agent Registry could query Google's or Microsoft's catalogs. But no timeline exists, and the technical challenges are significant. Federated discovery requires standardized metadata schemas, cross-cloud authentication, and agreed-upon protocols for agent identity, none of which currently exist. Until that infrastructure materializes, enterprises face a binary choice: consolidate agent deployments within a single hyperscaler to gain governance, or accept fragmented visibility across multiple clouds.

What's Next

AWS's roadmap includes external registry support, allowing Agent Registry to search and catalog agents registered in third-party systems. That capability would address the multi-cloud dilemma, enabling enterprises to maintain a federated view of agents regardless of where they run. But implementation depends on industry-wide agreement on metadata standards, authentication protocols, and cross-cloud communication frameworks. No such standards exist today, and the competitive dynamics among AWS, Google, and Microsoft make collaboration unlikely.

In the near term, enterprises will evaluate Agent Registry based on their existing AWS footprint. Organizations deeply embedded in Bedrock will adopt it as a natural extension of their governance stack. Teams running multi-cloud or hybrid environments will either manually register external agents, accepting the administrative overhead, or maintain separate registries per cloud provider, accepting the fragmentation. Neither option solves the root problem: agents proliferate across environments faster than governance tools can adapt.

The broader question is whether registry-based governance is the right model for AI agents at all. Traditional application registries work because applications are relatively static, with well-defined boundaries and stable ownership. Agents are ephemeral, composable, and often autonomously spawned by other agents. A registry that requires manual or protocol-dependent registration may be too rigid for the dynamic, distributed nature of agentic systems. AWS's bet is that enterprises will demand control even at the cost of agility, prioritizing audit trails and compliance over agent autonomy. Whether that trade-off holds depends on how painful agent sprawl becomes relative to the friction of multi-cloud governance.

Agent Registry is available now in preview across five AWS regions. Pricing and general availability timelines have not been disclosed.

The irony is sharp: enterprises adopting Agent Registry to tame agent sprawl may find themselves managing registry sprawl instead, juggling AWS, Google, and Microsoft catalogs that don't talk to each other. The tool that promises unified governance fragments the moment your infrastructure crosses cloud boundaries. AWS is betting you'll consolidate rather than coordinate. Whether that's pragmatism or lock-in depends on how much of your AI stack you're willing to hand over.

-- Aria Lin, Enterprise Technology Analyst

Sources: AWS