AWS Agent Registry Preview: Manage, Discover, and Govern AI Agents at Scale

The future of managing AI agents at scale: AWS Agent Registry now in preview

TL;DR
AWS Agent Registry (preview) inside AgentCore on Amazon Bedrock creates a centralized catalog for discovering, governing, and reusing AI agents across an enterprise.
It captures structured metadata, supports automatic ingestion via MCP (Model Communication Protocol) and A2A (Agent-to-Agent), and offers hybrid keyword + semantic search plus IAM/OAuth governance.
Early adopters (Zuora, Southwest Airlines) use it to prevent agent sprawl and speed reuse; tradeoffs include integration effort, metadata sensitivity, and potential subtle vendor lock‑in.
Platform teams should pilot with clear metadata schemas, add observability hooks, and measure reuse and reduction in duplicate work before broad rollout.

What is an “agent” — and why a registry matters

An AI agent is a software component that performs tasks autonomously—think an automated billing assistant, a sales outreach bot, or a code-generation helper embedded in developer tooling. As organizations deploy dozens or hundreds of these agents across Sales, Finance, Product, and Dev teams, three problems recur: invisible capabilities that show up as surprises during audits, poor governance with inconsistent policies, and repeated engineering effort rebuilding the same capability in multiple places.

A centralized Agent Registry treats agents as managed assets with clear ownership and policy controls. It’s the equivalent of an artifact repository for models and skills: searchable, versioned, discoverable, and tied back to identity and observability so teams can reuse vetted capabilities instead of reinventing them.

What AWS Agent Registry does

AWS’ Agent Registry (preview) is delivered inside AgentCore on Amazon Bedrock. It focuses on three platform pain points: visibility into deployed agents, governance over what’s discoverable and allowed, and reuse to eliminate duplicated work.

Structured metadata capture — publisher, protocols, exposed interfaces, invocation details, owner, compliance tags, documentation and custom schemas for domain-specific fields.
Standards-first ingestion — native support for MCP (Model Communication Protocol) and A2A (Agent-to-Agent), which let agents advertise capabilities and metadata so registries can index them automatically.
Flexible registration — manual via console/SDK/API or automatic via MCP/A2A endpoints.
Hybrid discovery — keyword filters plus semantic search to surface related capabilities (e.g., “payment processing” => “billing” or “invoicing”).
Governance & lifecycle — IAM-based publish/discover controls, OAuth support for external identity, approval workflows (draft → pending → approved), versioning and deprecation metadata.
Access patterns — reachable through the AgentCore Console, APIs, or exposed as an MCP server queryable by MCP-compatible clients (examples include Kiro and Anthropic’s Claude Code).

How it works (practical flow)

Basic data flow:

An agent exposes a metadata endpoint or is registered manually.
Agent Registry ingests structured metadata—either pushed or pulled via MCP/A2A.
Registry indexes records (keyword + semantic) and enforces publishing policies and approval workflows.
Teams discover agents through Console, API, or MCP-compatible clients; observability ties runtime metrics to registry records.

Minimal metadata schema (example)

name — human-friendly identifier
version — semantic version
owner/team — contact and org unit
interface_type — REST, gRPC, MCP, custom
invocation_endpoint — URL or connection string
protocols — MCP, A2A, other
compliance_tags — PCI, PII, GDPR, etc.
cost_center — billing mapping
docs — usage and runbook links
deprecation_date — optional

Observability: why telemetry matters for governance

Cataloging agents is only half the story. Rules and ownership must be tied to runtime behavior. AWS plans tighter integration between Agent Registry and AgentCore Observability so each registry record can surface metrics such as:

invocation count (per hour/day/week)
average latency and percentile latency (p50/p95/p99)
error rate and failure modes
top consumers (which teams or services are calling the agent)
cost per invocation and aggregated cost by cost center

These metrics let governance be evidence-driven: retire unused agents, enforce SLAs, or reassign owners when usage shifts.

Real-world snapshots: Zuora and Southwest Airlines

