Agentic Resource Discovery describes a layer for publishing and finding agentic resources. This recipe is a proposed evaluation procedure. ByAgents does not currently operate an ARD registry or claim that its own knowledge API implements ARD.
Pin the specification and the consumer
The main-branch ARD specification reviewed on September 13, 2026 identifies v0.91. It describes JSON-LD entries and the well-known /.well-known/ard.json path. The predecessor /.well-known/ai-catalog.json is optional for consumers to consult. Search relevance is explicitly distinct from trust or safety. Specification.
Main is mutable. Before implementation, pin a commit or released revision and identify the intended registry or client version. Do not mix an old catalog example with a newer entry schema. A news announcement is useful context, but it is not the full implementation contract.
Define the experiment
Name one real capability, a representative customer task, and a discovery consumer. Record how that consumer obtains publisher entries. Confirm whether you have permission to publish, register, and invoke the capability; a read-only assessment should stop before those mutations.
Separate the underlying artifact from its discovery description. An MCP server, A2A service, or API may need its own authentication and compatibility checks. A discoverable record can point to a broken or unavailable service.
Test the route in stages
| Stage | Proposed check | Evidence |
|---|---|---|
| Publication | Fetch the intended manifest from its published location | URL, response, revision, timestamp |
| Validation | Apply the pinned schema and relevant semantic checks | Validator version and specific errors |
| Ingestion | Verify the named consumer actually indexed the entry | Consumer response or observable record |
| Retrieval | Run a representative unbranded query | Query, filters, returned identifier, context |
| Use | Resolve and test the capability within authorization | Compatibility and final task outcome |
Do not infer ingestion from a crawler request alone. Do not infer retrieval from the fact that a record appears in an administrative inventory. Do not infer useful execution from an endpoint returning any response.
Evaluate descriptions for discrimination
Write a factual capability description that includes the result and meaningful constraints. Test a query the resource should satisfy and a nearby query it should not. A resource that matches everything is not necessarily described well. Preserve the criteria you used before evaluating the results.
Keep publisher assertions distinguishable from verified properties. A description can claim a region, certification, or capability; the audit should retain the evidence supporting that assertion. Do not interpret a semantic relevance value as an independent quality score.
Decide whether the experiment merits expansion
A successful small test can establish compatibility with one consumer. It does not establish that major assistant products consume the registry, that independent users arrive through it, or that the route has meaningful commercial volume.
Continue when the intended consumers exist, the underlying capability is useful, and the maintenance burden is reasonable. If no relevant consumer ingests the record, report that distribution gap rather than presenting a valid file as traction. Keep the protocol map and current briefing separate from claims about actual adoption.