Evidence note: This article rests on primary vendor announcements — AWS’s own weekly roundup posts and its machine learning blog — and on the self-descriptions published by the code repositories involved. Those are the subjects’ own accounts of their own work, not independent confirmation. None of the software described here has been run or benchmarked for this article, and several items below are explicitly marked where corroboration is missing.
A discovery layer for agent tools is not a new idea. What is new is that a cloud vendor’s routine weekly news post carried it alongside an acquisition, and that a handful of public repositories had already been written against it. One of those repositories is interesting for a reason that has nothing to do with the specification itself: it appears to treat the registry entry as a claim to be checked rather than a fact to be served.
What AWS published on August 31, 2026
AWS published a post in its AWS Weekly Roundup series dated August 31, 2026, titled "Welcome DuckLabs to the team, Agentic Resource Discovery (ARD), and more" (AWS Weekly Roundup, August 31, 2026). Two items share that headline: a definitive agreement to acquire DuckLabs, the Amsterdam-based company behind DuckDB, and Agentic Resource Discovery. Both facts here are AWS’s own announcement of its own business and its own specification work; they have not been independently corroborated for this article.
AWS describes Agentic Resource Discovery as an open specification for agent discovery, and gave it a separate treatment on its machine learning blog (AWS on ARD). The acquisition side of the same post is covered separately in our earlier report on the DuckLabs agreement.
One ordinary week in a routine series
The roundup is a weekly habit, not a launch vehicle, and reading the neighbouring weeks is the cheapest way to calibrate how much weight the August 31 items carry. Per AWS’s own posts: August 17 covered EC2 application status checks, an IAM role manager, and OpenAI Daybreak on Amazon Bedrock (August 17, 2026). August 24 covered Student Rewards on AWS Builder Center and a Local Zone in Las Vegas (August 24, 2026). September 7 reported Claude Fable 5.1 becoming available on AWS (September 7, 2026). September 14 covered OpenAI GPT-6 Astra on Amazon Bedrock, Amazon Quick desktop general availability, and Kiro for students (September 14, 2026). Each of those summaries is AWS’s own description of its own week; none is independently corroborated here.
The pattern is instructive. Region news, model availability, education programmes, console features — a specification headline is the outlier in that series, and an acquisition sharing the same headline is rarer still.
What the specification proposes
The shape of the proposal, as described on the specification’s introduction page, is that a client asks what is available for a task and gets a ranked set back before it invokes anything (ARD introduction). That inverts the common arrangement, in which an agent is handed a fixed tool manifest at startup and must reason over everything it was given, whether or not the current task needs it.
The practical consequence is a narrowing step ahead of invocation: fewer tool definitions in the prompt, a selection decision that can be logged and audited on its own, and a place to put relevance ranking that is not the model’s context window. Whether that narrowing improves task success in practice is not something the specification text can settle, and no benchmark result is claimed here.
Two vendors, one open specification
AWS frames the work as an open specification rather than a service (AWS on ARD). A second vendor announcement appears on Google’s developers blog, which carries a post announcing the Agentic Resource Discovery specification (Google developers blog, also served at an English-path URL). That is Google’s own announcement of its own involvement; the extent of either company’s governance role is not established by the announcements themselves, and sources do not confirm how decisions on the specification are made or who holds them.
The specification text is described as published at agenticresourcediscovery.org — an attribution that has not been independently corroborated for this article, and which should be treated as a pointer to check rather than a settled fact. A separate repository tracking the specification also exists in public (api-evangelist/agentic-resource-discovery); its relationship to the canonical text is not established here.
Where the text actually lives
Two repositories under the ards-project organisation hold the working material, according to their own published descriptions: the specification source in ards-project/ard-spec, and the documentation site in ards-project/ard-docs. For anyone evaluating a specification, this split matters more than the marketing page. The spec repository is where version history, open issues, and the actual normative language can be read; the docs repository is where the rendered site is generated from. A reader deciding whether to depend on this should open the spec repository’s commit history first.
Five projects already building on it
Five public projects are linked in the set of sources reviewed for this article (the count is a count of those repositories, not a survey of the ecosystem — a broader census has not been performed):
- A hands-on tutorial with a runnable two-organization data-analytics example over ClickHouse, published as Agent-Field/agentic-resource-discovery-lab, per the repository’s own description. A runnable two-party example is the most useful artefact in this list for anyone testing the idea, because cross-organization discovery is where a specification’s assumptions break first.
- hf-discover, an ARD client and server implementation maintained by Hugging Face (huggingface/hf-discover), per its own repository. Hugging Face shipping both halves is a meaningful signal about implementability, distinct from the vendor announcements — see also our earlier coverage of Hugging Face’s WebGPU kernel library for how that team tends to ship reference implementations.
- An Obsidian plugin that exposes agentic resources according to the specification (dsebastien/obsidian-agentic-resource-discovery-server). This one is not corroborated: the repository’s existence and stated purpose have not been independently verified here, and nothing about its maturity or maintenance should be inferred.
- resource-raiser, described as an agentic natural-language data-query engine built on the thesis that data should be discoverable through ARD (TechSoup/resource-raiser). Also uncorroborated; the characterisation above is a reading of the project’s stated thesis, not a tested account of what it does.
- Neuronto’s ARD Index (neuronto/agentic-resource-discovery), which is the subject of the next two sections and is likewise unverified.
The index that does not take the registry’s word for it
The Neuronto project is reported to build a verified tool index by reading each MCP server’s own tools/list response, rather than relying solely on what a registry entry claims the server offers. This claim has not been independently corroborated; the description comes from the project’s own material and has not been reproduced by running the index.
If it works as described, the design choice is the most interesting thing in this whole roundup. A discovery registry is a directory of self-reported capability, and self-reported capability drifts: a server ships a new tool and the entry lags, or an entry advertises a tool that was removed. An agent that trusts a stale entry will plan around a tool that does not exist and fail at invocation, after it has already committed to a plan. Reading the server’s live tool listing turns the registry entry into a hint and the server into the authority.
The cost is equally obvious and equally untested: live verification means network round-trips to every server in the index, freshness windows to tune, and a policy for what to do when a server is unreachable at index time. Sources do not confirm how the project handles any of these.
What the rest of Neuronto’s design implies
Three further elements are attributed to the same project, all of them uncorroborated here: federated search across public ARD registries, hybrid lexical and semantic retrieval, and a benchmark called ARD-Bench.
Read together, these describe a search problem rather than a directory problem. Federation implies no single authoritative registry is assumed — a reasonable bet for a young open specification, and a hard one to implement, since it means reconciling duplicate and conflicting entries across sources. Hybrid lexical and semantic retrieval is the standard answer when queries mix exact identifiers (a tool name, a server host) with intent descriptions ("something that can query our warehouse"); pure embedding search handles the second and fumbles the first.
The benchmark is the part worth watching. Tool-selection quality is currently argued rather than measured, and a named benchmark is at least a place to put numbers. No ARD-Bench results are cited in this article, and none should be assumed to exist in a comparable, published form until the benchmark’s tasks and scoring are public and someone outside the project has run it.
The other announcement in the same post, reread
The acquisition item in the same August 31 post deserves a second reading next to the discovery news. AWS announced a definitive agreement to acquire DuckLabs, the Amsterdam company behind DuckDB. By its own description, DuckDB is an open source analytical database that runs in-process — inside the calling application, with no server to operate — and executes SQL directly against files such as Parquet, CSV, and JSON. AWS states that DuckDB remains open source under its independent foundation following the agreement (AWS Weekly Roundup, August 31, 2026). These are the parties’ own statements about their own transaction and are not independently corroborated here.
The adjacency is at least suggestive. An in-process engine that reads files directly is exactly the kind of resource a discovery layer would want to describe: no endpoint to register, no service to keep alive, capability defined by what data it can reach. Whether the two items were placed in one post for any reason beyond calendar coincidence is not something the post establishes, and no strategic connection should be read into it.
Developer takeaway: what to check before wiring a discovery layer in front of your agent’s tools
For a team considering this, four checks come before any code:
- Read the specification repository’s history, not the site. Open ard-spec and look at how recently normative language changed and how open issues are handled. A specification announced by two vendors in the same season is early; early specifications move.
- Decide the trust question first. Will the agent trust registry entries, or verify against each server’s live tool listing? That choice determines latency budget, failure modes, and caching policy, and it is far cheaper to decide before implementation than after. The Neuronto design suggests one answer; it does not prove it is the right one.
- Measure the thing discovery is supposed to fix. The claimed benefit is fewer irrelevant tools in context and better selection. Both are measurable locally today — count tool definitions per request, count invocation failures caused by a tool that did not exist or did not fit — and a baseline taken before adopting a discovery layer is the only way to tell whether the layer helped.
- Start from the runnable two-party example. The ClickHouse tutorial exercises the cross-organization case, which is where a discovery protocol’s assumptions about identity, authorization, and entry freshness get tested.
What has not been tested here, and the follow-up worth running
Nothing in this article is a measurement. No repository above was cloned, built, or run; no discovery query was issued; no latency or selection-quality figure is reported. Every project description is the project’s own account of itself.
The follow-up that would actually settle something is narrow and reproducible: stand up the two-organization tutorial, point both a registry-trusting client and a live-verifying client at the same set of servers, then deliberately desynchronise one server — add a tool without updating its registry entry, and remove a tool that the entry still advertises. Record, for each client, whether the agent selected a tool that no longer exists, whether it found the tool that was added, and what the verification step cost in wall-clock time per query. That would turn the most interesting claim in this roundup — that an index should not take the registry’s word for it — from a design argument into a number.