Agent Discovery at Runtime With AWS Agent Registry

A small AI application can easily keep the capabilities and endpoints of a few agents in its own configuration. But when several teams publish agents, or multiple applications need the same information, that approach becomes harder to maintain. Every consumer-maintained list creates another place where metadata can become incomplete or stale, and keeping everything consistent takes significant developer effort.

AWS Agent Registry, which is part of Amazon Bedrock AgentCore, gives organizations a managed catalog for agents, Model Context Protocol (MCP) servers, skills, and other resources. Publishers add structured metadata, records pass through a configurable approval lifecycle, and builders or applications search the approved catalog for the resource they need.

Agent Registry manages records and publication state, then returns approved metadata through its discovery interfaces. Your agents and servers continue to run in their existing environments; Registry simply makes them discoverable while reducing the custom engineering required for publication and discovery when operating large agent platforms.

As of today, AWS Agent Registry is generally available, and as a launch partner, Caylent has worked with Agent Registry from early product validation in private beta, through two customer engagements. One engagement tested how agents and delivery pipelines could publish records, while the other used Agent Registry at runtime so an orchestrator could discover specialized agents dynamically before communicating with them. In this blog, we'll discuss where Agent Registry can simplify an agent platform, what teams must build around it, and which enterprise requirements still need separate design.

What AWS Agent Registry Manages for the Platform Team

Agent Registry combines structured records, controlled publication, and search. The registry record is the shared object between the team publishing a resource and the consumer trying to find it. For an agent, the record includes an Agent-to-Agent (A2A) Agent Card with its capabilities, skills, connection details, and supported communication. For an MCP server, it includes the server descriptor and the tools it exposes. Agent Registry can also represent skills and customer-defined resource metadata.

Agent Registry offers a managed publication and discovery path:

1. A publisher creates or updates a record, either directly or from supported metadata available at an HTTPS endpoint.
2. The record moves from draft through submission and approval. Only approved records are available for discovery.
3. Builders or applications search approved records through Agent Registry APIs or the registry-specific MCP endpoint.
4. The consumer interprets the returned metadata and uses a separately configured path to connect to the represented resource.

Discovery can occur at different points in the application lifecycle. A developer can search the catalog while assembling an application, a delivery workflow can retrieve metadata while configuring another service, or an orchestrator can search while handling a live request.

The approval lifecycle gives organizations a place to control what enters the discoverable catalog. A review process can apply criteria such as ownership, required metadata, security review, or validation results, and if you don't need any gates, you can enable automatic approval. In both cases, discovery operates only on approved records. This gives a common path through which publishers make capabilities available, and consumers can find them.

Publishing Agent Records Through Deployment Workflows

Publishing a new agent to the registry should be considered part of the delivery workflow, with completion only being ascertained once the agent is discoverable in Agent Registry. This means defining a clear owner for delivery, an update trigger, and a response when the record cannot be published successfully.

One option is to have the CI/CD pipeline create or update the Agent Registry record after deploying the agent. This lets the pipeline coordinate the deployed version, endpoint, and Agent Registry revision as a separate responsibility from publishing the agent. Another option is to let the agent’s deployment process publish the record, which keeps publication close to the resource, but the agent-side workflow needs permission to modify Agent Registry and a way to report failures.

The key point is that deployment, approval, and discovery are separate states, and teams need to manage all of them. A release can succeed while its corresponding record update fails, remains in draft, or is still waiting for approval. This situation becomes more complex when updating an existing resource, since editing an approved record in Agent Registry creates a new draft revision, and the previous approved revision remains discoverable until its replacement is approved. The existing listing is still available while the new draft revision is in review, meaning consumers may continue to receive the previous metadata after the updated resource has been deployed and before the record has been updated. Moreover, Agent Registry search is eventually consistent after approval, so there might be small delays even after a new revision is approved.

A complete publication workflow needs to verify that the intended revision is published, approved, and available through search. This prevents a successful deployment from silently leaving consumers with missing or outdated discovery metadata. Whatever process you build, it needs that end-to-end ownership.

Discovering Specialized Agents at Runtime

Runtime discovery is useful when an orchestrator must choose among a changing set of specialized agents. Instead of maintaining every agent and endpoint in its own configuration, the orchestrator can search the approved records in Agent Registry when it needs a particular capability.

Agent Registry supports keyword and semantic search through its data-plane APIs and its registry-specific MCP endpoint. The MCP endpoint gives MCP-compatible clients a standard way to search the catalog, but it does not proxy requests to the agents or MCP servers represented by the returned records. Agent Registry only handles discovery, not invocation.

During a request, the orchestrator searches for the required capability and evaluates the results. It can use the capabilities, skills, connection details, and supported communication described in each record to select an acceptable agent. It then uses that metadata to connect through a separately configured invocation path, such as A2A.

