目錄
Over the past two years, most discussions about AI agents have focused on how to connect everything. MCP servers, tools, skills, and agent frameworks have appeared one after another, and getting a workflow running has usually felt more urgent than the management problems that follow. Once a single company starts operating dozens or hundreds of agents, however, a different set of complications emerges: whether someone has already built a given function, who is responsible for a particular agent, which tools are no longer maintained, and whether an apparently usable MCP server has passed internal review.
On August 31, 2026, AWS Agent Registry became generally available. It does not make models better at reasoning, nor is it another agent builder. It is a centralized catalog and discovery layer that organizes the agents, MCP servers, agent skills, and other custom resources in an organization into a registry that can be searched, reviewed, and managed. AWS describes the problem directly: after an agent system grows from a handful of tools to hundreds, the real bottleneck becomes “Finding what already exists and trusting what you find.”
Products like this may not attract as much attention as a new model announcement, but they reveal the problems agents encounter once they enter real working environments. Connecting to MCP is no longer the only challenge. After that connection is made, determining what exists, who uses it, which version remains valid, and which resources other agents can discover becomes another layer of work.
AWS Agent Registry is clearly too heavy for a studio with only a few automations, but the underlying logic appears surprisingly early. When there are only three or five agents, leaving them unorganized seems to make no difference. After tools have been replaced several times and more OAuth permissions have accumulated, the first thing people usually forget six months later is not the prompt, but whether a particular workflow is still running at all.
What Problem Does AWS Agent Registry Solve as It Moves from Preview to GA?
AWS Agent Registry first launched in preview on April 9, 2026, and became generally available on August 31, roughly four months and three weeks later. Its core capabilities were already present during preview, including centralized registration, semantic and keyword search, an approval workflow, URL-based discovery, an MCP endpoint, and CloudTrail integration. GA added Infrastructure as Code, tags, cross-account sharing through AWS RAM, automatic detection of AgentCore resources, and more access points such as Amazon Quick and Kiro.
More significant than the idea that “AWS moved a preview product to GA quickly” is the fact that almost every capability added between preview and GA addresses problems that arise only after enterprises begin deploying it in practice: how to share across accounts, manage with IaC, classify resources and attribute costs, and find agents that were never actively registered.
In other words, the Registry’s problem was never whether an agent could be built. It was whether a reliable inventory existed after it had been built.
What Three Management Problems Most Often Appear After Enterprises Deploy AI Agents at Scale?
AWS summarizes the problems simply in its GA post. The first is the absence of a centralized inventory: organizations do not know which agents, tools, and skills exist or who owns them. The second is the lack of cross-team discovery: a capability may already exist, but another team cannot find it and rebuilds the same thing. The third is trust. If the owner, version, approval status, description, and endpoint of a resource are unclear, finding it does not make it safe to reuse.
A Registry Can Contain Four Record Types, Not Just Agents
Four top-level recordType values are officially supported: AGENT, MCP, SKILL, and CUSTOM. An agent record can use an A2A Agent Card to describe the agent and its skills. An MCP record stores an MCP server definition and can also include the tool definitions provided by that server. A skill record stores an Agent Skill Definition, while a custom record can preserve other organization-specific resources as custom metadata.
An important distinction is that an MCP tool is not a separate fifth record type. It is generally stored in the tool definitions of an MCP server record. This difference matters when records are created through the API, CLI, or IaC.
Keyword and Semantic Search Work Together to Find Resources
Registry search is not limited to matching names. SearchDiscoverableRegistryRecords performs semantic search and keyword search together, then merges and ranks the results. Users can search for an exact name or describe a need in natural language, such as “find a tool that can handle ticket routing.” The tool name, description, input schema, and other details within an MCP server can also be indexed.
If everyone must already know what a tool is called before they can find it, the result is only a better-looking spreadsheet. Real discovery must allow users to know only what they need to do, without knowing what name someone inside the company has already given that capability.
Approval Is Configurable, but Only Approved Records Enter Discovery
The original draft says that records must receive administrator approval before they can be searched. That is broadly correct, but it needs more precision. A Registry can use manual approval or set auto_approve. The fixed rule is that the general search, browse, and MCP discovery functions in the Discovery Plane expose only records whose latest revision is APPROVED. Draft, Pending Approval, Rejected, and Deprecated records do not appear in normal consumer searches.
Once a record is updated, it returns to Draft and proceeds through its configured lifecycle again. This is more reasonable than treating a record as permanently valid after registration, because an earlier approval may no longer apply after a tool version, endpoint, or capability changes.
CloudTrail Supports Auditing, but Not Every Event Is Fully Retained by Default
AWS Agent Registry is formally integrated with CloudTrail. Management events such as Registry Create and Update operations enter CloudTrail Event History by default and are retained for 90 days. To record data events such as discovery, an organization must separately create or modify a trail and add the Agent Registry data event selector.
The more accurate description, therefore, is not that every Registry access is automatically and fully written to CloudTrail. Rather, the Registry supports a complete CloudTrail audit architecture: management events are traceable by default, while data events must be enabled separately as needed.
The Registry Also Provides Its Own MCP Endpoint
This is one of the most interesting layers of Agent Registry. Every Registry can provide an MCP-compatible endpoint, and an MCP client can directly call search_discoverable_registry_records, list_discoverable_registry_records, and batch_get_discoverable_registry_record. The Registry is not only something administrators search in the console. An IDE or an agent itself can use it as a discovery tool, find approved resources, and then decide which tool or agent to connect to.
The AWS GA post explicitly defines consumers as developers, business users, or autonomous agents. In other words, “an agent searches the Registry for tools by itself” is not a speculative extension; it is a usage pattern the product explicitly supports.
However, returning an endpoint and authentication information does not automatically grant the searcher access to the underlying tool. To actually call an agent or MCP server, authorization must still be completed according to each resource’s onboarding process and credentials.
What Enterprise Management Capabilities Did GA Add Beyond Preview?
After GA, registries can be created and managed as Infrastructure as Code through AWS CloudFormation, Terraform, and AWS CDK, rather than leaving Registry configuration only in the console. Registries and records can also have tags for organization, cost allocation, and access control.
AWS RAM enables registries to be shared across AWS accounts, allowing an enterprise to build an organization-wide Registry instead of asking each account to maintain a separate catalog that no other account can see. GA also added automatic detection of AgentCore Runtime and AgentCore Gateway resources across an entire AWS Organization. A newly deployed agent or MCP endpoint can first be discovered as a draft record and then enter the review and approval process.
The boundary between current capabilities and the roadmap matters here. At GA, automatic detection covers AgentCore Runtime and AgentCore Gateway. The AWS GA blog says the company plans to expand this to other environments, including EC2, EKS, and ECS, and potentially use federation to see non-AWS resources. Those are future directions and should not be described as capabilities that are already broadly supported.
There are more access points as well. Registry resources can now be discovered from Amazon Bedrock AgentCore, Amazon Quick, and Kiro. Quick can directly search for approved agents and MCP servers in an organization’s Registry and enable them for use in Chat, Agents, Apps, Flows, or Deep Research.
Why Are AI Agents Starting to Need a Registry?
As MCP has become widespread, the way external tools connect to agents has grown much more standardized. REST APIs, databases, and internal services can be wrapped in MCP servers and exposed as tools that models understand. This does reduce integration friction, but it should not be described as making integration costs nearly zero. Authentication, permissions, schemas, deployment, observability, and runtime maintenance all remain.
The real change is that easier integration lowers the barrier to creating tools, making it more likely that many similar capabilities will exist simultaneously within an organization. Without a place to search first, shadow agents, duplicate MCP servers, and tools with no known maintainer naturally appear. AWS itself lists “Teams build in isolation” and “rebuild what already exists” among the core problems the Registry is intended to address.
This development resembles the earlier evolution of software engineering. More packages created the need for package registries. More container images created the need for image registries. Once the number of APIs grew, catalogs, gateways, and governance became necessary. Adding a Registry after agents and MCP tools enter production is not unusual; it simply means that AI tools have reached the same asset-management stage.
What Does It Mean That AWS Discussed Observability and Multi-Tenant Isolation on the Same Day?
On August 31, the AWS Machine Learning Blog also published several posts about production agentic systems, including observable agentic retrieval, multi-tenant data isolation on Managed Bedrock Knowledge Base, and an implementation for connecting an MCP server hosted on AgentCore Runtime to Amazon Quick.
Taken together, these posts reveal a common theme: after an agent has been built, the next questions are whether retrieval can be traced, whether data from different tenants can remain separate, and whether existing tools can be reused. However, this is a product observation drawn from AWS content published at the same time. It should not be framed as an official AWS announcement that “the agent era has moved from building to cleaning up.”
A more measured conclusion is that agent infrastructure in 2026 is giving visibly more attention to production concerns such as governance, observability, isolation, and discovery.
Is AWS’s Recognition as a Forrester AI Infrastructure Leader Directly Related to Agent Registry?
On August 31, AWS also announced that it had been named a Leader among 13 vendors in The Forrester Wave: AI Infrastructure Solutions, Q4 2025 and had received the highest score in the Strategy category.
This provides context for AWS’s broader emphasis on AI infrastructure, but it cannot prove that “Agent Registry made AWS a Leader.” The Forrester evaluation had a much broader scope, including training, fine-tuning, inference infrastructure, and overall strategy. Its Q4 2025 evaluation period also predates the public preview of Agent Registry in 2026.
Similarly, the claim that “model capabilities will become increasingly homogeneous, so governance will be the real moat for cloud providers” is better treated as a market inference, not as a conclusion these AWS documents can directly prove. What can be said with confidence is that competition among cloud platforms already extends beyond the models themselves to agent runtimes, identity, gateways, evaluation, registries, observability, and governance.
Two Governance Risks to Consider Before Adopting AWS Agent Registry
Registry Metadata Can Itself Expose Internal Architecture
In its enterprise considerations, AWS specifically warns that permission to “search for resources” should not be identical to permission to “register new resources.” Tool metadata may contain internal endpoints or architecture details, which can themselves be valuable to an attacker. Organizations therefore need to decide which metadata can be placed in a widely searchable Registry and which information should remain within a tighter access boundary. AWS also recommends auditing who searches the Registry and how frequently.
Building a Registry does not mean centralizing every piece of architectural information and then allowing anyone in the company to search it freely. The catalog itself also needs data classification and IAM boundaries.
Inclusion Does Not Mean a Resource Is Safe or Has Completed Security Review
Another point that requires correction is that AWS Agent Registry does not currently include built-in completion of every security scan, duplicate detection process, and compliance assessment.
AWS currently provides a record lifecycle, approval states, EventBridge hooks, and approval APIs so that enterprises can connect their own review processes. The minimum recommendation in the AWS GA blog is to check for similar resources before publishing, conduct a security scan of the agent, tool, or skill, and then have a human approver confirm that the metadata is complete, that the description is understandable to people outside the original development team, and that the resource belongs in the Registry. A simple CI/CD checklist or Slack approval flow can work at the beginning.
Security and vulnerability assessments, compliance evaluations, and de-duplication analysis are expected to appear more directly in the approval workflow later, but AWS explicitly places these under What's next. They remain part of the roadmap.
“Approved,” therefore, means that a resource has passed the approval bar set by the organization itself. It does not mean that AWS has completed a comprehensive security certification of the agent.
What Can an Enterprise Do Before It Truly Needs an Agent Registry?
The first step is usually not to purchase a Registry immediately, but to understand what already exists. Agents, automations, MCP servers, skills, and important integrations can be listed in an inventory that records at least the name, purpose, owner, current environment, data accessed, whether it has write permission, the last validation date, and current status. Completing this table alone will usually uncover a number of duplicate or unmaintained resources.
The second step is to establish a lightweight publishing threshold. When a tool is prepared for use by others for the first time, check whether an equivalent capability exists, whether authentication and permissions are appropriate, who is responsible for maintenance, and whether the tool can be stopped if a problem occurs. A small team does not need a ten-level approval process. One checklist and one reviewer are already much better than no governance at all.
The third step is to complete the lifecycle. An agent should not have only one state—“exists.” It can at least be classified as Draft, Active, Deprecated, or Retired, with a replacement link. AWS Agent Registry uses a similar lifecycle: when an approved record is no longer needed, a curator can mark it as Deprecated.
Do Individual Creators or Small Studios Need AWS Agent Registry?
In most cases, no. If there are only a few agents and automations, adding an AWS Registry solely to manage them will make the system more complex. Still, the problems the Registry is designed to solve appear quickly even at a small scale: forgotten workflow names, a long list of lingering OAuth authorizations, two versions of the same process, uncertainty about which version is still running, and discovering only after an automation breaks that its underlying tool had been discontinued for months.
A simpler option is to maintain an “Automation／Agent Registry” in an existing knowledge tool:
| Field | Suggested Information |
| Name | Name of the agent, automation, or MCP resource |
| Purpose | One-sentence description of the problem it actually solves |
| Owner | Person currently responsible for maintenance |
| Trigger | Manual, scheduled, webhook, or another condition |
| Tools／Connections | Gmail, Notion, Drive, Slack, GitHub, and others |
| Access | Read-only／Write／Delete／Send, and others |
| Cost | Monthly fees, tokens, credits, or API costs |
| Status | Draft／Active／Deprecated |
| Last Verified | Most recent date on which it actually ran successfully |
| Replacement | New workflow that replaced it after deprecation |
The value does not come from making the table attractive. It comes from being able to encounter an unfamiliar integration six months later without first searching chat history to determine what it is.
If there are only three automations, the table may go unopened for a month. Its value suddenly becomes obvious after more than a dozen tools have been connected, agents have been replaced several times, and the OAuth page displays a long list of authorizations.
What AWS Agent Registry Really Reveals Is That Agents Have Entered the Asset-Management Stage
AWS Agent Registry will not make an agent’s answers more accurate, nor will it automatically make an unsafe MCP server secure. It addresses another practical problem: once agents, tools, and skills become too numerous to manage from memory, organizations need a place to know what exists, which resources have passed their current usage threshold, and who is responsible for them.
AWS now even allows agents themselves to search the Registry through MCP. This means the catalog is not only an asset list for IT administrators; it may become a direct part of agent discovery.
The Registry does not complete every governance task by itself. Some security scanning, duplicate analysis, fine-grained discovery policy, and additional observability capabilities must still be built by enterprises, while others remain on the AWS roadmap. That is a more realistic reflection of today’s agent ecosystem: there are already many ways to build agents, but the systems that keep them discoverable, understandable, and maintained over time are still catching up.
Small teams do not need to wait until they have 1,000 agents to address this problem. Once no one can answer, “Is this workflow still running?” it is already time to maintain a Registry.
FAQs
AWS Agent Registry is a centralized agent catalog provided by AWS within the Amazon Bedrock AgentCore ecosystem. It registers and manages an organization’s agents, MCP servers, agent skills, and other custom resources. It does not build agents or improve model capabilities. Its main purpose is to address resource discovery, duplicate development, unclear ownership, version management, and governance. Because the Registry supports keyword and semantic search, users can describe a need in natural language even when they do not know a tool’s exact name.
AWS Agent Registry first launched in preview on April 9, 2026, and became generally available on August 31, 2026. GA added enterprise management capabilities such as Infrastructure as Code, tags, cross-account sharing through AWS RAM, and automatic detection of AgentCore Runtime and Gateway resources. The period from preview to GA was approximately four months and three weeks, not less than four months.
The problem is shifting from “Can an agent be built?” to “How should many agents be managed?” When different teams can quickly create agents, MCP servers, and skills, problems such as duplicate development, shadow agents, unclear ownership, and continued use of retired tools begin to appear. A Registry does not increase AI capabilities; it makes existing capabilities discoverable, understandable, and manageable. It also makes it easier to identify which resources should remain maintained and which can be retired.
No. The Registry addresses discovery and governance but does not automatically guarantee resource quality. Before use, teams should still confirm the owner, version, authentication, permission scope, maintenance status, and completion of the organization’s security and compliance reviews. Registry metadata may itself contain endpoints or architectural information, so permissions for “who can search” and “who can create or modify a record” should also be designed separately.
Most do not need to deploy AWS Agent Registry directly, but the same management logic is valuable. A team with several agents, automations, MCP servers, or OAuth integrations can begin with a simple Registry that records each item’s name, purpose, owner, trigger, tools and connections, read and write permissions, cost, status, and last successful validation date. Organization becomes necessary not when the number of agents reaches 1,000, but when no one can answer whether a particular workflow is still running.
Agent Registry integrates with AWS CloudTrail, but management events and data events must be distinguished. Management operations such as creating and updating resources appear in CloudTrail Event History. To record data events such as discovery and search, an organization must separately create or modify a trail and enable the corresponding data event selector. It is therefore inaccurate to say that every Registry action is fully retained by default, although AWS provides the foundation required to build complete auditing.
Yes. GA added AWS Resource Access Manager, or AWS RAM, which allows a Registry to be shared with other AWS accounts. An enterprise can therefore create a more centralized organization Registry instead of requiring every account to maintain a separate catalog that no other account can see. Registries and records can also have tags for classification, cost allocation, and access control.
MCP addresses how AI connects to external tools in a consistent way. Agent Registry addresses how an organization knows what exists, what has been approved, and who maintains it after the number of MCP servers and agents grows. The Registry can store MCP server definitions and tool metadata and synchronize information from existing MCP endpoints. It also provides its own MCP endpoint, allowing MCP clients to search for approved resources within the organization. The two are not substitutes; they operate at different infrastructure layers.
Yes. Agent Registry provides an MCP-compatible endpoint, and an MCP client can search, list, and retrieve approved Registry records. Developers can search from an IDE or other tool, while an agent itself can use the Registry as a discovery layer, identify available agents, MCP servers, or skills, and then choose a resource. Finding a tool in the Registry does not automatically grant access to the underlying system, however. Execution must still satisfy that service’s own authentication and access-control requirements.
Not at present. AWS Agent Registry provides an approval workflow, record lifecycle, EventBridge hooks, and related APIs, allowing enterprises to connect security scans, duplicate checks, compliance reviews, and human approval to their publishing processes. A complete automated security assessment and de-duplication analysis are not all built into the current GA release. AWS has listed more automated security, compliance, and deduplication signals as future directions. Accordingly, APPROVED means an agent has passed the organization’s own review threshold, not that AWS has completed a comprehensive security certification.
Not necessarily. A Registry can use manual approval or enable auto-approval. The fixed rule is that the general Discovery Plane exposes only the latest record revision whose current status is APPROVED. Draft, Pending Approval, Rejected, and Deprecated records do not appear in ordinary consumer searches. When a record is later modified, it re-enters the lifecycle rather than retaining the same status forever after one approval.
Four top-level record types are officially supported: AGENT, MCP, SKILL, and CUSTOM. Tools provided by an MCP server are stored within the tool definitions of the MCP record. MCP tools can therefore be searched and managed, but Tool is not an independent fifth record type. Other resources that do not fit the first three categories but still need organizational governance can be preserved through custom metadata.