AWS Agent Registry turns sprawl into a control layer

In its Apr. 9 preview announcement, AWS introduced AWS Agent Registry inside Amazon Bedrock AgentCore. On paper, the product sounds almost aggressively unglamorous. It stores metadata. It tracks versions. It manages approval states. It lets teams search what already exists.

That dry description is exactly why the launch matters.

AWS is making a blunt bet that the next enterprise AI headache is not model quality by itself. It is agent sprawl. Once a company has fifty, then five hundred, then a few thousand agents, tools, MCP servers, and workflow skills scattered across AWS, other clouds, and on-prem systems, the hard part stops being "can we build one?" The hard part becomes "who owns this, who approved it, how do I find it, and why are three teams rebuilding the same thing again?"

I keep coming back to one phrase in AWS's launch copy: a single place to discover, share, and reuse agents across the enterprise. That sounds like catalog language. It is really governance language. The registry stores metadata for agents, tools, MCP servers, agent skills, and custom resources. It can register them manually or pull details from MCP or A2A endpoints. It exposes approval workflows, versioning, deprecation, search, and access control. In other words, AWS is not pitching one more heroic agent demo. It is pitching the filing cabinet, permission layer, and lookup surface that show up right after the demos start breeding.

That also puts the launch in the same family as the control-surface shift we have been seeing elsewhere. In OpenAI's enterprise AI stack packaging, the interesting move was not a single feature. It was the attempt to turn enterprise AI into one governed operating layer. AWS is arriving from the infrastructure side, but the instinct is similar: own the boring layer that sits between experimentation and production.

This is not an app store, it is an asset register

The easiest way to misunderstand AWS Agent Registry is to hear the word registry and imagine a marketplace wall of little bots waiting to be installed. That metaphor will travel because it is simple and because executives love a familiar noun. It is also the wrong lens.

A marketplace is about browsing and selection. An enterprise registry is about control, provenance, and reuse. AWS says the preview can index records across AWS, other cloud providers, and on-premises environments. The point is not to celebrate a neat gallery of agent logos. The point is to stop large organizations from losing visibility into what already exists.

That changes the story from "AWS launched another Bedrock feature" to "AWS is productizing agent asset management." And yes, that sounds boring. Good. Enterprise systems usually become expensive because of boring failures.

Here is the practical split between what AWS says is live now and what still belongs in the future-tense bucket:

In preview now	Important, but still future-facing
Structured records for agents, tools, MCP servers, agent skills, and custom resources	Cross-registry federation across multiple registries
Manual registration or synchronization from MCP and A2A endpoints	Observability-enriched records with invocation counts, latency, uptime, and usage patterns inline
Draft, pending-approval, approved, versioned, and deprecated lifecycle states	Automatic indexing across every AWS service and workspace surface the moment something is deployed
Search via console, APIs, and an MCP endpoint	A fully unified discovery layer spanning every partner catalog AWS wants to connect
IAM-based governance plus support for corporate identity-based discovery flows	The complete every-surface, every-tool, every-IDE future AWS sketches in the roadmap

That table matters because AWS is mixing a real preview with a fairly ambitious destination story. Readers should keep the distinction crisp. Approval workflows, versioning, lifecycle states, and five-region preview availability are current. Cross-registry federation and observability-enriched records are not.

The detail most coverage will miss sits inside the protocols

The best part of this launch is also the part most quick coverage will skip because it requires reading past the headline. AWS Agent Registry is not just a place where humans search for assets in a console. According to both the announcement and the docs, the registry is available through APIs and as an MCP-compatible endpoint.

That changes the shape of the product.

If a registry is only a console, then it is a catalog for admins. If a registry is also an MCP server, then it becomes part of the live tool-discovery loop for developers and agents. AWS explicitly says any MCP-compatible client can query it, and it names Kiro and Claude Code as examples. That does not make them deep launch partners. It does make the point clear. AWS wants agent discovery to happen where the work is already happening.

This is why the MCP and A2A support matters more than it sounds. The preview can ingest details from MCP or A2A endpoints, validate MCP and agent records against protocol schemas, and then expose the resulting catalog back through an MCP surface. That is a loop, not a list.

We have been seeing variants of this move in other tooling stories. In Google's Gemini API Docs MCP push, the interesting shift was that documentation stopped being passive reference material and became a live input channel for coding agents. AWS is doing something adjacent here. It is turning discovery and governance metadata into something agent clients can query directly instead of forcing every team to maintain its own private spreadsheet of trusted tools and services.

And yes, the spreadsheet still exists in plenty of companies. It always does. It just usually arrives with three stale owners, one mystery column, and a quiet trail of regret.

The real bottleneck has moved from building agents to managing them

This is the section that matters now.

Enterprise AI spent the last two years arguing about whether companies could build agents at all. That question is not gone, but it is no longer the only one that matters. In a lot of organizations, pilots already exist. Somebody built a coding agent. Somebody else wired up a browser agent. Another team turned a workflow into an MCP server. A line-of-business group bought a managed tool that quietly behaves like an agent whether procurement calls it that or not.

