AgentCore Registry provides discovery for reusable agent interfaces, but the important behavior is not simple name resolution. The tested path was: create a registry, publish an A2A descriptor, move the record through approval, search approved records, resolve the Agent Card, and invoke the discovered agent.
That makes Registry a governed catalog for the agent graph. Hardcoded runtime ARNs are the visible pain. The deeper problem is uncontrolled reuse: which agents exist, which interface they expose, who approved them, and whether a caller is using the right version.
AWS Agent Registry gives that workflow a control plane: create a registry, publish a record, submit it for approval, approve it, then search only approved records. The record can describe an A2A agent, an MCP server, an agent skill, or a custom resource. The shape is intentionally catalog-first.
The thesis: agent discovery becomes a governance problem before it becomes a routing problem.
Hardcoded ARNs Are Only Part of the Problem
Hardcoded ARNs are easy to hate. They make demos brittle. They make account migration annoying. They make blue/green rollouts awkward. They also create the comforting illusion that the problem is only lookup.
It is not.
If a caller has a hardcoded ARN, at least it knows exactly what it is calling. A Registry-backed caller moves one level up: it asks for a capability, receives one or more approved records, resolves the interface, and invokes the selected agent. That adds power, but it also adds a new question:
Who gets to publish something discoverable?
That is where Registry differs from DNS. DNS does not ask whether a service is approved for reuse. Registry does. A record moves through lifecycle states before it becomes searchable. In our test, the A2A record moved from DRAFT to APPROVED before the search path could use it.
That lifecycle is the control point.
The Experiment
The verification ran two parallel paths: one against the preview API and one against the GA surface. Both proved the Registry-to-A2A integration path works end to end.
| Test | Result | What It Proved |
|---|---|---|
| Preview: Create, approve, search, resolve | PASS | A live A2A Agent Card can be published as an approved Registry record and discovered by search. |
| Preview: Invoke through discovered card | PASS | A caller can resolve the Agent Card from a Registry record and invoke the discovered agent through A2A without hardcoding the runtime ARN. |
| GA: Control and discovery APIs | PASS | The GA Registry APIs (agent-registry-control, agent-registry) create, approve, list, retrieve, and delete records. |
| GA: Registry-to-A2A invocation | PASS | A caller retrieved an A2A Agent Card from a GA Registry record and invoked the agent through A2A, then cleaned up the record and Registry. |
The target was a deployed A2A specialist agent exposed through an Agent Card:
- Name: enterprise support escalation specialist
- Protocol version: 0.3.0
- Function: assess support tickets, return severity, owner, SLA, and next steps
The Registry record was created as an A2A descriptor. The test captured:
- Registry status:
READY - Record after create:
DRAFT - Record after submit:
APPROVED - Search by name: returned the approved record
Then the search script selected the A2A record, parsed the Agent Card returned in the descriptor, and invoked the agent through the resolved card URL. The caller did not hardcode the specialist's runtime ARN in the delegation path.
The test case was deliberately operational: an enterprise customer had a double charge and production API access failure during quarter-end close. The discovered specialist returned:
P2 severity, Named TAM owner, 12-hour SLA.
That response matters less than the path. The important part is that the caller found an approved agent record, resolved its interface, and delegated over A2A.
What the Evidence Supports
The preview validation and GA revalidation support a narrower and more precise statement:
Registry is the catalog layer where agent interfaces become approved assets.
That is more than runtime address lookup. It changes what teams design around.
If Registry were only ARN lookup, the natural question would be, "Why not use an environment variable?" For a single caller and a single callee, that is still a good answer. A static env var is simpler, cheaper, and easier to debug.
Registry becomes worth the extra lookup when the organization needs reuse with control:
- Multiple callers need to discover the same agent.
- A platform team wants to publish approved A2A agents or MCP servers.
- Records need owners, versions, status, and audit history.
- Callers search by capability instead of importing another team's configuration.
- Agent interfaces are validated before they become reusable.
The Registry record is not only a pointer. It is metadata plus interface contract plus lifecycle state.
The Namespace Migration Is Part of the Contract
The migration is no longer future work. The current GA path uses the agent-registry-control client for lifecycle operations and the agent-registry client for discovery. This shift is not merely naming cleanup. It affects every script that creates, searches, or audits Registry resources, along with IAM policies, ARN formats, events, metrics, and quotas.
The two namespaces differ on every surface:
| Surface | Preview Namespace | GA Namespace |
|---|---|---|
| CLI/API |
bedrock-agentcore, bedrock-agentcore-control
|
agent-registry-control, agent-registry
|
| IAM actions | bedrock-agentcore:* |
agent-registry:* |
| ARNs | arn:aws:bedrock-agentcore:...:registry/... |
arn:aws:agent-registry:... |
| Events/metrics | Bedrock AgentCore sources | Agent Registry sources |
The practical rule: keep Registry client names, endpoint assumptions, and IAM action prefixes isolated in one layer. Do not scatter them through experiment code.
What the First Search Miss Showed
The first capability-style search did not return the record:
tier two escalation agent for enterprise billing tickets
The name search did:
enterprise support escalation specialist
That miss shows that catalog quality matters. Search is only as good as the record metadata, descriptor content, and query vocabulary. A Registry record with thin descriptions creates a weak discovery surface. A record with clear capability language gives the caller more to work with.
For production use, publishing an agent includes the same care as publishing an API:
- crisp description
- clear capability names
- versioning
- owner metadata
- examples of when to use it
- examples of when not to use it
Without that, Registry becomes a list of endpoints. With it, Registry becomes a catalog of approved agent capabilities.
What Registry Does Not Solve
Registry does not eliminate the rest of distributed-agent design.
It does not prove the agent is safe to call. Approval helps, but runtime behavior still needs observability and policy. It does not solve identity propagation across an A2A hop. The caller still needs the right permissions, and the callee still sees the authenticated caller according to the runtime auth model. It does not prevent delegation loops. Multi-agent systems still need hop budgets and loop controls.
It also does not remove the need to understand the interface. In our test, the caller resolved an A2A Agent Card and invoked the agent through that card. That worked because the callee exposed a real A2A surface. A plain HTTP runtime would need a custom record or another descriptor strategy.
This is the right boundary. Registry is not an orchestration layer. Its job is to make approved capabilities discoverable with enough metadata for a caller to decide what to do next.
So What
If you are building a multi-agent system, the question is not "How do agents find each other?"
The better question is: "Which agents are approved for reuse, and how does a caller know?"
For a small system, an environment variable is fine. For an agent graph that spans teams, accounts, or protocols, discovery needs governance. Registry gives that governance a place to live.
The next frontier is not lookup. It is trust: richer metadata, better search vocabulary, signed cards, policy-aware invocation, and clear ownership for every reusable agent capability.
That is where the agent graph starts to look less like a pile of runtimes and more like an operating model.
The open question I am holding: I have tested single-caller discovery paths. The multi-agent pattern — agents that invoke each other over A2A, each with its own identity and Registry record — is where the authorization model gets genuinely harder, and it is where I haven't yet wired the full lifecycle.
Part of a series working through Amazon Bedrock AgentCore by building on it. Start with The AgentCore Map, then Where AgentCore Sits in the Architecture. The mechanics behind Registry: AgentCore Runtime and Two Ways to Authorize an Agent Tool.
Top comments (0)