The discovery layer the agentic web was missing

I run agents in production, and the failure mode that costs me the most time is not a model being wrong. It is a model not knowing what it is allowed to reach for. An agent resolving a live incident might need to query an observability backend, search internal docs, read deployment history, open a ticket, and hand part of the problem to a specialized troubleshooting agent. Every one of those capabilities exists. The problem is that each lives behind its own registry, its own auth, its own framework, and there is no standard way for the agent to find them, choose between them, and trust them before it connects.

That gap — call it the discovery layer — is what Google's new Agentic Resource Discovery specification (ARD) is trying to fill. It is worth reading closely, because the design choices are conservative in the way durable infrastructure usually is.

Three questions, no standard answer

The spec frames the problem as three questions an agent needs answered before it can use a capability it does not already have wired in: where does the right capability live, which one should it actually use, and how does it verify the thing is safe to connect to. Inside a single platform you can answer all three with a proprietary registry. Across organizational boundaries you cannot — and that boundary is exactly where the interesting agent work is heading.

Today every vendor solves this internally and incompatibly. Each custom registry is a silo; an agent that can search one cannot search another. ARD's claim is modest and correct: the missing piece is not another registry, it is a standard for publishing and discovering capabilities that any registry, agent, or framework can speak.

Two primitives: catalogs and registries

The whole specification rests on two objects. A catalog is a file an organization hosts on its own domain, at a well-known path, named ai-catalog.json. It describes the capabilities that organization publishes — MCP servers, A2A agents, OpenAPI tools, even nested catalogs that point elsewhere. A registry is a search engine for those catalogs: it crawls them, indexes their contents, and answers discovery requests, returning matching capabilities along with the metadata needed to verify the publisher.

The two primitives in motion: catalogs are published under a domain, registries index them, and discovery hands off to the capability's native protocol.

The runtime flow is four steps. A provider publishes its catalog. A client either asks a registry in plain language — find me something that can read deployment history — or, if it already knows the partner, fetches that partner's catalog directly and skips search entirely. The discovery layer hands back verifiable trust metadata. The agent confirms the publisher's identity, then connects straight to the endpoint over its native protocol. All of it happens at runtime: the agent loads a capability it had never seen, uses it, and returns the result.

It reuses the web's trust model instead of inventing one

The choice I find most defensible is where ARD anchors identity. Because a catalog is hosted under the organization's own domain, ownership of that domain becomes the cryptographic root of trust. You already prove you control your domain every time you serve TLS; ARD leans on that existing fact rather than standing up a new global identity authority that everyone would first have to adopt and then agree to trust.

That is the same bet the open web made, and the parallels are close enough to be a map.

ARD reuses the open web's trust roots rather than inventing new ones.

A domain is the catalog's identity. The ai-catalog.json at a well-known path plays the role robots.txt and sitemaps play for crawlers — a predictable place to look. Registries are the search engines. The trust manifest is the TLS certificate of this world: proof the publisher is who it claims to be. And the call the agent finally makes — over MCP, A2A, or OpenAPI — is the hyperlink you follow once you trust the destination. None of these are new ideas, and that is the point. Infrastructure that lasts tends to reuse trust roots people already have rather than ask them for new ones.

Discovery is deliberately not invocation

Here is the detail practitioners should notice: ARD hands off and gets out of the way. It does not proxy your traffic, wrap your tools, or define a transport. Once the agent holds verified trust metadata, it talks to the capability over that capability's own protocol. ARD is the index and the trust check; it is never in the data path.

That separation matters. The ecosystem already has transport and interaction protocols — MCP for tools, A2A for agent-to-agent work. ARD does not compete with them; it sits one layer up and tells you which endpoint to point them at. A discovery layer that also tried to be the runtime would couple everyone to one vendor's plumbing — which is exactly the siloing ARD is meant to dissolve.

Where the hard problems still live

I would not oversell what a specification can do. Three things are unsolved by construction, and they are the things that will decide whether this works in practice.

First, which capability should I use is a ranking and quality problem, and ARD hands it to registries. Standardizing how capabilities are published does not tell an agent that one observability tool is reliable and another is abandonware. Whoever runs a good registry — with reputation, usage signals, real curation — holds most of the value, the same way search, not HTML, was where the open web's power concentrated.

Second, an open publishing standard is an open spam surface. Capability squatting, misleading catalog descriptions, and low-quality entries are inevitable. The cryptographic layer proves who published something, not whether it is any good or safe to run. Those are different guarantees, and only the first is in the spec.

Third, inside an enterprise the governance is the product. Google's own Agent Registry, part of its Gemini Enterprise Agent Platform, adds the parts the bare spec leaves out: namespaced URNs, egress policies that bound what agents may reach, version pinning, and identity verification against the trust manifest for compliance regimes like HIPAA. That is the unglamorous machinery that decides whether a security team ever lets an agent discover and connect to something at runtime. The spec is necessary; on its own it is nowhere near sufficient.

What I take from it

ARD is licensed under Apache 2.0 and built on the Linux Foundation's AI Catalog data model — the right shape for something meant to be neutral infrastructure rather than one company's product. If I were publishing capabilities today, I would host a catalog now; it costs almost nothing and makes my tools findable by anything that learns to read the format. If I were consuming, I would treat the trust manifest as a floor, not a ceiling — verify identity through ARD, then apply my own policy about what I will actually let an agent invoke.

The honest framing is that ARD solves the part that genuinely needed a standard — finding and verifying capabilities across organizations — and leaves the parts that need judgment to the people running registries and the teams setting policy. That is the correct division of labor. The agentic web needed a discovery layer before it needed anything fancier, and this is a credible one.