Retrieval is procurement

A registry that conforms to the Agentic Resource Discovery specification has to answer exactly one kind of question. It must accept a sentence of English and return a list of tools, best first, each carrying a number between 0 and 100. That is the floor. The endpoint that lets you browse the catalogue deterministically is optional. The endpoint that lets you count what is in it is optional. The ranked guess is the only interface a registry is obliged to implement.

Of that number, the specification says this: it is "strictly an informational relevance metric and MUST NOT be interpreted by orchestrators as a cryptographic trust, compliance, or safety rating."

Both sentences are defensible on their own. Together they describe a system in which the only signal guaranteed to reach the component making the decision is the one that component is forbidden to act on.

ARD is at v0.91, still marked Proposal, dated 26 August 2026, and still moving — three pull requests merged on 12 September. Its authors are from Google and Hugging Face, and its acknowledgements run to contributors from Amazon Web Services, Cisco, Databricks, GitHub, GoDaddy, Microsoft, Nvidia, Salesforce and Snowflake. This is not a draft looking for adopters. GitHub's Agent Finder catalogue has been shipping since June, generating what its README calls "a generated Agentic Resource Discovery (ARD) ingestion artifact," and its first principle is stated in three words: "Discovery, not installation."

That phrase is the whole argument, and GitHub deserves credit for putting it so plainly. Installation is an event. Somebody did it, on a date, and the record of it is a line in a manifest that a reviewer can read, a scanner can enumerate and a lockfile can pin. Discovery is not an event. It is a query, evaluated when the agent needs something, against an index maintained by a party you probably do not operate.

What ARD changes is not whether tools get chosen. It is whether the choosing leaves anything behind.

Consider what the ranking is computed from. The specification's discovery signal is representativeQueries: two to five sample questions "a user might issue that this resource can serve," which the registry builds its semantic index from. The publisher writes them. They are sentences a vendor composes about its own product, in order to be retrieved, and they are the substrate of the match.

They are also not required. The authoritative schema lists exactly three mandatory terms for an ARD entry — identifier, displayName, type — and conformance tooling flags a missing or badly sized representativeQueries as a warning, not an error. The trustManifest, which carries identity binding, attestations, provenance and signatures, is optional altogether.

And there is a detail easy to miss on a first reading. In a search response, an entry "MUST carry identifier; every other term is at the registry's discretion," and representativeQueries "serve indexing rather than presentation and are normally omitted." The text that caused the match is not shown to the thing that acts on the match. An orchestrator receives a name, a type, a URL and a score, and no view of the sentence it actually matched against. Retrieval happens on the publisher's words; selection happens without them.

On 12 September an implementer opened issue #90 on the specification repository. They run a signed timestamping service, and found that agents could not find it when its representative queries used its own product language. After rewriting them in the vocabulary a searching agent would use mid-task — "trusted timestamp for an agent action, verifiable offline" — discovery improved. They proposed the specification offer guidance to that effect, and were careful to say this was not a measured ranking result.

Nothing about that is bad faith. It is a conscientious publisher with a real discovery problem, reasoning in the open. It is also the first inch of search engine optimisation for tools, arriving on schedule, requested politely, on the record, before the specification has left Proposal status. There will be a great deal more of it, and very little of it will be filed as an issue.

The obvious reply is that trust was never supposed to be the ranking's job. The specification is emphatic that it is not: relevance and trust are "fully decoupled," and verification belongs to the trust manifest. That would be a clean separation if the trust half were as reliably present as the relevance half. It is not.

ARD "does not define a signing or verification procedure of its own." The signed payload, canonicalisation, key resolution and processing are all deferred to whatever framework the manifest declares — SPIFFE, a DID method, an enterprise PKI. A registry should run that verification and may use the outcome in ranking. The one rule ARD does mandate is §4.5.1: the trust domain asserted in the manifest must align with the publisher domain in the entry's identifier, which is the defence against namespace squatting. On 14 September another implementer opened issue #94 pointing out that the specification never defines "align." They report that one implementation moved from exact matching to accepting subdomains behind a flag, that another does not validate the trust manifest at all, and that a permissive reading lets an entry claiming a public suffix accept identities from any domain beneath it.

I have not read those implementations, and the issue is a report rather than something I verified. Everything above is drawn from the project's own record — the specification text, its schema, its decision log and its issue tracker — which is the primary evidence and also, necessarily, one party's account of itself. But the shape of the problem does not depend on the contested details being right. The score is universal, numeric and comparable across every conforming registry. Verification is optional, framework-dependent, unevenly implemented, and resting on an undefined verb. One of those signals always arrives. The other sometimes does.

It gets sharper. ADR-0004 records that the working group deliberately kept Boolean filter expressions and custom sort orders out of the search API. Their reasons are good ones: sorting by metadata "conflicts with and destroys relevance-based ranking," and asking LLM orchestrators to generate complex Boolean strings is "error-prone and prone to LLM parser hallucinations." The consequence they list first is "Relevance Integrity: Guarantees that search queries remain sorted by semantic alignment."

So the mandatory interface cannot be asked to sort by anything except relevance. Not by verification status, not by publisher reputation, not by whether the trust manifest checked out. The deterministic endpoint where you could order by other fields is the optional one, and it carries no relevance scores at all. The design protects the ranking's meaning by removing every competing ordering — and then tells the orchestrator not to over-read the ordering. A sorted list has one affordance. The group knew its consumer was a model too unreliable to write a filter expression, and asked that same model to exercise interpretive restraint.

The strongest objection is that none of this is new. Package managers, service discovery and DNS all resolve names at runtime, and the industry survived. More to the point, ARD does not force anyone onto the open web: GitHub's own README says Agent Finder is "scoped to a registry" — public or private — and "governed by managed settings." A regulated organisation will point its agents at a curated internal index, and the reviewed list comes back.

That is genuinely the right answer, and most serious adopters will take it. But two things survive it. A package manager resolves a name: you asked for a specific artefact and got that artefact, and the request is the record. ARD resolves an intent, and the same sentence on two different days can legitimately return different providers, with no pin, no lockfile, and — the specification says so directly — no normative operation for retrieving a complete entry by identifier at all, that being "out of scope for this draft." And the boundary is a setting. Federation's auto mode has a registry query upstream registries and merge their results into one response, which the client sees as a single list. Curation is one configuration value away from not being curation.

Procurement has always been slow, and its slowness is the point. It is where an organisation writes down why it accepted a risk: the vendor review, the decision record, the dependency that someone signed for. ARD does not remove that work. It removes the moment the work used to attach to. There is no install event, no pull request adding a line, no artefact of the decision — because no decision was taken by anyone. A retrieval happened.

The specification's own motivation invites the comparison: it wants agents to find capabilities "similar to how search engines discover web pages." The analogy is more exact than it may have been meant to be. The web learned, expensively, what happens to ranking computed from what publishers say about themselves, and its answer was to stop trusting self-description and start measuring something publishers could not simply write down. ARD has shipped the earlier signal into a system whose reader cannot be sceptical, cannot see the text it matched on, and has been instructed, normatively, not to draw the only inference available to it.

The score is honest. It measures semantic similarity between a task and a sentence a vendor composed. What it cannot do is tell you that the sentence was true — and by the time it reaches the orchestrator, it is the only thing left to go on.