Once that happens, the bottlenecks shift fast:

• discoverability, because teams cannot reuse what they cannot find
• governance, because nobody wants unknown automation wandering into production
• identity, because hidden credential sprawl is how neat demos become security meetings
• lifecycle management, because pilots rarely retire themselves
• duplication, because every team thinks its own version is special until the cloud bill arrives

AWS is very clearly aiming at that layer. The key capabilities page describes governance and curation, EventBridge notifications for approval workflows, and direct integration with existing review pipelines through the UpdateRegistryRecordStatus API. That is not consumer product language. It is operator language. It is for the team that has to explain to security why an internal agent can invoke one MCP server but not another.

The timing also makes sense inside AWS's broader AgentCore push. AgentCore already has runtime, browser, identity, gateway, and observability surfaces orbiting around agent deployment. Registry is the layer that ties those pieces into an enterprise memory of what exists. Without that memory, each new tool becomes another isolated little kingdom. With it, AWS can pitch a more durable story: build agents anywhere, but catalog and govern them through us.

That is why I think the launch matters more than most feature recaps will admit. The market fight is moving toward control planes for mixed-agent estates. The winner will not just be the company with the best demo. It will be the one that gives platform teams a sane way to manage the mess after everybody falls in love with the demo.

You can even see the adjacent pressure from the client side. In the Claude Code aftermarket story, the growing ecosystem was not only about agents doing more work. It was about the surfaces around them: plugins, MCP servers, workflows, integration points, and the surrounding operational layer. A registry that those clients can query is a natural next move.

What is real in preview, and what is still procurement poetry

AWS deserves credit for shipping something concrete. The preview is not empty. The current feature set is substantial enough to support a serious argument:

• records can be created manually or synchronized from MCP and A2A endpoints
• registry entries can carry ownership, compliance, protocol, and invocation metadata
• approval states, version history, and deprecation are part of the lifecycle model
• search combines semantic and keyword matching
• the service is available in five AWS regions
• access can be controlled with IAM and, for discovery flows, corporate identity-friendly token setups instead of handing everyone raw AWS credentials

That is enough to make the product legible.

But it is still preview. Readers should not let the roadmap blur into the present tense. Cross-registry federation is future-facing. So is the richer vision where observability data sits beside every record and everything deployed across AWS surfaces gets indexed automatically. Those may happen. They are not the same thing as shipping now.

This is where a lot of launch coverage gets sloppy. Preview products attract two bad habits at once. The first is under-reading, where people treat the announcement like a small feature. The second is over-reading, where every roadmap line gets repeated like it already exists. AWS Agent Registry only makes sense if you avoid both mistakes.

There is also a category mistake I would avoid. This is not proof that enterprises want one giant unified registry for every conceivable workflow asset tomorrow morning. It is proof that AWS thinks the governance problem is getting large enough to deserve a product surface. That is a lower bar, but it is a meaningful one.

The noise you can safely ignore

A few parts of this story are not worth over-investing in yet.

First, ignore the app-store framing. It is catchy, but it hides the operational point. Enterprises are not mainly struggling with too little browsing joy. They are struggling with too little visibility and too many half-owned automations.

Second, ignore customer-logo theater unless it comes with specific operating detail. Named logos like Zuora and Southwest Airlines help validate that the pain exists, but they do not tell you how broadly or deeply the product is deployed. They are evidence of interest, not evidence of maturity.

Third, ignore any reading that turns Claude Code or Kiro into co-launch stars. AWS names them as examples of MCP-compatible clients. That is useful because it shows the registry is meant to be queried from outside an AWS-only console. It is not the same as saying those tools are strategically fused into the launch.

Finally, ignore the temptation to treat preview governance software as somehow less important because it is not flashy. The history of enterprise infrastructure is basically one long reminder that the important layer is often the one with the least cinematic demo.

The market AWS is actually entering

If AWS executes, AWS Agent Registry could become part of a bigger enterprise control-plane market that barely has a settled name yet. Call it agent governance, call it agent asset management, call it catalog plus lifecycle plus identity plus search. The label matters less than the shape.

The shape looks like this: companies will keep building agents in more than one place, with more than one framework, across more than one cloud. They will expose capabilities through MCP, A2A, APIs, and internal tools. Then they will discover that the expensive part is not generating another agent. It is governing the estate they already created.

That is the opening AWS sees. Not "we have one more agent." More like, "you are going to need traffic laws."

I think that is the right read. The preview is not mature enough to declare victory, and some of the most ambitious pieces are still roadmap material. But the direction is sharp. AWS is treating enterprise agents as assets that need cataloging, approval, search, and retirement. Once that framing sticks, the conversation changes. The next battle is less about who can build an agent fastest and more about who can keep an entire organization's agent layer legible.

That is a much bigger market than a feature launch. And a lot more durable.