How do your agents find out a new agent exists?

Your orchestrators can't call an agent they can't find. A governed registry makes approval and discoverability one decision, with pull and push paths on AWS.
Purpura, Michael

Global Sr. Solutions Architect, Private Equity
Published Nov 10, 2026
Last modified Nov 10, 2026
Suppose a team in your finance organization ships a refund-analytics agent on Tuesday. Which of the orchestrators already running in production, the agents that hand work to other agents, will know it exists by Wednesday, and who decided they should be allowed to call it?
Both questions get harder as agent fleets grow. In a survey of 1,050 IT leaders at enterprises with at least 1,000 employees (vendor-funded, self-reported), organizations reported an average of 12 agents and expected that number to climb 67% within two years. Half of those agents operate in isolated silos ( Salesforce ). An IBM Institute for Business Value study of 2,000 technology executives found that only 11% feel fully ready for the scale of agent deployment they expect over the next year ( IBM ).
I built and tested an answer to both questions on AWS Agent Registry and Amazon Bedrock AgentCore. This article shares the patterns that held up, with short code snippets where they help, and what it takes to run them safely.
What protocols don't coverProtocols such as Agent2Agent (A2A) and the Model Context Protocol (MCP) define how agents describe themselves and talk to each other. In A2A, each agent publishes an agent card, a JSON document that lists its name, its skills and how to reach it, so two agents that already know about each other can connect without custom work. Finding a new agent in the first place is a separate problem. A2A names a curated registry as the enterprise option and then notes that "The current A2A specification does not prescribe a standard API for curated registries" ( A2A agent discovery ).
That leaves each organization to solve discovery on its own while its agents already depend on each other. In Gravitee's October 2026 survey of 900 technology leaders (vendor-funded, self-reported), 97% said they run agents that call other agents ( Gravitee ). Without a shared catalog, the AWS launch post for AWS Agent Registry observes, "the default is to rebuild what already exists" ( AWS Machine Learning Blog ), which is the second refund-analytics agent in Figure 1. No survey I found measures how often that happens, so treat duplication as a likely cost rather than a measured one.
﻿
Figure 1: An orchestrator sees only the agents it was configured with, so a new agent goes unnoticed and another team builds it again
Make approval the moment an agent becomes findableMy view is that discovery should be a governance decision, because the step that lets an agent be found should be the same step that lets it be trusted. A governed registry puts both in one place. Teams publish their agents into it, a reviewer that AWS calls a curator approves or rejects each one, and other agents can find only the agents that were approved.
AWS Agent Registry works this way. It stores each agent as a record that carries the agent card, and the record moves from Draft to Pending Approval to Approved, while a curator can also reject it or later deprecate it ( AWS Agent Registry ,  EventBridge notifications ). Only approved records are visible to search, and the launch post describes the discovery view as one where "only records approved by an admin or curator appear here" ( AWS Machine Learning Blog ). My tests showed how strict this is, because reading my own orchestrator's record before approval returned a not-found error, even from the account that published it.
Editing an approved record "sends it back to DRAFT state, restarting the submission process" ( AWS Machine Learning Blog ), so a publisher can't change a card and keep it findable without a fresh review. You design the review itself, since the registry announces each submission with a  Registry Record State changed to Pending Approval  event that can start your existing approval workflow ( notifications for pending approvals ). Consider giving the publisher and approver roles to different people, so that no one person can admit an agent alone.
﻿
Figure 2: Only an approved record sits above the visibility line, and editing or deprecating it moves the record back below
How agents find approved agentsWith pull, an agent searches the registry when a task needs a capability it doesn't have, much as client-side service discovery lets a microservice look up an endpoint instead of keeping a fixed list. The search call,   SearchDiscoverableRegistryRecords  , takes a plain-language query and returns only approved records, each with its agent card included.
registry = boto3.client("agent-registry")
records = registry.search_discoverable_registry_records(
    registryIds=[registry_id],
    searchQuery="analyze refund trends",
    maxResults=5,
)["registryRecords"]
card = json.loads(records[0]["descriptors"]["a2aAgentCard"]["data"])
Make pull the default, since an agent's capabilities rarely change from hour to hour. The Agentic AI Lens of the AWS Well-Architected Framework recommends caching that kind of metadata for periods that are "typically hours, not seconds" ( AGENTCOST06-BP01 ), which keeps a cached search fresh enough for most lookups.
With push, the registry tells waiting agents that something new has arrived. When a curator approves a record, the registry publishes an Amazon EventBridge event from the source  aws.agent-registry , and the event carries only the record ID and the registry ID ( EventBridge notifications ). A rule that reacts to approvals needs two fields.
{
  "source": ["aws.agent-registry"],
  "detail-type": ["Registry Record State changed to Approved"]
}
Match the Approved event and nothing earlier. Pending Approval emits an event too, although that one belongs to your review workflow, and an agent that reacts to it would treat an unreviewed agent as available.
In the pattern I tested, the Approved event flows through an Amazon Simple Queue Service (Amazon SQS) queue to an AWS Lambda function with no logic of its own. The function passes the two IDs to a standing orchestrator on Amazon Bedrock AgentCore Runtime. The orchestrator re-reads the approved record from the registry and acts on that record rather than on the event. EventBridge and SQS can deliver the same event more than once, and the SQS documentation says to "Design your applications to be idempotent" ( Amazon SQS at-least-once delivery ), so the orchestrator records each record ID in Amazon DynamoDB before it acts.
Push is worth these extra parts for rare events that shouldn't wait for the next cached search, such as a new approval or a deprecation. Figure 3 shows how both paths end at the same call to the new agent.
﻿
Figure 3: Pull and push on AWS share one approval gate and one invoke path
Finding an agent isn't permission to call itApproval tells you the organization reviewed an agent's description, although it doesn't tell you whether a particular caller should reach that agent. The registry also stores each record as the publisher wrote it and "doesn't verify the packages, repositories, or endpoints that records reference" ( discovering the registry ). The Agentic AI Lens asks for every coordination step, including reading an agent card, to be "attributable to a verified agent identity and recorded for investigation" ( AGENTSEC06 ). Three layers protect each call in this pattern, and each one stops a different failure.
The approval gate described earlier forms the first layer, keeping unreviewed agents out of search results and out of the event stream.
The calling agent adds the second layer, an account check. Every AgentCore Runtime agent in a Region is reached through the same AWS service address, so the address in a card says nothing about who owns the agent. The card also holds the agent's Amazon Resource Name (ARN), the AWS identifier that includes the owning account, and the orchestrator refuses to call any agent whose account isn't on a list in its own configuration.
The third layer sits on the agent being called, which I'll call the callee. AgentCore Runtime agents can be invoked only through the   InvokeAgentRuntime   API, which requires AWS Signature Version 4 (SigV4) request signing ( SigV4 ), so the callee can carry a resource-based policy that decides which roles may call it ( resource-based policies ). I allowed the orchestrator's role and denied every other principal, meaning any other AWS identity, with one statement.
{
  "Sid": "DenyOtherPrincipals",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "<runtime ARN, or its DEFAULT endpoint ARN>",
  "Condition": {"ArnNotEquals": {"aws:PrincipalArn": ["<consumer role ARN>"]}}
}
Attach the policy to both the runtime and its default endpoint ( {runtimeArn}/runtime-endpoint/DEFAULT ). When I attached it to the runtime alone, every call was denied with nothing in the error to explain why.
The orchestrator also keeps arrival events away from its language model. Each approval reaches it as a small structured message with exactly the two IDs, and plain code handles it by re-reading the record, so nothing a publisher wrote in a card can steer the decision to call. Apply the same caution on the pull path, where a model choosing among search results reads each card's description, and consider selecting agents on fields your curators control rather than on that free text.
Card signing is the layer I left out of my tests. The Open Worldwide Application Security Project (OWASP) Top 10 for Agentic Applications recommends signed agent cards to guard against forged ones ( OWASP ). Inside one organization, an approval gate with separate publisher and approver roles already records who vouched for each card. Consider adding signing when cards come from outside the organization that approves them, such as a partner's agents or another business unit's registry.
﻿
Figure 4: Three trust layers around the invoke call, with card signing as an optional outer layer for cards from outside your organization
Push acts on its own, so match autonomy to consequenceOn the pull path, an agent calls another agent as part of a task a person gave it. On the push path, the orchestrator calls the new agent as soon as it's approved, before anyone asked. The AWS Agentic AI Security Scoping Matrix places systems that a person starts, and that then act without further approvals, in Scope 3. It places systems "capable of invoking their own activities based on environmental factors, learned patterns, or predetermined conditions" in Scope 4, its highest level of autonomy ( Agentic AI Security Scoping Matrix ). Push with automatic calls sits between the two, since a human approval starts the chain while the call itself happens on a predetermined condition.
Plan for the controls the matrix names for Scope 4, which center on monitoring, anomaly detection and automated containment, and include a way to switch automatic calls off. On AWS, AgentCore Observability stores each agent's metrics, traces and logs in Amazon CloudWatch ( AgentCore Observability ), which gives you a baseline for alarms, and disabling the EventBridge rule stops automatic calls without redeploying either agent.
AGENTREL02-BP05, another best practice in the Agentic AI Lens, sorts actions into three tiers by how reversible they are ( AGENTREL02-BP05 ). Low-risk actions run on their own, medium-risk actions proceed while an operator is aware of them, and irreversible actions wait for explicit human approval. Consider assigning a tier to each capability rather than to each agent. A peer that answers questions or reads data can be called automatically, and a medium-consequence peer can be called after an Amazon Simple Notification Service (Amazon SNS) message alerts an operator. A peer that moves money or changes production state should wait for a person before its first call.
Decide the tier in code or policy, from fields your curators control. The Agentic AI Lens warns against letting a model judge risk when it is "exposed to the same untrusted content as the request it is evaluating" ( AGENTSEC04 ), and an agent card's description is exactly that kind of content. For the same reason, keep auto-approval out of any registry that feeds the push path, since auto-approved records "skip human review and become discoverable as soon as they're submitted" ( key capabilities ) and would remove the one human decision the chain depends on.
﻿
Figure 5: Oversight tiers set per capability by how reversible its actions are
Keep the registry currentA registry stays useful only while its records match the agents that are running. Gartner's guidance on agent sprawl, the uncontrolled growth of agents across an organization, includes reviewing and retiring redundant agents ( Gartner ). Yet fewer than one in 10 organizations in Gravitee's October survey had a named person formally accountable for what their agents do ( Gravitee ). Give every record a named owner and a review date, and deprecate records whose agents no longer run.
Deprecation hides a record from search, so that it "can no longer be found by builders" ( key capabilities ), although it doesn't revoke access to the agent. An orchestrator that cached the card can keep calling the agent, and the callee's resource policy still allows it. Consider subscribing consumers to the  Registry Record State changed to Deprecated  event so that they drop the card, and remove the caller from the callee's resource policy when access needs to end.
When you don't need a registryIf your agents mainly call each other as tools, you may not need a registry yet. The Agentic AI Lens notes that discovery through Amazon Bedrock AgentCore Gateway "removes the need for custom registry infrastructure in many scenarios" when agents interact mainly through tool calls ( AGENTCOST06-BP01 ). A single team with a small, fixed set of agents can also manage with configuration files. A registry becomes worth running once several teams publish agents that work with each other as peers, or once you need a record of who approved each one.
Questions to ask before you build itWhich of your agents call each other as tools behind one gateway, and which need to find peers they weren't configured with?
Who approves a record, against which criteria, and is that person different from the one who published it?
Which capabilities are reversible enough to call automatically, and who makes that call?
How does each callee decide which callers it accepts, separately from the registry?
When you deprecate a record, how do cached consumers find out, and who removes their access?
Do any agent cards come from outside the organization that approves them, and should those be signed?
About the authorMichael Purpura is a Senior Global Private Equity Solutions Architect at AWS. He works with private equity firms and their portfolio companies to structure AI adoption around measurable business outcomes.