An approval queue is now on the runtime path. AWS's own framing is that the problem has moved from building agents and tools to discovering and governing them [3], and that without a searchable catalog the default is to rebuild what already exists [13]. A record that has been registered but not cleared produces that same outcome, because the governance side retains a resource whatever its lifecycle state [5] while the consumer side is curated rather than comprehensive [7]. The tool exists, it is registered, and the developer who went looking for it gets nothing back.
Coverage is the second thing I would check before committing a platform team to this. Automatic population is bounded: it detects agents on AgentCore runtime and AgentCore gateways [17], and everything else arrives through the paths that shipped in preview, manual entry or URL-based record creation [14]. AWS says teams get complete visibility into their AI landscape [22]. For that sentence to describe your estate, your agents have to be running on AgentCore. Anything else is hand-authored, and hand-authored records are exactly where version drift and untracked capabilities came from in AWS's own problem statement [4].
The consumer view is built on summarised signals rather than raw governance data, surfacing compliance and security indicators framed for the decision to use a resource [10], with search by intent, as in find me a tool for ticket routing, or by exact name [9]. Both depend on fields your teams maintain. Custom metadata schemas are where that maintenance lands, with cost centre, data classification and SLA tier given as the examples [6]. The plane is also specified for high-throughput programmatic queries without hitting rate limits [8]. That is the right design goal for agents that search on every turn, but AWS does not publish a quota or a rate-limit figure to size against it.
The plumbing is the part I would standardise on first. Registries can be provisioned and managed as code through CloudFormation, Terraform and the CDK, and both registries and records accept tags for organisation, cost allocation and access control [15]. Resource Access Manager shares registries across accounts and supports organisation-wide registries [16]. That combination is what makes a catalog reviewable in the same pipeline as the rest of your infrastructure, which matters more to me than the console search does.
The footprint is five regions: US West (Oregon), US East (N. Virginia), Asia Pacific (Tokyo), Asia Pacific (Sydney) and Europe (Ireland) [19]. Two of the five sit in the US, and Ireland is the only European option [20]. Neither AWS post lists a price for any of it [25]. Tags are documented for cost allocation [15], which implies there is a bill to allocate somewhere.
My read, and my context is a mixed estate across several runtimes: the two-plane separation is sound engineering, and the as-code path is the reason to adopt now rather than wait for the roadmap. The ceiling on the value is how much of your fleet AWS can enumerate without a human typing.