Zuora — deployed roughly 50 agents across Sales, Finance, Product, and Dev teams. Before the Registry, teams often rebuilt the same integrations or could not find a vetted billing helper. After centralizing records and metadata, principal architects gained a single view to catalog and manage agents, accelerating reuse and reducing duplicate builds.

“The registry gives principal architects a single view to catalog and manage agents so teams can reuse vetted capabilities instead of rebuilding them.” — Pete Hirsch, Zuora

Southwest Airlines — planning an enterprise-wide catalog to prevent agent sprawl. Centralized ownership metadata and policy enforcement are core to their approach, enabling governance at scale from day one rather than retrofitting controls after sprawl occurs.

“A centralized Agent Registry prevents agent sprawl by enforcing standardized ownership metadata and policy enforcement, enabling enterprise-scale governance from day one.” — Justin Bundick, Southwest Airlines

Tradeoffs, risks, and practical limits

Agent Registry is promising, but adoption comes with tradeoffs platform teams should evaluate:

Integration effort — existing agents may need adapters to expose MCP/A2A metadata endpoints. Plan engineering cycles for this work when moving from manual registration to automatic indexing.
Metadata sensitivity — some metadata describes sensitive behaviors or data flows; decide which fields to redact or restrict via role-based policies.
Cross‑registry federation complexity — a single namespace across multiple registries helps discovery but introduces consistency, latency, and access-control challenges.
Cost and chargeback — to avoid surprises, tag agents with cost centers and build chargeback or showback mechanisms tied to usage metrics.
Vendor lock‑in concerns — while AWS emphasizes openness and cross-platform indexing, teams should validate how easily non-AWS agents integrate and whether the path of least resistance favors AWS-native patterns.

“The registry aims to eliminate invisible agents across mixed environments by indexing agents wherever they run, so organizations can discover, govern, and reuse capabilities across their landscape.” — AWS product messaging

Practical migration checklist: make agents MCP/A2A-ready

Inventory existing agents and rank by priority (usage, criticality, cost).
Define a minimal metadata schema and required fields for your first pilot.
Implement a metadata endpoint (MCP/A2A) or adapter that returns structured JSON with the agreed schema.
Register the agent manually in the Registry and verify index/search behavior.
Enable observability hooks (metrics, logs, traces) and link them to registry records.
Run a controlled pilot with one team, collect reuse and governance KPIs, iterate schema and policies.
Roll out incrementally across teams with training and ownership SLAs.

Security and compliance checklist

Classify metadata fields by sensitivity and apply redaction where needed.
Use role-based access controls (IAM/OAuth) and separation of duties for publish vs. discover privileges.
Audit registry changes and approvals; retain provenance for compliance reviews.
Design how PII/PCI-affecting agents are annotated and isolated from broad discovery.

KPIs to measure registry success

percentage of production agents cataloged
reuse rate (calls to registered agents vs. newly built agents)
time to discover a capability (average discovery time)
number of duplicated implementations prevented
incidents traced to unknown agents (should decrease)

Federation: benefits and headaches

Federation (searching multiple registries as one) unlocks cross-team discovery in large enterprises and across partner ecosystems. Benefits include a single namespace for capabilities and easier reuse. Downsides include consistency management, access control complexity, and potential performance tradeoffs if registries are globally distributed. Start with a limited, permissioned federation and expand as identity and data governance mature.

For platform leaders: recommended next steps

Run an agent inventory and pick a high-value pilot (billing, onboarding, or a developer productivity helper).
Define a minimal metadata schema and approval workflow with security and cost tags.
Implement MCP/A2A endpoints for a subset of agents and validate automatic ingestion and search behavior.
Hook registry records to observability so governance ties to runtime metrics.
Track KPIs (catalog coverage, reuse rate) and iterate policies based on evidence.

What to watch next

automatic indexing across more AWS services
cross-registry federation details and performance guarantees
richer observability integration with cost and SLA reporting
partner catalogs and how third-party registries are surfaced
pricing and chargeback models for registry and observability consumption