What the heck is ARD? Why Anthropic and OpenAI are not in it
Junjie Bu and Srinivas Krishnan
If you have spent any time around AI agents lately, you have probably tripped over a new three-letter acronym: ARD, short for Agentic Resource Discovery. On June 17, 2026, a coalition of some of the biggest names in enterprise software announced it as an open specification, and the tech press immediately noticed something odd about the guest list. The two companies most associated with frontier AI models and agents, Anthropic and OpenAI, were nowhere to be found. So what is ARD, who is behind it, and why are the two most famous AI labs sitting it out? Let's dig in.
What ARD actually is
Agentic Resource Discovery is an open specification for publishing, discovering, and verifying AI capabilities across the web. The capabilities it cares about are the building blocks of the emerging agentic ecosystem: tools, skills, MCP servers, APIs, and other agents. The core idea is that any organization can describe its capabilities in a standard machine-readable file, and any agent can then find and trust those capabilities at runtime instead of having them hardcoded in advance.
The architecture rests on two primitives. First, a catalog: an organization publishes a file (an ai-catalog.json) at a well-known path on its own domain, listing what it offers. Because the file lives on the organization's domain, ownership of that domain becomes the cryptographic anchor for identity and trust. Second, a registry: registries act like search engines for the agentic web. They crawl published catalogs, index them, and answer plain-language queries from agents with matching capabilities plus the metadata needed to verify the publisher before connecting. Once an agent picks something, ARD steps out of the way and hands off so the agent can connect directly using the resource's native protocol.
The spec is licensed under Apache 2.0 and built on the AI Catalog data model from a Linux Foundation working group, and it is currently a draft.
The background: why anyone wanted this
To understand the origin of ARD, it helps to remember the recent history of agent plumbing. In 2024 Anthropic introduced the Model Context Protocol (MCP), which gave agents a standard way to call tools. Around it grew companion ideas: Skills, a way for agents to consume instructions, and A2A, a way for agents to call other agents. All three solved the problem of how an agent talks to a capability. None of them solved the problem of how an agent finds the right capability in the first place.
The result, as the partners describe it, is an install-first, use-later world. A developer hardcodes an MCP server URL into a config file. A user manually connects a plugin and reuses it. That works fine for the handful of tools an agent touches every day, but the universe of available tools already numbers in the hundreds of thousands and grows daily. Any single agent can only see the tiny slice that has been explicitly wired into it. Microsoft's Ramanathan Guha put the problem bluntly: AI is only as capable as its wiring allows, and anything not wired in may as well not exist.
Both Google and Microsoft reach for the same historical analogy. Before search engines, the early web was full of pages nobody could find unless they appeared in a hand-curated directory like early Yahoo. Search engines lit the web up by building a discovery layer that could reach everything automatically and match it to what someone needed in the moment. The pitch for ARD is that the agentic ecosystem is in its pre-search-engine moment, and ARD is the missing discovery layer.
Who is behind it
ARD launched with eleven named contributors: Cisco, Databricks, GitHub, GoDaddy, Google, Hugging Face, Microsoft, NVIDIA, Salesforce, ServiceNow, and Snowflake. Google and Microsoft each published their own announcement, and several partners shipped working implementations on day one. GitHub launched Agent Finder, which lets Copilot discover and call MCP servers, skills, tools, and agents at runtime from a public or private registry. Hugging Face shipped a Discover Tool offering semantic search across thousands of Skills, ML applications, and MCP servers. Google is wiring ARD into the Agent Registry in its Gemini Enterprise Agent Platform, with native support promised in the coming months.
Look closely at that list and a pattern jumps out. These are infrastructure, cloud, data, and enterprise-software companies. They own the tools, the platforms, the data warehouses, and the developer surfaces that agents will want to reach. What they mostly do not do is build the frontier foundation models that sit at the center of consumer-facing AI assistants. That distinction turns out to be the whole story behind the missing names.
What ARD is for, and what it is not
It is worth being precise here, because ARD is easy to misread. ARD is for discovery and verification. It is the layer that sits before invocation and helps an agent answer three questions: where the right capability lives, which capability to actually use, and whether it is safe to connect. Hugging Face was explicit that ARD is a shared standard any company can implement independently, not a product and not a marketplace.
Just as important is what ARD is not. It is not a replacement for MCP, A2A, or APIs; those remain the protocols agents use to actually talk to a capability once it is found. It is not a single global database of every tool. The partners are emphatic that the goal is many discovery services, each defined by what it indexes, whom it serves, and how it ranks, and that getting different answers from different registries is the point rather than a flaw. And it is not a substitute for security. ARD does not replace authentication, authorization, governance, or organizational trust decisions; it returns ranked matches and verifiable identity, and then gets out of the way.
The model the partners keep invoking is DNS rather than ordinary web search. Like DNS, ARD is meant to allow local control while still participating in a larger shared system: an organization can resolve its private capabilities and public ones through the same mechanism, and join the broader network without giving up control over its own answer set. Whoever runs a discovery service controls what that service returns, which is precisely what makes the enterprise case compelling.
ARD vs MCP: how they differ
If you remember only one distinction from this whole post, make it this one: MCP is how an agent talks to a tool, while ARD is how an agent finds the tool to talk to in the first place. They operate at different layers and are designed to complement each other, not compete.
Think of it in terms of the web. MCP, A2A, and Skills are like HTTP: the protocols that let two parties actually exchange information once they are connected. ARD is like DNS and the search engine combined: the layer that lets you locate the right address and confirm you are talking to who you think you are, before any HTTP request is made. You would not pick one over the other, because they do different jobs. An agent uses ARD to discover that a transcription tool exists at some endpoint and to verify its publisher, and then it uses MCP to actually call that tool.
There is also a difference in what each one standardizes. MCP standardizes the shape of a single connection: how a client lists a server's tools, passes arguments, and receives results. ARD standardizes the shape of a public description and a query: how a publisher advertises its capabilities in a domain-hosted catalog, and how a registry answers an agent's plain-language request with verifiable matches. MCP makes a capability usable; ARD makes it findable. That is why the two protocols are showing up together in early implementations, such as GitHub's Agent Finder, which uses ARD to discover MCP servers and then hands the agent off to MCP to use them.
Is ARD the same as llms.txt?
Not at all, though the confusion is understandable because both are files you drop on your domain to make it friendlier to AI. The difference is what they are for. An llms.txt file is about content: it is a Markdown file at the root of your site that gives a model a clean, curated map of your pages and documentation, so that when an assistant reads about you it gets the good version instead of wrestling with your raw HTML, navigation, and ads. It helps a model understand your site.
ARD's ai-catalog.json is about capability. It is a structured JSON file, also at a well-known path, but instead of describing pages for a model to read, it advertises things an agent can do: MCP servers, A2A agents, Skills, and APIs, each with the endpoint and protocol needed to call it. It does not help a model understand your prose; it helps an agent find and invoke your tools, and it carries the domain-anchored identity that lets the agent verify who is offering them. One is a reading aid, the other is an action catalog.
Because they solve different problems, they happily coexist on the same domain. A company might ship an llms.txt so assistants describe its product accurately, and an ai-catalog.json so agents can discover and call its API. A loose way to remember it: llms.txt is closer to a sitemap for what models should read, while ARD is closer to a service directory for what agents can run. They are complementary, not competing, and neither replaces the other.
The benefits
The headline benefit is that agents can discover capabilities dynamically at runtime instead of needing everything pre-installed. That breaks the ceiling on what any one agent can do and lets a tool published last week, on the other side of the world, be found by an agent facing exactly that problem today, with no custom integration in between. A second benefit is context efficiency: rather than dumping every tool description into the model's limited context window, an agent searches and pulls in only what the task actually calls for, which is exactly the win GitHub points to with Agent Finder. A third is trust. Because catalogs are anchored to domain ownership and can carry cryptographically signed metadata, an agent can verify who published a capability and whether it has been tampered with before connecting. And because the whole thing is open and federated, no single company sits as a gatekeeper, so a search through one service can surface capabilities hosted by another.
A functional example: using ARD in about 40 lines
Because ARD is just well-known JSON files plus a plain HTTP search endpoint, you can build a working client without any SDK. The little Python app below does the full loop end to end: it asks a registry for a capability in plain language, verifies the publisher by checking that the capability is actually listed in that publisher's domain-hosted catalog, and then reports back what it would connect to. It uses Hugging Face's public Discover registry as a live example of an ARD discovery service.
"""Minimal Agentic Resource Discovery (ARD) client.
Flow: search a registry by intent -> read the publisher's
domain-hosted catalog -> verify the match -> report the endpoint.
"""
import sys
import urllib.parse
import requests
# A public ARD discovery service (Hugging Face's reference registry).
REGISTRY_SEARCH = "https://huggingface-hf-discover.hf.space/search"
def search(intent, page_size=3):
"""Ask the registry, in plain language, for matching capabilities."""
resp = requests.post(
REGISTRY_SEARCH,
json={"query": {"text": intent}, "pageSize": page_size},
timeout=30,
)
resp.raise_for_status()
return resp.json().get("results", [])
def fetch_catalog(domain):
"""Read the publisher's catalog from the ARD well-known path."""
url = f"https://{domain}/.well-known/ai-catalog.json"
resp = requests.get(url, timeout=30)
resp.raise_for_status()
return resp.json()
def verify(result):
"""Trust check: confirm the capability really lives in the
publisher's own domain catalog before we ever connect."""
endpoint = result.get("endpoint", "")
domain = urllib.parse.urlparse(endpoint).netloc
if not domain:
return False
catalog = fetch_catalog(domain)
listed = {c.get("endpoint") for c in catalog.get("capabilities", [])}
return endpoint in listed
def main(intent):
for r in search(intent):
name = r.get("name", "<unnamed>")
endpoint = r.get("endpoint", "<none>")
ok = "verified" if verify(r) else "UNVERIFIED - skip"
print(f"- {name}\n endpoint: {endpoint}\n {ok}")
if __name__ == "__main__":
query = " ".join(sys.argv[1:]) or "transcribe some audio"
print(f"Discovering capabilities for: {query!r}\n")
main(query)Run it with python ard_demo.py "transcribe some audio" and the client queries the registry, pulls back a few candidates, and prints each one with a verified or UNVERIFIED label depending on whether the capability is actually advertised in its publisher's own catalog. The whole thing is intentionally tiny, and that is the point: ARD's surface is small enough that the discover, verify, connect loop fits on a single screen, while leaving the heavy lifting of authentication, authorization, and the actual tool call to the resource's native protocol
Can't anyone just fake an ai-catalog.json?
This is the question that decides whether the whole scheme is trustworthy, so it is worth answering carefully. The short version: yes, a publisher can write whatever it wants in its own ai-catalog.json, but ARD is designed so that lying buys you much less than you might expect.
Start with what the design does prevent. The catalog has to live at a well-known path on a domain you actually control, and the verification step confirms two things cryptographically: that the catalog really came from the owner of that domain, and that it has not been tampered with in transit. That alone rules out the most dangerous attack, impersonation. You cannot publish a catalog under microsoft.com or stripe.com and borrow their reputation, because you do not own those domains. Whatever you advertise is bound to your own identity, and an agent can see exactly who is making the claim before it connects.
Now the honest caveat. Verification proves identity and integrity, not honesty or quality. Nothing in the cryptography stops you from listing a capability on your own domain that is exaggerated, broken, or outright malicious. ARD can confirm that the catalog genuinely belongs to evilcorp.example and was not altered; it cannot confirm that the tool evilcorp advertises as a friendly invoice parser is not quietly exfiltrating data. The example client in the previous section makes this concrete: its verify step only checks that a returned endpoint is actually listed in the publisher's own catalog. That defeats a registry or a man-in-the-middle inventing endpoints the publisher never offered, but it takes the publisher's self-description at face value.
So what actually keeps the ecosystem honest? The answer is the layers ARD deliberately leaves to others. Registries are curated and federated rather than open free-for-alls, so whoever runs one decides what gets indexed and how it ranks, and an enterprise registry typically only lists tools it has vetted and approved. Verified identity also makes reputation possible: because every claim is tied to a real, provable owner, bad actors can be flagged, delisted, and blocked, and a domain that ships malware once can be distrusted everywhere. And the final gate is invocation itself, which still runs over the capability's native protocol with its own authentication and authorization. In other words, ARD's job is to tell you who is making a claim and to prove they really made it; deciding whether to believe them, and whether to actually connect, remains a governance and security decision, which is exactly why the partners keep insisting ARD is not a substitute for trust.
A note on the risks
No honest write-up should skip the obvious concern. Letting agents find and connect to capabilities they discover on the web creates a new and valuable attack surface. Because trust is anchored to domain ownership, domains, DNS, deployment pipelines, and catalog files all become high-leverage targets; compromise one and you can potentially poison what agents discover. The spec leans on cryptographic verification, publisher metadata, and enterprise controls to mitigate this, but as ZDNET pointed out, ARD improves discovery and verification without eliminating the need for ordinary security hygiene like authorization, allowlists, signing, monitoring, and policy enforcement. The promise is real, and so is the new responsibility that comes with it.
The bottom line
ARD is a bet that the agentic web needs a discovery layer the same way the early web needed search, and a coalition of enterprise-software and infrastructure giants has decided to build it as an open, federated, DNS-like standard. The absence of Anthropic and OpenAI is not a footnote; it is a window into the central power struggle of this era of AI, between the companies that supply the capabilities and the companies that want to own the interface. Whether ARD becomes the default plumbing of the agentic web or just one more competing standard will depend on adoption, security, and whether the two biggest names eventually decide they would rather join than route around it.