AWS Agent Registry Preview: Govern Agents, MCP Servers, and Skills at Scale

On April 9, 2026, AWS launched AWS Agent Registry in preview inside Amazon Bedrock AgentCore. That launch matters because most teams are no longer struggling with a single agent demo. They are struggling with sprawl.

One team ships an MCP server for CloudWatch. Another ships a nearly identical one for the same metrics. A third team wraps an internal deployment API, but nobody knows which version is approved, who owns it, or whether it is safe to expose to production agents. That is the point where agent infrastructure starts looking like old integration debt with a new label.

AWS Agent Registry is AWS trying to put a control plane around that mess. It is a governed catalog for agents, tools, skills, MCP servers, and custom resources that teams can publish, approve, search, and invoke through the console, APIs, or an MCP endpoint. If you are already using posts like AWS Bedrock Agents for DevOps or Server-Side Tool Execution in Bedrock, Registry is the missing discovery and lifecycle layer above those runtimes.

What AWS Agent Registry Actually Does

According to the AWS announcement and AgentCore documentation, Registry gives you:

• a centralized catalog for agents, MCP servers, tools, agent skills, and custom resources
• approval workflows so records are not discoverable until a curator approves them
• search through both semantic and keyword matching
• access through the AgentCore console, AWS CLI, AWS SDK, or a remote MCP endpoint
• inbound authorization with either AWS IAM or JWT-based OAuth-style access
• CloudTrail logging for administrative and access actions

That list sounds administrative, but it is operational in practice.

The real question a platform team needs to answer is simple: which agent or MCP server should another team trust and reuse? If the answer still lives in Slack threads and tribal memory, you do not have an agent platform. You have an accident waiting to happen.

The Record Model Is the Important Part

AWS organizes the service around two top-level concepts:

• registries, which are the catalogs you create
• registry records, which describe the individual resource you publish

That sounds obvious, but it creates a useful boundary. Your runtime still lives wherever it lives. An MCP server may be in AgentCore Runtime, ECS, or another environment. An agent may be managed or custom. Registry does not replace those systems. It publishes metadata and governance around them.

AWS also validates MCP and agent records against protocol schemas, which matters because it reduces the chance that teams publish hand-wavy metadata that looks searchable but is not actually interoperable.

For a real internal platform, I would organize registries one of two ways:

• by lifecycle stage: dev, qa, prod
• by asset type: agents, mcp-servers, skills

If your organization is still small, stage-based registries are usually easier to govern. If you already have platform ownership split across multiple teams, asset-type registries may be cleaner.

What Preview Means in Practice

This is a preview feature, so you should treat it like a platform component you validate before you standardize on it. AWS says the preview is currently available in five Regions:

• US East (N. Virginia)
• US West (Oregon)
• Europe (Ireland)
• Asia Pacific (Tokyo)
• Asia Pacific (Sydney)

That region list matters because you may need your registry near the AgentCore services your teams already use.

The other preview reality is governance design. Registry gives you the mechanisms, not the policy. You still need to define:

• who can publish draft records
• who can approve them
• what metadata is mandatory
• what makes a record production-safe
• when a record should be deprecated or rejected

If you skip those decisions, a registry quickly becomes another junk drawer.

A Practical First Workflow

AWS documents a straightforward lifecycle:

1. Create a registry.
2. Create a registry record.
3. Submit the record for approval.
4. Approve the record.
5. Search and discover the approved resource.

That maps well to how most engineering organizations already handle promotion. You can even plug approval into an EventBridge + Step Functions workflow instead of leaving it as a purely manual console click.

Here is a minimal CLI flow using the AWS-documented commands:

aws bedrock-agentcore-control create-registry \
  --name "platform-prod-registry" \
  --description "Approved agents and MCP servers for production" \
  --region us-east-1

aws bedrock-agentcore-control create-registry-record \
  --registry-id REGISTRY_ID \
  --name "cloudwatch-investigator" \
  --descriptor-type MCP \
  --descriptors '{
    "mcp": {
      "server": {
        "inlineContent": "{\"name\":\"ops/cloudwatch-investigator\",\"description\":\"Read-only CloudWatch and Logs investigation tools\",\"version\":\"1.0.0\"}"
      }
    }
  }' \
  --record-version "1.0.0" \
  --region us-east-1

