September 17 deadline: AWS ends the preview Agent Registry namespace
Update, September 17, 2026: AWS says support for the preview bedrock-agentcore namespace ends today. The replacement agent-registry namespace is a migration target, not a newly launched product. Existing automation should be checked for clients, resource names, record payloads and directory assumptions before the old namespace disappears.
| Replacement change | Compatibility check |
|---|---|
agent-registry namespace | Search code, policies, templates and dashboards for the preview name |
Required recordType | Reject a test record that omits the field before production migration |
| List and batch-get APIs | Verify pagination, permissions and missing-record behavior |
| Record tags | Preserve governance tags and validate tag-based access workflows |
| Redesigned directory | Confirm discovery results and operator procedures still match |
| Nine-region availability | Map records, replication and failover to supported regions |
Run a reversible namespace cutover
- Export the current registry records and permissions.
- Create replacement records in a non-production environment.
- Compare list, batch-get and discovery results by record identifier.
- Switch one read-only consumer to the new namespace.
- Monitor missing records, denied calls and region mismatches.
- Keep the export and old configuration as the rollback package.
See the Agent Registry concepts guide and AgentCore release notes. The ARD and registry-layer comparison remains below.
MCP can tell an AI agent how to call a tool. It does not tell the agent where every trustworthy tool lives. Agentic Resource Discovery is an early attempt to build that missing map.
Agentic Resource Discovery, or ARD, is an open specification for cataloging, searching, and discovering agents, MCP servers, skills, APIs, and other callable services across multiple registries. The canonical project is at version 0.91 and describes itself as open and evolving.
The idea is timely. Companies are accumulating tool servers and specialist agents faster than operators can find, vet, connect, and retire them. The important caveat is just as large: finding a resource is not the same as trusting it, authorizing it, or proving that it still does what its catalog record claims.
Update: AWS Agent Registry is GA, and it is a different layer
Update, September 1, 2026: AWS Agent Registry is now generally available as a private system of record for agents, tools, skills, MCP servers, and custom resources. Teams can use it through the AWS console, CLI, and SDK, while Amazon Bedrock AgentCore, Amazon Quick, and Kiro IDE can use the catalog for discovery.
The GA release adds infrastructure-as-code support through CloudFormation, Terraform, and CDK. It also adds tags for organization, cost allocation, and access control, plus AWS Resource Access Manager sharing across accounts and organizations. Registry administrators can automatically detect AgentCore runtime and gateway agents across an organization, and Amazon Quick can discover approved registry entries through a connector.
| Question | AWS Agent Registry GA | ARD v0.91 |
|---|---|---|
| Primary job | Private catalog and governance inside an AWS organization | Federated discovery across compatible registries |
| Administration | Console, CLI, SDK, IaC, tags, approvals, and CloudTrail | Open specification, schemas, and conformance tooling |
| Sharing | Cross-account and organization sharing through AWS RAM | Domain-anchored discovery across ecosystems |
| Execution permission | Still requires IAM, policy, and runtime authorization | Outside the discovery specification |
| Availability | Five AWS regions at GA | Implementation-dependent |
The five GA regions are US East (N. Virginia), US West (Oregon), Europe (Ireland), Asia Pacific (Tokyo), and Asia Pacific (Sydney). A global organization should decide where the registry record, approval history, and discovery traffic live before making it the control plane.
This update makes the distinction in the original article clearer. AWS Agent Registry can be the curated internal catalog. ARD can become the protocol that helps compatible catalogs find one another. Neither layer proves that a listed agent is safe, that its description is current, or that the caller may invoke it. Discovery returns a candidate. IAM and runtime policy still decide whether it acts.
Read the AWS general availability announcement and the AWS implementation guide for agents, tools, and skills.
The missing problem is discovery across catalogs
A small team can keep five tools in a configuration file. A large organization can have hundreds of MCP servers, internal APIs, agent cards, skills, and vendor services spread across clouds and business units. Each environment can maintain its own registry, approval workflow, identity system, and metadata format.
ARD proposes a common way for those catalogs to describe and expose resources without moving everything into one global database. Its design is federated and domain-anchored: publishers keep local control while discovery clients can search across compatible services.
ARD, MCP, A2A, and registries solve different layers
| Layer | Primary question | What it does not prove |
|---|---|---|
| ARD | Where can I discover a resource and its catalog metadata? | That the resource is safe, authorized, reachable, or correct |
| MCP | How can a model client interact with tools, resources, or prompts? | That a server should be trusted or globally discoverable |
| A2A or agent card | How does one agent describe and communicate with another? | That an enterprise has approved the agent for this user or task |
| Private registry | Which records has this organization curated in one environment? | That other registries use the same schema or can search it |
| IAM and policy engine | May this identity perform this action now? | That the selected tool is useful or its output is accurate |
AWS Agent Registry now makes the distinction concrete as a generally available private catalog. It provides approval workflows, hybrid search, CloudTrail audit, infrastructure-as-code support, tags, and cross-account sharing inside an AWS organization. ARD remains the interoperability proposal for catalogs in AWS, other clouds, on-premises systems, and SaaS environments.
The DNS analogy helps, but it can mislead
AWS compares ARD federation to the Domain Name System. The analogy is useful because DNS lets many authorities publish names under domains they control while clients resolve them through a shared protocol.
AI resources require richer decisions than hostname resolution. A catalog may claim that an agent reviews invoices, but a consumer still needs to know who operates it, what data it receives, which tools it can call, how its behavior changed, whether the endpoint was compromised, and whether the current user may invoke it.
Discovery should return a candidate. Policy should decide whether the candidate may act.
A catalog record needs a trust envelope
A useful enterprise record should carry more than a name and description. Before automatic selection, I would require:
- Ownership: verified publisher domain, responsible team, and a reachable security contact.
- Identity: endpoint identity, supported authentication, and key-rotation behavior.
- Scope: input data classes, tool permissions, external effects, and prohibited uses.
- Version: immutable release identifier, change history, compatibility, and retirement date.
- Evidence: conformance results, security review, provenance, and last verification time.
- Operations: region, availability, rate limits, cost, logging, and incident status.
- Revocation: a fast way to remove a compromised or obsolete record from discovery and execution.
These requirements overlap with our review of WebMCP permission boundaries. A standardized description can make a tool easier to call; it should not make dangerous permission choices invisible.
Version 0.91 is a pilot signal, not a universal standard
The ARD repository publishes a specification, schemas, architecture decisions, and conformance tooling under Apache 2.0. That is stronger evidence than a slide deck. It is still version 0.91, with open issues and an explicit invitation for proposals.
AWS contributed feedback and is explaining how ARD could complement Agent Registry. That is meaningful vendor interest, not proof of multi-vendor production consensus. Teams should avoid designing a hard dependency around a draft without an adapter layer and an exit plan.
Run a read-only ARD pilot first
- Select ten low-risk internal resources already approved in an existing registry.
- Publish catalog metadata through one controlled domain without enabling automatic execution.
- Verify ownership, version, endpoint identity, and revocation for every record.
- Ask users and agents to find resources through both keyword and task descriptions.
- Measure discovery success, stale records, wrong matches, missing policy data, and time saved.
- Require a separate IAM and approval decision before any discovered resource is invoked.
- Break the catalog, revoke a record, rotate an endpoint, and confirm consumers fail closed.
This separates the value of discovery from the risk of autonomous selection. It also reveals which metadata your organization needs before it contributes to a shared schema.
The hard problem starts after a match
A discovery service can return three agents that claim to reconcile invoices. The runtime still needs to compare cost, data location, permissions, freshness, failure behavior, and evidence quality. An attacker may also try to manipulate descriptions so a malicious resource ranks for valuable tasks.
Catalog search therefore needs provenance-aware ranking, publisher verification, abuse reporting, and an explicit distinction between “found,” “curated,” and “authorized.” Our guide to agentic AI in plain English makes the same practical point: capability matters less than the permissions and consequences attached to it.
My verdict: standardize the map, keep the gate local
ARD identifies a real scaling problem. A federated discovery layer could reduce duplicate integrations and make internal agent infrastructure easier to reuse across clients and environments.
I would pilot v0.91 as a catalog protocol, not treat it as a trust protocol. Let ARD answer where a candidate resource is described. Keep identity, policy, approval, monitoring, and revocation at the execution boundary until the ecosystem proves much more.
Read the primary sources
- Inspect the canonical ARD v0.91 repository, schemas, and conformance tooling.
- Read AWS’s ARD and Agent Registry architecture explanation.
- Compare the discovery problem with enterprise MCP administration controls.
Checked August 31, 2026. Specification status and scope come from the canonical ARD repository. AWS product and federation claims come from AWS. Comparisons, trust requirements, and the pilot plan are Musthave.ai’s analysis.
