AWS Just Built DNS for Agents — Here's What That Actually Buys You
胡新宇
发布于 2026-08-25
AWS released ARD (Agentic Resource Discovery) on Aug 24 — an Apache 2.0 open spec for federating agent registries. The lead author is ex-Route 53. Here's what engineering teams should actually do in the next 6 months.
AWS Just Built DNS for Agents — Here's What That Actually Buys You
On August 24, AWS released an open specification called ARD — Agentic Resource Discovery. Apache 2.0, public GitHub, anyone can implement it.
The lead author is Jeffrey Damick. He used to be a principal engineer on Amazon Route 53.
The problem nobody names: your agents can't find each other
Every company is building agents. MCP servers, custom tools, agent skills, internal API endpoints.
Team A writes a file-retrieval tool. Team B doesn't know it exists, so they write another one. Different parameter, same job.
There is no central catalog. No shared description format. No way for an agent to discover what another agent already does.
Five tools is fine. Fifty MCP servers, thirty agents, hundreds of endpoints — that's a spreadsheet, then a Slack thread, then silence.
AWS named the phenomenon "agent sprawl." The word is accurate. (Source: same AWS blog post.)
#AI Agent#AI工程#开源
AWS Just Built DNS for Agents — Here's What That Actually Buys You
What ARD actually is: DNS for agents
ARD does one thing: let an agent find other agents across any environment, the way a domain name resolves to an IP across any network.
The "DNS for agents" framing isn't marketing. Damick said it himself, and the architecture backs him up. DNS solved a translation problem: humans remember names, machines use addresses, the middle layer does the conversion. ARD aims at the same seam — agents need capability descriptors, registries each have their own format, and the federating layer is missing.
The spec lives at agenticresourcediscovery.org. Apache 2.0. Reference implementations on GitHub. Anyone can read it, anyone can build on it.
The key architectural move: ARD treats discovery like DNS treats name resolution. Local registries can federate through ARD without bilateral agreements, the way root servers federate the DNS namespace. Publishers describe once. Consumers discover everywhere.
AWS Agent Registry: the spec becomes a product
Same day as the ARD release, AWS put Agent Registry into Preview. It is the concrete shape the ARD spec takes inside AWS:
An admin creates a registry, sets approval rules, configures authorization
Publishers wrap their MCP servers, agents, and tools as records, submit for approval
Approvers review; approved records become discoverable
Consumers — humans and agents — search and call through an MCP-native endpoint
Authorization runs two ways: AWS IAM, or a JWT from your corporate identity provider. Search is hybrid: semantic plus keyword.
Look at ARD alone and it sounds like just another open spec.
Stretch the timeline and the picture changes.
In the past 30 days, AWS shipped AgentCore Browser Tool, AgentCore Payments GA, AgentCore Observability, AgentCore Gateway. All AgentCore building blocks. None of them have a discovery layer. Each one is a silo without ARD. (Sources: articles/未知/ Amazon Bedrock AgentCore 系列 — Browser Tool, Payments GA, Observability, Gateway, Aug 2026.)
AWS isn't releasing a spec. It's grabbing the right to define agent infrastructure standards.
Putting Route 53's engineering muscle behind agent discovery is itself a competitive statement. DNS worked because it solved a problem every operator shared, with reference implementations strong enough to anchor an ecosystem. AWS is betting the same logic holds here.
A bucket of cold water
ARD is open. Apache 2.0. Spec public. Reference implementation public.
But AWS Agent Registry's approval flow, authorization, and governance are bound to AWS IAM and Bedrock. The control plane stays in AWS.
Open spec does not equal open ecosystem. AWS opened the discovery protocol. It kept the trust and control surfaces. (Source: same AWS blog post.)
The play matches what AWS did with Route 53: open protocol, captured control plane.
One more thing. ARD is brand new. No large-scale deployments. The AWS blog itself leans on "we expect" language — future tense. Full schema details aren't public; you have to dig into the GitHub repo for reference implementations.
My read after going through the spec: direction is clear, details aren't fixed yet. This is the land-grab phase.
What engineering teams should actually do in the next 6 months
Six concrete moves, no fluff:
One — inventory your assets. List every MCP server, agent, tool, and skill you have. Ignore ARD for a moment. You can't federate what you haven't catalogued.
Two — wrap everything in MCP if you haven't already. ARD's discovery rides on top of MCP. Tools that aren't MCP-shaped will be hard to surface through any registry, ARD included.
Three — watch the schema. The spec is early. Reference implementations on GitHub will iterate. Ten minutes a week on changelogs beats a surprise migration in six months.
Four — don't migrate to AWS wholesale. Keep your private registries running. Keep the interface layer clean so you can federate through ARD later if the protocol wins.
Five — count the non-AWS implementations. If three or more non-AWS companies ship ARD-compatible registries in the next six months, the spec is real. If they don't, it's an AWS-only "open" standard.
Six — pick a registry strategy now, not later. Build vs. buy vs. federate is a one-quarter decision, not a one-year one. Teams that punt will inherit whatever AWS, MCP-incubator vendors, and GitHub MCP Registry pick for them.
Is ARD the BGP of agents, or X.500?
Open question.
BGP became the internet's de facto standard because it solved a problem painful enough that every major player was willing to adopt.
X.500 died because it was heavy and nobody actually needed a full directory service.
Agent discovery's biggest enemy isn't technical complexity. It's every vendor believing they can sit on the fence for another six months. (Source: synthesis of ARD post and adjacent MCP ecosystem coverage.)
AWS has shown its hand. What Damick brings from DNS isn't code — it's a battle-tested mindset about how to federate independently operated systems at internet scale.
Your team's call. Six months from now, the answer is visible.
