- AWS describes an optional pattern: with Agent Registry, an AI agent searches a catalog of approved tools at runtime instead of using tools written into its code.
- For teams that adopt it, oversight moves from code review to catalog approval, and the quality of each tool's description affects which tool is chosen.
- Leaders of such teams should ask who approves records, where credentials live, and whether each agent's tool choices are logged.
Who decides what an agent can do?
In one common way to build an AI agent, engineers write each tool into the agent's code, test it and ship it. The list of what the agent can do is then a list a team can read and review. AWS contrasts this with a different approach, and the contrast matters for anyone who signs off on agent projects.
In a post published October 20, AWS describes a pattern for teams that choose to adopt its Agent Registry. In AWS's sample, the orchestrator starts with no built-in knowledge of tools. When a user asks for something, it searches a catalog and uses what it finds. This shows that, under this pattern, much of the decision about tools moves from the code to the catalog.
What AWS published
Agent Registry is a hosted AWS catalog. Publishers register three kinds of entries in it: MCP servers, other agents and agent skills. MCP, short for Model Context Protocol, is a shared standard that lets an AI model call outside tools. Each entry carries a description that software can search, and the agent searches those descriptions in plain language.
AWS says the fixed-list approach copes with a few tools, strains once the count reaches a few dozen, and breaks down further beyond that. It says enterprise systems expose hundreds of internal APIs. In those systems, the model can spend more effort telling tool names apart than reasoning about the request. Each new tool also needs a code change and a redeploy. These are AWS's claims from its own enterprise work. The post gives no measurements.
How the loop works
AWS calls the pattern Discover, Instantiate, Execute. The loop begins when the main agent, called the orchestrator, turns a user's request into a plain-language search of the catalog. The Registry returns matching records. Each has a name, description, version and a descriptor, which is a technical file explaining how to connect to the tool.
Next, the orchestrator builds a connection for each record, based on the descriptor type. Then it creates a short-lived inner agent that holds only those discovered tools. That agent answers the request and is then torn down. The next request starts with a fresh search.
AWS stresses that search results do not include the credentials needed to call a tool. The application must obtain those separately. In the sample, an OAuth token comes from Amazon Cognito for one tool path. Calls to agents on AgentCore runtime are signed with the caller's AWS credentials.
Where oversight sits under this pattern
Two controls carry more weight here. The first is approval. With manual approval switched on, a new record moves from DRAFT to PENDING_APPROVAL to APPROVED. Only approved records appear in search. AWS says IAM permissions can separate the people who publish from the people who approve.
The second is the description. In one demo, a return-and-refund query found a Customer Support Agent because its description captured that intent. Those words were not in its name. AWS advises writing descriptions that distinguish a capability from neighboring records. The text a publisher writes helps decide which tool an agent picks.
This is the shift for leaders on teams that adopt the pattern. A code review no longer covers the tool list. A catalog workflow does. A loose approval step or a vague description can then affect what the agent does in production.
Limits AWS states
AWS is open about the limits. It calls the return-and-refund result a demo, not proof that ranking improves as a catalog grows. It says search quality depends on descriptions, query design and evaluation.
AWS does not claim every project needs this design. It names two cases where fixed wiring may still fit better. One is a short tool list that seldom changes, where fixed wiring may be simpler. The other is a pipeline that always runs the same steps in the same order, which may be easier to trace as a set sequence.
On monitoring, the sample grants CloudWatch Logs permissions. It does not create custom metrics or dashboards. AWS says production teams must define their own traces, logs and alerts.
Questions to put to your team
If your team is considering a catalog like this, start with approval. Who can approve a record, and are they different people from those who publish it? Does a security review or CI check sit inside the approval step, as AWS says it can?
Next, ask where credentials live and whether they stay outside the catalog. Then ask whether you can see which records an agent selected for a given request. AWS lists selected record identifiers and downstream outcomes as useful signals.
Finally, test search with your own catalog and your own queries. AWS gives the same advice.
The lesson is plain. Where agents choose their own tools, the catalog is the first place to decide what they may do. Credentials and IAM permissions are separate controls that sit beside it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS.
