Publishing a Catalog Is Not the Same as Running a Registry

Everything this series has described so far, the shared capability contract, the knowledge graph, the health-checked registry, the identity and governance layer underneath all of it, assumes one organization is willing to build and operate that stack. There's a shortcut now on the table that looks like it makes the whole thing unnecessary: skip the registry, publish what you have, and let other agents find it. It's a real shortcut, and it only answers part of the question this series opened with.

The shortcut has a name and a real specification behind it. Agentic Resource Discovery, published on June 17, 2026 by a coalition of eleven companies including Google, Microsoft, GitHub, Hugging Face, Cisco, Databricks, and several others, describes exactly this pattern. An organization hosts a file called ai-catalog.json at a well-known path on its own domain, listing the tools, agents, and MCP servers it makes available. A registry crawls that file, indexes it, and answers another agent's plain-language discovery request. Once a capability is selected, the spec hands off entirely, and the requesting agent connects directly using the tool's own protocol, MCP, A2A, or a plain API. Domain ownership is the trust anchor; publishers can attach cryptographic metadata on top of that for production use. Several contributors shipped working implementations the same day the spec went public.

There's a genuine problem this solves that the rest of this series hasn't touched. Everything built so far assumes one identity and governance surface underneath every asset. That assumption holds inside an organization. It doesn't hold across one. Nobody is going to onboard a partner's agent into their own registry by hand, and nobody is going to let a partner write into their knowledge graph directly. Federation is the answer to a question the five-layer architecture in the last post can't answer on its own: how does an agent find a capability that lives on the other side of a boundary neither party controls.

That's also exactly where the pattern runs into the same three walls this series has already mapped, and the people who wrote the spec seem to know it. The contributors describe what they built as moving discovery into a search step that happens at runtime. Request-only is the honest name for that: an agent asks, a registry answers based on whatever was last crawled, and nothing more is guaranteed.

Start with the human-facing half from earlier in this series. A crawled catalog is built to be indexed by a registry, not browsed by a person, and it's made of however many publishers described their own capabilities, at whatever level of care each one chose. Getting from a pile of crawled entries to a person typing a plain-language question into a chat interface and getting one coherent answer back still takes someone normalizing what got crawled into a single shared contract. The federation layer hands over raw material for that contract. It isn't the contract itself.

The knowledge-graph half fares no better. A catalog entry is precisely the kind of self-reported, batch-published metadata that active metadata replaced years ago in enterprise data catalogs. Nothing in a crawl-and-index model corrects a description because usage revealed it was wrong, and nothing tracks the fact that a partner's invoice-reconciliation agent calls a model version that changed last month. What a registry hands back is a snapshot from whenever it last crawled the file, described however the publisher chose to describe it, unless something on the receiving end builds the enrichment layer that fixes both problems.

The registry half is where the gap is sharpest. The spec explicitly steps out of the way once a capability is chosen and hands the connection off to the tool's native protocol. That's the right design for a discovery step, but it means the file that just got crawled told an agent the endpoint exists and claims to do something. It didn't say whether the endpoint is healthy right now, which version is live, or whether the calling workflow is authorized to invoke it unattended. That's the same gap DNS left open in the earlier era of service discovery, moved out to the scale of the entire web, not one data center. A health check, a version pin, and an authorization decision still have to happen somewhere, and a static JSON file crawled on someone else's schedule is not that somewhere.

The clearest evidence that this gap is real comes from the spec's own authors. Google's contribution to the coalition is an open specification with no governance built in beyond domain ownership. Google's product built on top of that specification, Agent Registry inside its Gemini Enterprise Agent Platform, adds namespaced identity, enforced egress policy, and version pinning, the exact things the open spec leaves out. The company that helped write the federation standard didn't ship the standard alone and call it governed. It shipped a second, proprietary layer specifically to do the governing. If a capability resolved through a partner's catalog isn't logged into the same identity and audit surface as everything invoked internally, the one-identity-and-governance argument from the last post has a hole in it exactly the size of every external capability nobody is tracking.

None of that makes federation the wrong move. It makes it a partial one. Federation is the wire protocol for crossing a boundary neither side controls, the same role DNS still plays even after a service mesh sits on top of it. What it hands over is a feed into a graph, not a replacement for one. A crawled entry needs the same treatment this series has already described for an internal asset: verified against a shared capability contract, enriched with ownership and lineage even though it lives outside the namespace, health-checked and version-pinned before anything in a pipeline is allowed to call it unattended, and logged into the same governance surface as everything internal. Skip that step, and federation just moves the original discovery problem from a team boundary to a company boundary, the same static-catalog failure mode this series opened with, carrying a passport.

That pattern has already played out once, in a different field. Data mesh went through the identical argument over federated governance: pure domain autonomy without a small, non-negotiable set of shared standards produces fragmentation dressed up as federation, not the real thing. It only worked once domains agreed to emit into common contracts while keeping local control of everything else. The specification described here is quietly making the same bet: publish locally, but hold the schema, the trust model, and the identity layer in common. Federation itself is already shipping. Whether the bet pays off comes down to something narrower: whether enough of the ecosystem holds the shared contract still long enough for the crawl to mean something once it's aggregated.

Sources: Announcing the Agentic Resource Discovery specification | Google Developers Blog; Google, Microsoft Back Draft AI Agent Discovery Spec | Search Engine Journal; Agent Registry overview | Google Cloud Documentation; Agentic Resource Discovery launch | Hugging Face