aws bedrock-agentcore-control submit-registry-record-for-approval \
  --registry-id REGISTRY_ID \
  --record-id RECORD_ID \
  --region us-east-1

aws bedrock-agentcore-control update-registry-record-status \
  --registry-id REGISTRY_ID \
  --record-id RECORD_ID \
  --status APPROVED \
  --status-reason "Reviewed for metadata quality and least-privilege scope" \
  --region us-east-1

The operational detail here is useful: AWS documents that new records move through CREATING and then DRAFT before they are ready for approval. That means you can design your automation around clear state transitions instead of guessing whether a record is discoverable yet.

Why Approval Workflow Is the Real Feature

The search layer will get the headline, but the approval model is the real enterprise feature.

AWS supports both auto-approval and manual approval. Manual approval is the right default for anything touching production data or shared tools. It forces an explicit review before a record is visible in search results. That is how you prevent the registry from turning into a search index of half-finished experiments.

The better pattern is:

• allow builders to create draft records freely
• require approval for production discovery
• use a lightweight checklist for naming, ownership, auth, and blast radius
• expire or deprecate stale records aggressively

This is also where existing IAM design matters. If you have weak identity boundaries already, Registry will not save you. It works best when combined with sane least-privilege controls like the ones in AWS IAM Roles vs Policies and IAM Permission Boundaries.

EventBridge Makes Registry Operational

AWS documents an EventBridge integration for pending approvals. When a record changes to pending approval, AWS emits an event on the default EventBridge bus with:

• source: aws.bedrock-agentcore
• detail type: Registry Record State changed to Pending Approval
• record details including registryRecordId and registryId

That is exactly enough to automate a real review pipeline.

For example:

{
  "source": ["aws.bedrock-agentcore"],
  "detail-type": ["Registry Record State changed to Pending Approval"]
}

From there, you can route to Lambda, Step Functions, Slack, Jira, or an internal approval dashboard. That matters because registries do not stay healthy through manual heroics. They stay healthy when review becomes part of normal delivery flow.

If your team is already thinking in terms of release gates, this is a cleaner fit than asking engineers to remember another console queue.

URL Discovery Is Useful, but It Needs Discipline

One of the better preview features is URL-based discovery. AWS says Registry can discover metadata from a live MCP server or agent endpoint and pull in details such as tool schemas and capability descriptions.

That is a good feature for platform onboarding, but it is also an easy way to publish noise if you do not curate aggressively.

My recommendation:

• use URL discovery for ingestion speed
• require approval before search visibility
• require owner, environment, and support metadata on every record
• reject records that do not clearly describe blast radius and auth model

That way discovery stays useful instead of becoming another index of vaguely named services.

Where Registry Fits in the AgentCore Stack

The clean mental model looks like this:

• AWS Bedrock Agents for DevOps or your own framework handles reasoning and task execution
• Bedrock AgentCore Gateway server-side tool execution centralizes tool access
• Bedrock AgentCore Evaluations in CI/CD measures whether the agent still behaves correctly
• AWS Agent Registry tells the rest of the organization what exists, what is approved, and what should be reused

That is why Registry is more valuable to organizations than to solo builders. It solves discovery, curation, and lifecycle problems that only show up once multiple teams are shipping agent infrastructure.

What I Would Register First

Do not start by registering every experiment. Register the assets that create operational or compliance risk:

• MCP servers shared across teams
• production agents with data access
• reusable agent skills and templates
• tool collections exposed through Gateway
• records tied to evaluation suites or approval policies

That gives you a catalog of the things that matter when something breaks, spends money, or touches sensitive data.

Final Take

AWS Agent Registry is not another toy launcher for agent demos. It is the first serious AWS answer to the catalog, curation, and governance problem that appears once agent infrastructure spreads across a real engineering organization.

If you only have one experimental agent, you probably do not need it yet. If you already have multiple MCP servers, multiple teams, and no reliable answer to “which tool should we trust?”, Registry is the right direction. The preview is early, but the problem it solves is very real.

Sources

• AWS What’s New: AWS Agent Registry for centralized agent discovery and governance is now available in Preview
• AWS Docs: AWS Agent Registry overview
• AWS Docs: Get started with AWS Agent Registry
• AWS Docs: Notifications for pending approvals