If the consumer agent executes a search on each request, it will always have access to the latest agents available in the registry without needing to maintain an internal configuration, but it will also suffer from increased latency due to the Agent Registry search always being part of every request. If your agents need to change less frequently, you can implement local caches on your orchestrator agents and other consumers, reducing latency at the expense of not always receiving the latest records.

Registry Discovery and Agent Execution

A successful search gives the consumer information about a resource. Then the consumer must connect to the target, authenticate, receive authorization, communicate through the required protocol, and handle the result.

Agent Registry only acts at the discovery boundary. Each registry uses AWS IAM or JSON Web Tokens (JWTs) for inbound discovery authorization. JWT authorization can use an OAuth/OpenID Connect-compatible identity provider such as Okta, while control-plane operations require IAM. These Agent Registry authorization controls determine who can search the registry or use its MCP endpoint. Authorization to invoke a discovered agent or server must be enforced separately.

The invocation path may use other Amazon Bedrock AgentCore capabilities such as Runtime, Gateway, Identity, and Policy for hosting, connectivity and invocation, workload credentials, and request-policy evaluation.

When to use AWS Agent Registry

AWS Agent Registry can replace significant custom work when multiple publishers and consumers need to reuse the same records, approval path, and discovery interface. Here are five questions to help you determine where Agent Registry can provide the most benefits:

1. Does one registry cover the required discovery scope? Each documented search request targets one registry. Agent Registry does not currently support native federation across registries, accounts, or Regions. A platform that needs a unified view across those boundaries must design that broader view and rely on other tools.
2. Does registry-level authorization match the access model? AWS IAM or JWT can protect discovery at the registry boundary. There are no per-record JWT entitlements, and permission to invoke a discovered resource is managed separately. Platforms with fine-grained access requirements must account for all three questions: 1. Who may search? 2. Which records may they see? 3. Which targets may they invoke?
3. How will publication coordinate with the invocation gateway? Record approval, Gateway attachment, target credentials, Policy configuration, and invocation are separate actions. If every discoverable capability must also be available through a governed gateway, delivery automation needs to coordinate those states and detect mismatches. This is not a reason to avoid Agent Registry, just additional work that is worth mentioning.
4. What happens when regional discovery is unavailable? Registry resources and endpoints are regional, with no managed cross-region replication or failover for registries. Multi-region architectures will require additional work.
5. Who owns metadata freshness and operational evidence? Refreshing an existing synchronized record requires an explicit trigger. The platform still needs owners and signals for stale records, failed refreshes, target health, discovery failures, and incident response.

An end-to-end evaluation should follow one agent across both sides of the lifecycle. Deploy the agent, publish its metadata, apply the intended approval process, search for the approved record, and invoke the target through the platform’s normal path. Then update the agent and its metadata. This exposes whether the publisher, approval process, search consumer, and invocation path match your expectations, and shows you where you need to add governance controls.

The evaluation should also exercise results other than a clean match. Search for a capability that returns several candidates and one that returns none. Observe the indexing interval after approval, then test a record with a stale endpoint or a target that rejects the caller. If Agent Registry will be queried during live requests, include discovery unavailability in the failure test. These checks will help you establish how the surrounding application must behave when discovery cannot produce an immediately usable target.

Additionally, consider the costs of your usage. Agent Registry charges $0.400 per 1,000 registry records, $0.20 per 1,000 Search API invocations, and $0.004 per 1,000 List and GET API invocations. The first 5,000 records, 1,000,000 Search API invocations, and 2,000,000 List and GET API invocations every month are free.

Conclusion

Agent Registry provides the most value when several publishers and consumers need changing metadata and a common discovery interface for agents, MCP servers, and skills. In that setting, its record model, approval lifecycle, and search capabilities significantly reduce custom catalog and endpoint-management work. New specialized agents can become discoverable through the publication workflow instead of requiring each consumer to maintain its own inventory.

Agent Registry can avoid custom work for record storage, publication state, search, and discovery interfaces. It can also add integration work if you already have an existing catalog that you intend to keep authoritative, or when publication needs significant coordination with identity and gateway systems. In all cases, measure total platform effort, including the code and services avoided, the delivery changes required, and the ongoing ownership of metadata and runtime dependencies.

How Caylent Can Help

As an AWS Agent Registry launch partner, Caylent can help organizations evaluate where AWS Agent Registry fits, integrate agent publication and runtime discovery with existing platforms, and validate the identity, gateway, observability, and resilience work required around it. Our teams bring hands-on experience from early product validation and customer engagements, so whether you're starting to build an agent platform or scaling an existing one, Caylent can help you move from a centralized catalog to a governed, scalable approach to agent discovery. Reach out to us today to explore how AWS Agent Registry can support your agent strategy.