Enterprise Agent Registry and Discovery Just Shipped. It Answers Two of Four Questions.
Enterprise agent registry and discovery shipped this month from AWS and a cross-vendor spec. Both tell you what exists. Neither says who vouches for it.
The first time I watched an agent reach for a capability nobody on the team had reviewed, it was not dramatic. It resolved a tool by name, called it, got a sensible answer, and moved on. The run succeeded. That is what made it uncomfortable. Enterprise agent registry and discovery is the layer that was supposed to make that moment governable, and this month three separate things shipped that all claim to be it.
None of them are wrong. I think they are collectively answering half the question, and the half they are skipping is the one that bites.
What actually shipped this month?
AWS moved Agent Registry to general availability: a private, governed catalog for agents, MCP servers, A2A agent cards, skills, and custom resources, with a deliberate split between a governance plane where curators approve things and a discovery plane where consumers only ever see what was approved. Records move through draft, pending, approved, rejected, deprecated, with EventBridge driving the workflow and CloudTrail keeping the audit trail. GA added CloudFormation, Terraform and CDK support, cross-account sharing through RAM, and organization-wide auto-detection of agents already running on AgentCore. That last one is the sleeper feature, and it exists because shadow agents are already a real inventory problem. AWS names Southwest, PepsiCo, Syngenta, Amdocs and Sony as adopters, which tells you the buyers are past the pilot argument. The full architecture writeup is on the AWS ML blog.
At the same time, a genuinely cross-vendor specification appeared for the same problem. Agentic Resource Discovery, authored by Junjie Bu at Google, R.V. Guha at Microsoft and Shaun Smith at Hugging Face under Apache 2.0, with contributions from NVIDIA, Salesforce and Databricks. The New Stack's writeup calls it DNS for agents. The mechanics are modest on purpose: JSON-LD over REST, one required POST /search endpoint that takes a task rather than a name, optional browse endpoints, and federation so an enterprise can keep an internal catalog private while routing queries out to trusted external registries. Version 0.91, governance not yet settled, W3C floated as a possible home.
And a company called AIR came out of stealth with $50 million across two seed rounds led by Sequoia and then Greenoaks, to vet the skills, plug-ins and MCP servers that agents pull in. Their number is the one I have not been able to put down: of the add-ons and skills they evaluate from public sources, they currently filter out about 27%.
Three announcements, one week, same layer. That is usually a sign the industry has agreed on where the gap is.
Why is discovery a separate problem from MCP?
Because MCP never claimed to solve it. MCP standardized how an agent calls a tool once it knows which tool to call. A2A standardized how two agents talk once they know about each other. Both assume the hard part already happened. I wrote a piece a couple of weeks ago on the four things that do not port when you move an agent between platforms, and the registry was the first of them. I expected that gap to stay open for another year. Instead three vendors filled it at once.
What changed is scale. Wiring MCP servers by hand works at twelve tools. At twelve hundred, spread across clouds, SaaS vendors and internal teams, an agent that can only use capabilities someone hardcoded into its config is not an agent, it is a script with a language model attached. Discovery is what makes the capability set dynamic. It is also what makes it unaudited, which is the trade nobody has priced yet.
There is a second reason this got urgent faster than people expected, and it comes from an unusually good piece of empirical work. A source-code study published this week (arXiv 2609.00006) dissected eleven production coding harnesses across roughly four million lines of code, including Claude Code, Codex CLI, Gemini CLI and OpenHands. Buried in it is a fact I did not expect: SKILL.md-style skills now lead MCP in adoption across those runtimes, nine of eleven versus eight of eleven. The fastest-growing way to extend an agent is a markdown file with executable instructions in it. Markdown files do not have a signing story. They barely have a versioning story.
What are the four answers a registry owes you?
Here is the frame I have started using, because it separates what these products do from what they are being bought to do. Before an agent uses a capability it did not have an hour ago, someone needs four answers, and they are not the same answer.
Existence. Does something that does this exist, and where does it live? This is the question ARD's POST /search was designed for, and the question AWS's discovery plane answers well. It is a real problem and it is now solved, or close to it.
Fitness. Of the several things that came back, which is the right one for this task? Notice that ARD's own authors are explicit that the DNS analogy breaks here: a search returns candidates, not one authoritative address, so every service sets its own trust and ranking rules. That is a reasonable thing for a young spec to punt on. It is not a reasonable thing for you to punt on, because ranking is where an attacker most wants to be.
Standing. Is this approved right now? AWS models this properly with a lifecycle and events, and it is the best-developed piece of any of these systems. But approval is a state that decays. A record approved in March, auto-detected from a running workload, and never revisited will keep serving the discovery plane in September with exactly the same confidence as one reviewed yesterday.
Provenance. Who wrote this, what has changed since anyone looked, and what does it pull in at runtime? Nothing shipping this month answers that, and it is the entire reason AIR raised fifty million dollars. Their argument, and I think it is correct, is that vetting is not an event. A skill that was safe last month can turn hostile because a dependency shifted or a maintainer's account was taken over, with no change to the record in your catalog. The academic work is converging on the same shape: a systems paper on agentic skills (arXiv 2608.29596) lays out a nine-stage lifecycle in which marketplaces, public registries and adversarial threats are treated as first-class architectural concerns rather than deployment details.
Existence and fitness are search problems. Standing and provenance are supply-chain problems, and we have been here before. We learned it with npm, with container base images, with browser extensions. Each time, the catalog arrived years before the vouching did, and each time the gap between them was where the incidents happened.
The Last-Verified Test
This is small on purpose, because the useful part is the answer and not the framework.
Open whatever inventory of agent capabilities you have, formal registry or spreadsheet, and pick one entry at random. Ask for two dates. When was it approved, and when was it last verified. Not reviewed by a human, necessarily. Last checked against its source, by anything.
If those two dates are the same date, you have a catalog. A catalog tells you what you decided once. A control plane tells you what is true now. The distance between them is the number of days an approved-and-forgotten capability has had to change underneath you, and on a supply chain where roughly a quarter of the public inventory already fails a basic vetting pass, that number is your actual exposure.
Most teams I ask cannot produce the second date at all, and that is the finding. It is not that the answer is bad. It is that the field does not exist.
What I would actually do this quarter
Adopt a registry. I am not arguing against any of these products and I would take the AWS one seriously if you are already on Bedrock, or ARD if you need something federated and vendor-neutral. The inventory problem is real and shadow agents are worse than shadow SaaS, because they act.
Then add the field the registry does not give you. A last-verified timestamp on every record, written by an automated check rather than a person, and a policy that says what happens when it goes stale. Expire, quarantine, or alert. Any of the three beats the current default, which is that nothing happens forever.
Then decide who owns fitness. If discovery returns three candidates and your agent takes the first, your ranking policy is whatever the registry's default sort happens to be. That is a decision you are making by not making it, and it is the cheapest thing on this list to fix.
The uncomfortable version is short. We are about to spend a year building the catalogs and calling it governance. The catalog is the easy half. Ask for the second date.
Related: Enterprise Agent Platform Lock-In on the four things that do not port, Enterprise MCP Architecture on what the stateless spec changed, and the pillar guides Multi-Agent Orchestration Architecture and Enterprise AI Agent Governance.
Sources: AWS Machine Learning Blog and AWS What's New on Agent Registry GA; The New Stack on the Agentic Resource Discovery specification; TechCrunch on AIR's $50M raise; arXiv 2609.00006 (harness engineering source-code study); arXiv 2608.29596 (systems foundation for agentic skills).
I write one of these every week on Build: NextGen AI. Subscribe and the next one comes to you.
Swipe the framework