On June 17, 2026, a quiet specification landed that most teams have not read yet. Google and around eleven partners shipped Agentic Resource Discovery, governed under the Linux Foundation. It is not a new model. It is not a new runtime. It is a discovery layer - the piece that was obviously missing once you see it.
Here is the gap it fills. MCP gives agents a standard way to call tools. Skills give agents a way of consuming instructions. A2A gives agents a way to call other agents. All three assume the user already knows which tool, instruction, or agent they need. The user is still responsible for discovering, integrating, and maintaining those capabilities. That last sentence is the honest description of most enterprise agent stacks right now: a human has manually wired every connection, and when something changes, a human goes back in to fix it.
ARD replaces that with a publish-crawl-search-verify-connect loop. The model is simple enough to fit on a sticky note.
What the ai-catalog.json spec actually requires
The specification defines two primitives: a static ai-catalog.json manifest hosted at a well-known path on an organization's domain, and a registry API that crawls and indexes published catalogs and returns ranked matches to natural-language discovery queries.
You publish it at /.well-known/ai-catalog.json on your domain. Each entry has an identifier, a type, and a link to the capability the agent can connect to.
ARD sits entirely before invocation - it finds the right resource; the resource is then called through its own native protocol (MCP, A2A, OpenAPI, etc.). It is explicitly not a replacement for MCP, A2A, or Skills. Think of it this way: MCP is the wiring standard for an outlet; ARD is the electrician's map that tells you which outlets exist in the building and what they power.
A resource publisher creates a standard manifest that describes what the agent does, what tasks it handles, and how to invoke it. The manifest lives on the publisher's own domain. Registries crawl those manifests. Clients query the discovery service with natural-language text and optional filters. The service returns ranked entries with schemas and endpoints. The client connects directly to the selected resource over its native protocol (MCP, A2A, REST).
The ARD model is federated - organizations can run their own registries, and registries can cross-reference each other without a central catalog. You are not handing capability inventory to a third-party silo.
Why agent tool discovery has been the quiet failure mode
The coordination problem in multi-agent systems is real and documented. In 2026, the practical team size for agentic systems is typically three or four agents, due to rapidly increasing coordination overhead. Part of that overhead is not logic - it is plumbing. Every capability your agent needs has been pre-connected by a developer who looked it up manually, evaluated trust manually, and hard-coded a reference. The moment the tool changes its endpoint or auth scheme, the agent breaks silently.
Today, a developer or IT admin has to manually find an agent, MCP server, API, workflow, or other agentic resource, judge whether it's useful and trustworthy, connect it to the AI client, and keep that wiring current. That worked when there were just a handful of well-known agentic resources available. Anthropic's MCP SDK is now at 97 million monthly downloads. The number of MCP servers a given team might want to consider has outgrown the manual-wiring model entirely.
ARD does not solve trust by itself.
By adding a cryptographic signature to the Agent Card, a receiving agent can verify that the card was actually issued by the domain owner. Without this, an attacker could stand up a fake Agent Card and redirect other agents into a card forgery attack.
ARD extends the same idea to the discovery step - the verify stage in the publish-crawl-search-verify-connect pipeline is the one that earns the right to act on what you find. A teammate like Beagle, embedded in Slack and Teams, faces exactly this sequence every time it decides which tool to call on a team's behalf.
How ARD fits with MCP and A2A (and what is still open)
A2A sits alongside MCP (which handles agent-to-tool access) to form the interoperability stack for multi-agent systems. ARD is now the third layer of that stack, sitting upstream of both. The spec includes connection guides for Claude, ChatGPT, GitHub Copilot, Microsoft Copilot, and Gemini as ARD clients - it is a draft specification developed by contributors from Microsoft, Google, GoDaddy, Hugging Face, and others.
Hugging Face launched a Discover Tool that wraps the Hub's semantic search over Spaces, Skills, and MCP servers in the ARD envelope, making thousands of capabilities searchable via the specification. That is the first large-scale implementation. It is early; the field naming in the base spec is still converging. But the direction is clear.
What is still open: federation trust between registries (who vouches for whom), how staleness is handled when a published catalog drifts from what a server actually exposes, and whether the major IDEs adopt ARD-aware tooling the way they adopted MCP. Those are real gaps. ARD is an early-stage, open specification. Some details, including field naming, are still converging between the base specification and the ARD working group.
The practical position for a team building agents today is this: publish your ai-catalog.json now, even if no registry indexes it yet. The cost is two hours and a JSON file. The alternative - being undiscoverable to agents that will be querying registries in six months - has a much higher cost to fix retroactively.
See how Beagle connects to the tools your team already uses on the integrations page, or read about the governance side in Give Your AI Agent Only the Permissions It Can Justify.