Standards

ARD is now an IETF Internet-Draft

2 November 2026 · 8 min read

On 30 October 2026 Agentic Resource Discovery was submitted to the IETF as three Internet-Drafts, under the name Agent Resource Discovery. The format did not change. How a manifest is served did: the drafts give it a media type of its own, and a client may ignore a manifest without it. We checked every domain we know publishes one. Of 179 serving /.well-known/ard.json, none used it.

What was submitted

On 30 October 2026 three Internet-Drafts were submitted to the IETF's DAWN effort (Discovery of Agents With Names), by authors at Google and Ericsson. Together they restate the ARD specification as IETF text and split it into three parts.

These are individual drafts, version 00, valid until 3 May 2027. They are not an RFC and not yet working group documents. The registration interface, how a publisher pushes entries into a registry, is left to a later document.

One protocol, two names

The drafts call it Agent Resource Discovery. The specification site still says Agentic Resource Discovery. They are the same thing: the same /.well-known/ard.json path, the same urn:air:<publisher>:<namespace>:<name> identifiers, the same entry fields and the same JSON-LD base context at agenticresourcediscovery.org/context/v1. A manifest valid under v0.91 of the specification is still a manifest under the drafts.

Nothing you published is invalid. Two things about how it is served now matter more than they did.

What changed for publishers

• The media type. The discovery draft registers application/ard+json for a manifest, and the initial contact draft says a response to the well-known URI with any other media type has the outcome no manifest. A client written to the draft is allowed to ignore a manifest served as application/json.
• A link from your homepage. A publisher SHOULD answer HEAD / with Link: </.well-known/ard.json>; rel="ard". The HTML <link rel="ard"> tag still works for crawlers that fetch the page.
• Optional DNS. An SVCB record at _index._agents.<domain> names a host that serves the manifest, and DNS-SD under _ard._tcp can enumerate several manifests. On a local network, clients browse _ard._tcp.local. over Multicast DNS.
• One redirect, no more. A client follows at most one HTTP redirect and one DNS alias. A chain of two ends the attempt.

What changed for registries

• The url of a registry's own application/ai-registry+json entry is its base URL. Clients append /search, /explore or /agents. The url of a referral in a search response is the opposite: a complete search endpoint, used as it is.
• Errors SHOULD be RFC 9457 Problem Details with a code: INVALID_ARGUMENT, UNAUTHENTICATED, PERMISSION_DENIED, NOT_FOUND, RATE_LIMIT_EXCEEDED, INTERNAL_ERROR, NOT_IMPLEMENTED.
• Federation keeps its three modes (auto, referrals, none) and adds a rule: registries MUST bound how far a query travels, three hops by default.
• Search pages with pageSize (up to 100), pageToken and nextPageToken, and every result carries a score from 0 to 100 and a source.

We measured who is ready

Our crawler knows 460 domains that have published an ARD manifest. On 2 November 2026 we requested each one again and checked it against the new text.

These numbers are now re-measured every day on the ARD IETF readiness tracker, with the data as JSON and CSV.

Not one manifest in the sample, ours included, was served with the media type the draft defines. The nine that were not plain JSON used names of their own: application/ai-catalog+json eight times and application/ard-manifest+json once. The SVCB records mostly come from the DNS-AID proposal and point at agent endpoints rather than at a manifest, which is why only 14 of 50 lead to one. Seven apparent DNS-SD records were wildcard answers, not real ones, so the count is zero.

Check your own domain

curl -sI https://example.com/.well-known/ard.json | grep -i content-type
# want: content-type: application/ard+json

curl -sI https://example.com/ | grep -i '^link'
# want: link: </.well-known/ard.json>; rel="ard"

dig +short _index._agents.example.com TYPE64
# optional: 1 example.com. alpn="h2"

On nginx, the media type and the header are two lines each:

location = /.well-known/ard.json {
    types { } default_type application/ard+json;
}
location = / {
    add_header Link '</.well-known/ard.json>; rel="ard"; type="application/ard+json"' always;
    # ... your existing root configuration
}

A client that only understands JSON still reads application/ard+json, because it ends in +json. Changing the type breaks nothing that worked.

What we changed today

Neuronto now serves its manifest as application/ard+json, sends Link: rel="ard" on the root, publishes an SVCB record at _index._agents.neuronto.com, gives its registry entry a base URL, answers discovery errors as Problem Details, pages search results with nextPageToken, and asks other registries for their local results only, so a query never travels more than one hop. The specification's own conformance tool still reports PASS, 0 errors, 0 warnings for both the manifest and the registry. The code is open on GitHub.

One thing we did not ship yet: DNS-SD. The SVCB record already gives a client the same entry point, and DNS-SD earns its keep mainly where a domain has several manifests to enumerate.

curl -s https://neuronto.com/search \
  -H 'content-type: application/json' \
  -d '{"query":{"text":"scrape a website"},"federation":"auto"}'

claude mcp add --transport http neuronto https://neuronto.com/mcp

Keep reading