On this page
AI Agent Discovery Protocols Are Solving the Wrong Problem
AI agent discovery protocols are fragmented across DNS, onchain, and brokerage models. They over-serve discovery but neglect behavioral trust verification. The missing layer is continuous attestation of agent reliability.
Over 2.3 million AI agents have valid identities and capability descriptions right now. Only 3.5% of them are verified trustworthy, and 28% don’t even respond when contacted. The 2026 protocol gold rush has produced dozens of discovery standards — from DNS-based lookup to onchain registries — yet nearly all of them stop at pre-interaction metadata while pushing verification and execution accountability to layers that don’t exist yet. AI agent discovery protocols are solving an over-served problem while neglecting the critical missing piece: continuous behavioral verification.
Here’s the pattern I’ve observed, which I’ll call Discovery Trust Lag. The ecosystem emits discovery, identity, and payment specs within months of each other. Nearly all of them handle find, describe, and price. Almost none handle verified execution, uptime attestation, or dispute resolution. The gap between what a protocol registers and what an agent actually does at runtime is widening every month.
If you’re building multi-agent systems, you’ll find that discovery is the easy part. Trust is the hard part. And the current protocol landscape reflects that imbalance precisely.
The Discovery Protocol Landscape Is Fragmented Across Three Architectural Camps
The protocols fall into three architectural philosophies: DNS-native, onchain, and centralized brokerage. Each camp makes fundamentally different tradeoffs about decentralization, adoption speed, and trust.
DNS-native approaches reuse the internet’s most battle-tested infrastructure. DNS-AID is an IETF draft using DNS SVCB and TLSA records for agent identification, deliberately avoiding central registries. The Agent Identity & Discovery (AID) v2 standard takes an even more minimal approach — a single DNS TXT record makes any agent service discoverable, with Ed25519 HTTP Message Signatures (RFC 9421) for proof. The Universal Agent Discovery Protocol (DUADP) uses DNS SRV/TXT records and well-known endpoints (RFC 8615) for cross-organizational discovery. And the Linux Foundation’s Agent Name Service (ANS) anchors agent identity directly to DNS with signed records checkable against public key infrastructure.
Onchain approaches add cryptographic commitment and payment-native design. ERC-8257 specifies a permissionless onchain registry for AI agent tools with extensible predicate-based access control, deferring pricing and access-model details to manifest hints and external predicate contracts. The registry never handles funds — the manifest declares what a tool costs, and the endpoint enforces payment.
Centralized brokerage prioritizes unified UX over decentralization. Monid is an agent-native router enabling AI agents to autonomously discover, authenticate, and execute API calls across 200+ tools with a unified pay-per-call interface and a flat 10% markup on underlying provider cost. TrueFoundry defines an AI agent registry as a centralized or federated catalog of autonomous agents and capabilities used for discovery, governance, and reuse across multi-agent systems.
Then there are the hybrid and full-stack protocols. Google’s Agentic Resource Discovery (ARD) — announced June 17, 2026 with contributors including Microsoft, Hugging Face, GitHub, Nvidia, Salesforce, ServiceNow, Snowflake, Databricks, Cisco, and GoDaddy — standardizes capability publication under an organization’s domain with federated registry indexing. The Agent Mesh Protocol (AMP) uses a decentralized mesh network via NATS and gRPC for agents to find and call each other across organizational boundaries. The Agent Discovery Protocol (ADP) v2 by Bidz-nl covers the full lifecycle: discovery, negotiation, transactions, and reputation signals. And the AI Agent Discovery and Invocation Protocol (draft-cui) is an individual IETF Internet-Draft proposing a metadata format, capability-based discovery mechanism, and unified RESTful invocation interface.
| Protocol | Pricing Model | Key Feature | Target Audience |
|---|---|---|---|
| Monid | 10% markup on provider cost per Monid | 200+ tools, unified pay-per-call | Agents needing immediate API access |
| ERC-8257 | Deferred to manifest hints per EIP-8257 | Onchain registry, predicate-based access | EVM-native agent tool ecosystems |
| ARD | — | Federated domain-based catalogs per Google | Enterprise cross-org discovery |
| DNS-AID | — | DNS SVCB/TLSA records per DNS-AID | Operators wanting decentralized discovery |
| ADP v2 | — | Full commerce lifecycle per ADP | Autonomous agent-to-agent commerce |
The table makes the fragmentation visible. Five protocols, three architectural camps, and only one with a transparent pricing model. The rest defer pricing to manifests, external predicates, or simply don’t address it.
Discovery Is Over-Served While Trust Verification Remains Unaddressed
The numbers tell a story the protocol designers aren’t talking about. AgentRisk tracked 2,300,349 total agents indexed, with 81,319 (3.5%) verified trustworthy, 269,334 delisted, and 644,127 (28%) registered but non-responsive, as reported in their analysis of agent discovery gaps. That’s nearly one million agents with valid identities and capability descriptions that are either delisted or completely non-functional.
This is what I mean by Discovery Trust Lag. The protocols solve find-and-describe brilliantly. They solve verify-and-trust not at all.
The structural reasons are clear when you look at the design choices. ARD returns metadata then, in its own words, “steps out of the way” — handing off trust to the agent’s native protocol. ERC-8257 defers access and pricing to external predicate contracts and never handles funds. Rail402’s agent-services-spec defines machine-readable paid-API discovery via /.well-known/agent-services.json and llms.txt, with autonomous payment via x402 flow in USDC on Base — but payment isn’t trust. Most discovery specs publish endpoints and capabilities, then stop.
A few protocols attempt to bridge the trust gap. OAN (OpenAgenet) is a protocol-neutral trust layer specifying identity objects, registration, authorization-aware discovery, and signed trusted invocation. ADP v2 includes reputation signals after completed transactions. These are steps in the right direction, but they’re still static attestations — snapshots at registration time, not continuous behavioral verification.
Here’s why that matters for you. If you’re building a production agent system today, you’ll discover agents that look capable on paper. You’ll call them. Some won’t respond. Some will respond but produce garbage. The protocol you chose told you they existed and what they claim to do. It didn’t tell you whether they actually work, whether they’ve been online for the last 30 days, or whether any other agent has successfully completed a transaction with them.
The protocol design incentive structure makes this worse. A protocol that requires behavioral verification before registration will lose adoption to one that lets anyone register freely. Market dynamics favor open registration. So the protocols that win adoption are the ones that trust least.
The Payment Layer Fragmentation Compounds the Trust Problem
Discovery protocols that defer payment create a second gap: agents can find tools but can’t reliably transact with them. As of March 2026, four competing agent payment protocol standards exist: x402 (Coinbase+Cloudflare), ACP (OpenAI+Stripe), UCP (Google+Shopify), and MPP (Stripe+Tempo), each addressing different payment layers.
This isn’t just fragmentation — it’s a trust multiplier. When a discovery protocol defers payment to an external layer, and that layer itself is fragmented across four standards, the agent has to negotiate not one trust gap but two. Which payment protocol does the target agent support? Is the payment flow authenticated end-to-end? Who handles disputes?
Rail402’s spec is one of the few that tries to close the loop: discovery and payment in one document, with x402 handling the transaction in USDC on Base. But it’s a single-contributor project with nine GitHub stars. The specs with industry backing — ARD, ANS, DNS-AID — don’t address payment at all.
For teams evaluating these protocols, the MCP vs REST API economic decision we’ve covered before applies here too: protocol choice isn’t just technical, it’s economic. If your discovery protocol doesn’t specify how payment works, you’re building custom payment integration for every agent you discover. That’s the same per-integration overhead that MCP was supposed to eliminate.
Centralized Brokers Trade Portability for Immediate Usability
The centralized brokerage camp makes a different bet: skip the trust problem entirely by becoming the trust layer yourself.
Monid’s approach is the most concrete. Agents query the registry using natural language, get ranked results with structured input schemas and transparent pricing, and the router handles authentication and billing. The 10% markup is the cost of not building trust infrastructure yourself. For a team that needs 200+ API endpoints working tomorrow, that’s a reasonable trade.
TrueFoundry’s enterprise registry model adds governance: centralized agent registration with metadata schemas, OAuth 2.1 + RBAC for per-team agent access, and versioning and full lifecycle management. This is the enterprise IT approach — control everything through a single pane of glass.
The tradeoff is portability and vendor lock-in. If your agents discover tools through Monid, you depend on Monid’s uptime, Monid’s pricing, and Monid’s tool curation. If TrueFoundry’s registry is your discovery layer, your agents can’t find anything that isn’t registered there. The Agent Cards approach to agent discovery we’ve discussed offers a more portable alternative — machine-readable identity documents that let agents find each other without a central broker.
AgentRisk’s analysis makes the neutrality problem explicit: cross-platform verification requires neutrality that’s impossible for single vendors. Google can’t credibly verify agents on Azure. Anthropic can’t verify agents on AWS. Every protocol builder has a conflict of interest.
A Decision Framework for Teams Choosing Discovery Protocols
Your protocol choice should follow from your team’s constraints, not from which spec has the most GitHub stars or the biggest contributor list. Here’s how I’d break down the decision:
If you need agents working across organizational boundaries with minimal infrastructure: DNS-native protocols (DNS-AID, AID v2, DUADP) are the lowest-friction option. You already run DNS. Publishing an SVCB or TXT record is a configuration change, not a new system. The tradeoff: no built-in payment, no built-in trust verification, and you’re responsible for your own agent metadata format.
If you’re building on EVM chains and need payment-native discovery: ERC-8257 gives you onchain commitment, content-hash verification, and a pluggable access control model. The manifest carries pricing hints, and the predicate layer handles access logic. The tradeoff: EVM-only, and the predicate contract pattern adds complexity that only makes sense if you’re already building onchain.
If you need enterprise governance with RBAC and versioning: A centralized registry like TrueFoundry’s gives you the control plane features enterprises expect. The tradeoff: vendor lock-in, and your agents can only discover what’s registered in that specific catalog.
If you want the broadest industry backing and don’t need payment: ARD has the strongest consortium — Google, Microsoft, GitHub, Nvidia, and others. Its federated model means you publish under your own domain and registries crawl you. The tradeoff: it’s v0.9, deliberately steps out of the way after discovery, and doesn’t address trust or payment.
If you need full lifecycle commerce including negotiation and reputation: ADP v2 covers registration through reputation signals. The tradeoff: it’s a single-contributor project with minimal adoption, and you’re betting on a protocol with almost no community validation.
The Missing Layer: Behavioral Attestation
The 2026 protocol gold rush is misallocating effort. Another discovery standard is redundant when 2.3 million agents already have valid identities and capability descriptions. The critical missing layer is independent, ongoing trust verification and dispute resolution.
New standards must mandate behavioral attestation — uptime metrics, fulfilled transaction counts, response latency distributions — rather than static capability manifests. A few projects are moving in this direction. The Internet Court protocol, announced July 2026, adds on-chain dispute resolution for AI agents. OAN specifies a trust-governed identity layer with signed invocation. ADP v2 includes post-transaction reputation signals. These are early experiments, not established patterns.
The question that should keep protocol designers awake: what happens when an agent with a valid identity and a perfect capability description consistently fails to deliver? Today, the answer is nothing. The protocol did its job — it registered the agent, published its capabilities, returned it in search results. The protocol has no mechanism to flag the agent as unreliable, to delist it based on behavior, or to warn the next agent that tries to connect.
If you’re evaluating discovery protocols today, ask one question that the spec authors don’t want to answer: how does this protocol handle agents that are registered, described, and broken? If the answer is “that’s someone else’s job,” you’ve found the gap. The protocol that closes it — not the one with the most contributors or the cleverest DNS trick — will be the one that actually makes the agentic web trustworthy enough for production.
For a deeper look at how MCP and REST APIs compare as economic decisions, and why the A2A protocol matters for cross-boundary agent communication, those posts break down the adjacent layers that discovery protocols hand off to.