The AI agent ecosystem has a critical unifying gap: despite 15+ communication protocols and 10+ fragmented marketplaces, there is no universal agent discovery, cross-protocol identity, or governance standard - with AGNTCY (Cisco/Linux Foundation, 75+ companies, P2P architecture) being the most production-ready attempt, OSSA uniquely claiming the "contract layer" between protocols and applications, and the newly formed AAIF (Anthropic, OpenAI, Google, Microsoft) aspiring to become the "W3C for agents" while MCP dominates adoption at 97M monthly SDK downloads in just 13 months.

The AI agent discovery standards landscape in early 2026 is converging toward interoperability across at least 10 competing initiatives - with .well-known JSON endpoints, DID methods, and reverse-DNS namespaces emerging as dominant discovery patterns, while AGNTCY (Linux Foundation), A2A, and MCP are bridging into each other and platforms like Salesforce natively adopt multiple protocols simultaneously.

The emerging AI agent discovery ecosystem is converging on domain-based identity (DNS) as the foundational layer, with multiple competing but complementary mechanisms - agent:// URIs, did:wba DIDs, DNS TXT/SVCB records, and .well-known agent cards - all anchored to existing web infrastructure, while lessons from email and ActivityPub federation show that operational complexity inevitably drives centralization regardless of protocol openness, making hybrid discovery approaches (DNS bootstrap + registries + gossip) the most viable path forward.

The AI agent ecosystem is converging around a layered architecture where static JSON files at well-known URIs enable any system to become a discoverable agent node, with A2A for agent-to-agent communication, MCP for tool access, OSSA for governance contracts, and AGENTS.md (adopted by 60,000+ projects) for human-readable coding agent guidance - all requiring remarkably low barriers to entry.

DUADP and the race to become DNS for AI agents

No universal discovery protocol exists for AI agents, and DUADP's federated approach addresses the most critical gap in the emerging agentic stack. While MCP has standardized agent-to-tool connectivity (97M+ monthly SDK downloads) and A2A has consolidated agent-to-agent communication (150+ organizations), every major analysis of the landscape identifies the same vacancy: there is no unified, vendor-neutral discovery layer spanning protocols, frameworks, and platforms. DUADP's architecture - combining DNS TXT records, WebFinger-style resolution, federated gossip propagation, and a novel GAID URI scheme - occupies a technically differentiated position against both centralized registries (MCP Registry, Salesforce AgentExchange) and competing decentralized approaches (AGNTCY's P2P DHT, ANS's DNS hierarchy). The window is narrow: the Agentic AI Foundation under the Linux Foundation is rapidly consolidating governance, and NIST CAISI's AI Agent Standards Initiative (launched February 2026) is actively soliciting exactly the kind of specification DUADP represents. - -

The discovery layer is the last unsolved problem in the agent stack

The agentic AI protocol landscape underwent remarkable consolidation in 2025, crystallizing into a complementary multi-protocol stack under Linux Foundation governance. MCP dominates agent-to-tool connectivity with 5,800+ registered servers and adoption by OpenAI, Google DeepMind, and Microsoft. A2A handles agent-to-agent communication with 150+ supporting organizations including Adobe, Cisco, SAP, and all major cloud providers. AGENTS.md provides coding-agent context across 60,000+ repositories. AGNTCY adds infrastructure plumbing for identity, messaging, and observability with 75+ companies supporting it.

Yet none of these protocols answers the fundamental question: how does an agent - or a human - discover the right agent for a task across the entire ecosystem? The MCP Registry at registry.modelcontextprotocol.io indexes only MCP servers. A2A's .well-known/agent.json discovery is per-domain with no global search or aggregation. Google's Agentspace (now folded into Gemini Enterprise) is a proprietary walled garden. Salesforce AgentExchange serves only the Salesforce ecosystem. The OpenAI GPT Store contains 3M+ custom GPTs but is OpenAI-locked. Fetch.ai's Almanac requires blockchain transactions for registration.

The fragmentation math is stark: 10+ major agent marketplaces exist, each with different listing requirements, technical standards, and monetization models. BCG calculates that without standards, integration complexity rises quadratically - every new marketplace multiplies the connectors needed. The AI agent market is projected to reach $50 billion by 2030 with 10,000+ custom agents published weekly, making universal discovery infrastructure not just useful but essential.

DUADP's positioning as a cross-protocol, cross-marketplace discovery layer addresses this gap directly. Unlike MCP Registry (tool-specific), A2A Agent Cards (protocol-specific), or AGNTCY (infrastructure-focused), DUADP aims to index agents, skills, and tools regardless of which protocol they use or which marketplace lists them. - -

How GAID resolution compares to existing agent URI schemes

The agent identifier landscape contains at least six competing approaches, none yet dominant. DUADP's GAID scheme (duadp://skills.sh/tools/web-search) represents a seventh entry designed to subsume the others.

IETF draft-narvaneni-agent-uri (versions -00 through -02, October 2025) defines the agent:// URI scheme with a five-layer architecture: URI scheme, transport binding, agent descriptor, resolution framework, and application semantics. The format agent://authority/path maps to HTTPS-hosted agent descriptors, with optional protocol hints (agent+https://). At IETF 123, Ted Hardie stated the draft would need "significant refactoring" for adoption, and it was recommended for a non-WG-forming BoF only.

did:wba (Web-Based Agent DID method), developed as part of the Agent Network Protocol, extends W3C's did:web specifically for agent-to-agent authentication. The format did:wba:example.com:user:alice resolves to https://example.com/user/alice/did.json. Authentication uses DID + cryptographic signature in HTTP headers, with the server verifying against public keys in the DID document. The resolution process mirrors did:web but adds agent-specific constraints and an AgentDescription service type.

AID (Agent Identity & Discovery) takes a DNS-first approach, using a single _agent TXT record per domain: _agent.example.com. 300 IN TXT "v=aid1;u=https://api.example.com/mcp;p=mcp". Single-letter field keys (v, u, p, k, i) maximize byte efficiency within DNS's 255-byte-per-string limit. Identity verification uses Ed25519 HTTP signatures verified against public keys in the DNS record.

DUADP's GAID scheme (duadp://namespace/path) offers three key differentiators over these approaches. First, it unifies discovery and identity in a single URI - duadp://skills.sh/tools/web-search simultaneously identifies the resource and implies its discovery mechanism, whereas agent:// requires a separate resolution step and did:wba requires DID document fetching. Second, the duadp:// scheme is explicitly designed for resolution through multiple mechanisms (DNS TXT lookup, WebFinger query, registry API, gossip network) with graceful fallback, whereas agent:// prescribes HTTPS resolution and did:wba mandates DID document hosting. Third, the namespace component (skills.sh) enables hierarchical organization of the entire agent ecosystem - agents, tools, skills, and workflows - under a unified addressing scheme.

The closest analog to GAID resolution is WebFinger (RFC 7033), which ActivityPub/Mastodon uses for federated actor discovery (acct:user@domain → HTTPS lookup at /.well-known/webfinger). No formal proposal yet combines WebFinger specifically with AI agent discovery, but the pattern is natural: a WebFinger query for a GAID could return links to the agent's A2A Agent Card, MCP server manifest, and OSSA contract simultaneously. DNS-SD (RFC 6763) provides complementary wide-area discovery using PTR + SRV + TXT records, though its metadata capacity is severely limited. The BANDAID IETF draft (draft-mozleywilliams-dnsop-bandaid-00, October 2025, Standards Track) proposes SVCB records under _agents.example.com subdomains, secured with DNSSEC + DANE - a more modern DNS foundation that DUADP could adopt. - -

Agent JSON fills the gap between protocol cards and full contracts

The .ajson/.jsona format enters a crowded field of agent description standards, but targets a specific sweet spot that existing formats miss. Current agent description formats occupy distinct layers: A2A Agent Cards are protocol-level discovery metadata, MCP tool schemas are tool-level invocation metadata, OSSA manifests are full governance contracts, and AGENTS.md is human-readable coding guidance. No format is optimized for universal discovery indexing across all these layers.

A2A Agent Cards contain identity fields (name, description, provider, version), a service endpoint URL, capability flags (streaming, push notifications), authentication schemes, and an array of AgentSkill objects. They're served at /.well-known/agent.json and support optional JWS signing. Their limitation for universal discovery is scope: they describe only A2A-compatible agents and carry no governance, trust, or cost information.

MCP's server.json format in the registry includes server name, description, repository URL, package identifiers (npm, PyPI), transport configuration, and optional remote endpoint details. The MCP Registry API is frozen at v0.1, with a proposed /.well-known/mcp endpoint under discussion. The format is entirely tool-focused - no agent identity, no capability negotiation, no trust tiers.

The JSON Agents / PAM (Portable Agent Manifest) project at jsonagents.org is the closest existing format to .ajson. It defines an ajson:// URI scheme with JSON Schema 2020–12 validation, seven standard capabilities (summarization, routing, retrieval, QA, classification, extraction, generation), modular profiles (core, exec, gov, graph), a policy expression language, and explicit framework mappings for LangChain, OpenAI, AutoGen, and MCP. A sample manifest uses "id": "ajson://example.com/agents/support-hub" with capabilities, runtime configuration, security settings, policies, and multi-agent graph definitions.

DUADP's .ajson format can differentiate by serving as a universal index record rather than a standalone manifest. Where OSSA manifests are comprehensive governance contracts (identity, capabilities, autonomy, resources, governance sections) and A2A Agent Cards are protocol-specific connection metadata, .ajson could be designed as a lightweight, indexable discovery record that links to full specifications in any format. An .ajson record would contain: the GAID URI, a human-readable description, capability tags from a standardized taxonomy, endpoint URLs for each supported protocol (A2A, MCP, OSSA, OpenAPI), trust tier indicators, and provenance signatures. This "index card" approach - rich enough for discovery decisions but pointing to full specifications elsewhere - avoids competing with existing formats while providing the universal indexing layer none of them offer.

The OSSA specification already defines an agent-card.schema.json with required fields including uri (format agent://{namespace}/{name}), capabilities array, tools array with MCP server references, transport and authentication requirements. Evolving this into .ajson with GAID-based URIs and explicit multi-protocol endpoint references would create a natural upgrade path from OSSA's existing schema.

Layer 2: Federated Discovery via [object Object] Agent Cards

To ensure interoperability between high-bandwidth OCI pulls and low-bandwidth web crawlers, DUADP introduces the .ajson (Agent JSON) extension. An .ajson file is a lightweight, cryptographically hashable index card that summarizes the agent's identity, capabilities, endpoints, and conformance tier. It acts as the bridging format between MCP tool registries and A2A discovery graphs, enabling decentralized web crawlers to index AI capabilities as easily as HTML web pages.

{
  "gaid": "duadp://acme.com/security/security-scanner",
  "name": "security-scanner",
  "version": "2.1.0",
  "kind": "Agent",
  "description": "Container Vulnerability Scanner",
  "trust_tier": "verified-signature",
  "endpoints": {
    "duadp": "https://duadp.acme.com",
    "mcp": "https://mcp.acme.com/tools/security"
  }
}

- -

Ten Patterns from Globally Scaled Infrastructure

Analysis of successful federated infrastructure systems reveals recurring patterns that form the DUADP design foundation:

Content-addressable storage: OCI registries, npm, Maven, and Git use cryptographic hashes (e.g., SHA-256) as the fundamental unit of trust, enabling deduplication, integrity verification, and immutability.
Proxy/cache federation: DUADP scales via hierarchical proxy caching and gossip-based selective replication, similar to how Verdaccio chains npm registries or Harbor replicates OCI images.
Discovery aggregation: Separation of discovery (listing .ajson cards) from hosting (OCI blob pulls) allows decentralized indexers to crawl capabilities without hosting heavy artifacts.
DNS as a universal trust anchor: DUADP specifies a DNS bootstrap protocol (_duadp.<domain> IN TXT "v=duadp1 url=https://... cap=skills") allowing clients to resolve mesh endpoints without out-of-band handshakes.
Layered security adoption: Trust tiers (Basic, Standard, Verified) support everything from simple HTTPS API keys to mTLS with full provenance chains and transparency logs.
Immutable tombstones: Revoked identities leave cryptographic tombstones to prevent downgrade attacks, propagating aggressively during peer gossip.
Topic-based Pub/Sub delivery: Nodes decouple publishers from mesh subscribers over resilient event streams (CloudEvents/NATS), buffering propagation independently of client load.
Gossip-driven anti-entropy: Eventual consistency is achieved via polling and delta checksums, ensuring isolated registry enclaves rapidly reconcile split partitions.
Scoped trust boundaries: Mesh architecture isolates community pools from zero-trust enclaves. Registries explicitly filter capabilities lacking required signatures.
Schema-on-publish enforcement: Nodes leverage strict JSON Schema validators on the ingress edge before propagating elements to the wider mesh. - -

The Complete DUADP API Surface

The current reference implementation (v0.1.0) demonstrates the comprehensive scope of the protocol, exposing 15 dedicated endpoints that cover discovery, resource management, federation, and advanced governance:

Discovery & Resolution: /.well-known/duadp (Node capabilities & version)
Resource Management: /api/v1/skills, /api/v1/agents, and /api/v1/tools for listing and retrieving assets.
Search & Querying: /api/v1/search for full-text search across all types.
Mutation & Federation: /api/v1/publish (Publish agent/skill/tool), /api/v1/validate (Validate OSSA manifest).
Federation & Identity: /api/v1/federation/list, /api/v1/federation/register, /api/v1/federation/peers, /api/v1/federation/gossip, and /api/v1/identity/node.
Operations & Observability: /api/v1/governance (Governance policies), /api/v1/health (Node health status), and /api/v1/metrics (Usage & performance metrics).

This structured API shifts the ecosystem conversation from "which vendor API do we support?" directly to "does this node speak DUADP?" - -

Federated gossip beats both centralized registries and pure P2P

DUADP's three-tier discovery architecture - DNS TXT bootstrap, WebFinger-style resolution, gossip-based federation - occupies a pragmatic middle ground between fully centralized and fully decentralized approaches, drawing on lessons from both email federation and modern service mesh architectures.

Centralized registries (MCP's official registry, Salesforce AgentExchange, Google's AI Agent Marketplace) offer curated discovery, quality control, and immediate usability. But as Infoblox's DNS-AID proposal predicts: "Whoever controls discovery influences an agent's attack surface." Centralized registries create single points of failure, enable vendor lock-in, and fragment the ecosystem into incompatible silos. The 10+ competing marketplaces today demonstrate this problem in real time - agents listed on the GPT Store are invisible to Salesforce AgentExchange users.

Fully decentralized approaches like AGNTCY's P2P DHT (using libp2p Kad-DHT with OCI-based storage) eliminate single points of failure but introduce latency, consistency challenges, and bootstrap problems. The ANS IETF draft authors themselves acknowledge the difficulty of "architectural decisions about the extent of decentralization required, plus issues like latency, consistency, operational cost, and complexity." Fetch.ai's blockchain-based Almanac requires cryptocurrency transactions for registration, creating unnecessary friction.

DUADP's federated model mirrors the architecture that made email the most successful federated system in history. DNS TXT records provide the bootstrap layer - any domain can advertise its DUADP node using a single TXT record, just as SPF/DMARC use DNS for email authentication. This requires no new infrastructure and works with every domain on the internet. WebFinger-style resolution enables cross-domain discovery: querying duadp://skills.sh/tools/web-search triggers a resolution chain from DNS to HTTPS endpoint, similar to how ActivityPub's WebFinger resolves @user@instance handles. Gossip protocol federation (modeled on Consul's Serf/SWIM implementation) propagates discovery information epidemically between nodes, achieving convergence in O(log N) rounds with bounded per-node bandwidth.

The critical advantage over pure P2P is operational accessibility. Running a DUADP node can be as simple as hosting a static JSON file at a well-known path - the "any system can be a node" principle. A Drupal site, a Flask API, a Kubernetes operator, or even a GitHub Pages deployment can participate in the federation without running DHT infrastructure or maintaining persistent peer connections. AGNTCY's DHT approach, by contrast, requires dedicated node software maintaining peer tables and participating in distributed hash table routing.

The gossip layer adds resilience without requiring universal connectivity. Nodes that can't maintain persistent connections (serverless functions, CMS platforms, static sites) participate through periodic polling and cached responses. Nodes that can maintain connections (dedicated registries, Kubernetes clusters) run the full gossip protocol for real-time propagation. DUADP's AsyncAPI events (duadp.agents.registered, duadp.agents.updated, duadp.agents.revoked) provide the event vocabulary for gossip propagation, and the existing trust tier system (official, verified-signature, signed, community, experimental) enables nodes to make informed decisions about which propagated records to trust. - -

Becoming "THE API" requires bridge-first integration strategy

DUADP's path to becoming the universal interface layer depends on integrating with existing ecosystems rather than displacing them. The integration surface area spans five categories: protocol bridges, framework adapters, registry connectors, CMS plugins, and infrastructure operators.

Protocol bridges already exist between MCP and A2A - projects like A2A-MCP-Server expose tools (register_agent, send_message, get_task_result) that translate between protocols. DUADP needs a similar bridge architecture where querying a GAID resolves to the appropriate protocol endpoint. A DUADP resolver for duadp://skills.sh/tools/web-search would return structured endpoints: {"a2a": "https://skills.sh/.well-known/agent.json", "mcp": "mcp://skills.sh/tools/web-search", "ossa": "https://skills.sh/manifests/web-search.yaml"}. This multi-protocol resolution is what neither A2A Agent Cards nor MCP Registry provides.

Framework adapters for LangChain, CrewAI, AutoGen/AG2, and Kagent would enable discovery-by-GAID within existing agent code. LangGraph already exposes A2A endpoints natively. CrewAI agents can be containerized and deployed via Kagent's BYO mechanism. AutoGen v0.4 supports A2A Server mode. The adapter pattern is: tools = duadp.discover(capability="web-search", trust_tier="verified") returns framework-native tool objects regardless of the underlying protocol. This is analogous to how OSSA already exports to LangChain, CrewAI, AG2, MCP, A2A, and Kagent from a single manifest definition.

Registry connectors would crawl and index existing registries: the MCP Registry API (GET /v0/servers), A2A well-known endpoints, AGNTCY OASF schema server, Salesforce AgentExchange listings, and any future marketplace APIs. Each indexed entry gets a GAID, creating a universal search layer over fragmented registries. This mirrors how Google Search indexes the web without replacing individual websites.

CMS integration is a particularly strong differentiation opportunity. The Drupal AI ecosystem already includes 48+ AI provider integrations, a plugin-based agent framework (drupal/ai_agents), and OSSA manifest support (drupal/ai_agents_ossa). A DUADP Drupal module that automatically serves .well-known/duadp.json and registers the site's agents in the federated network would make every Drupal site a DUADP node with zero additional infrastructure. WordPress, with its REST API and plugin architecture, could follow the same pattern. The "any system can be a node" approach means the barrier to participation is a JSON file at a predictable URL path - achievable on any web server, CMS, or static hosting platform.

Kubernetes operators represent the enterprise adoption path. Kagent already defines Agent CRDs with the pattern apiVersion: kagent.dev/v1alpha2. A DUADP operator that watches Agent CRDs and automatically registers them in the federated discovery network would make every Kubernetes cluster a DUADP node, with agents becoming discoverable the moment they're deployed. - -

AGNTCY is the primary competitor, but OSSA's contract layer is unique

The competitive landscape contains one direct threat (AGNTCY), two emerging alternatives (ANS, Oracle Agent Spec), and a governance risk (AAIF scope expansion).

AGNTCY (Cisco/Linux Foundation) is the most complete competing approach, with a full discovery + identity + messaging + observability stack backed by 75+ companies including Cisco, Dell, Google Cloud, Oracle, and Red Hat. Its OASF (Open Agent Schema Framework) provides agent description capabilities, its Agent Directory uses P2P DHT for decentralized discovery, and its Identity service provides cryptographic verification. AGNTCY's strengths are institutional backing, production-ready code, and Linux Foundation governance. Its weaknesses are architectural complexity (full P2P requires dedicated node software), Cisco-centric origins, and focus on infrastructure rather than contract semantics.

ANS (Agent Name Service) from the OWASP GenAI Security Project takes a DNS-inspired approach with PKI-based identity, protocol adapter layers, and zero-knowledge proofs for capability validation. An IETF draft (draft-narajala-ans) has been submitted. ANS is conceptual only - no production deployment exists, but its IETF standardization path could give it long-term legitimacy if adopted.

Oracle's Open Agent Specification is a declarative schema for agents and workflows, positioned as "ONNX for agents." It's open-sourced and integrating with AGNTCY's OASF, creating a potential combined Oracle+AGNTCY+Linux Foundation competitor.

DUADP's differentiation against all three rests on the OSSA contract layer - the only specification that combines agent identity (W3C DIDs/GAID), authorization (Cedar policies), trust tiers, compliance frameworks, resource governance (token efficiency budgets), and cryptographic provenance in a single composable schema. As the OSSA white paper states: "MCP provides the hands. A2A provides the voice. OSSA provides the credentials." Neither AGNTCY's OASF nor ANS nor Oracle's Agent Spec addresses governance, compliance, or trust boundaries at the schema level.

The DIF Trusted AI Agents Working Group (launched September 2025) and the OpenID Foundation's OIDC-A proposal both converge on the same identity gap OSSA addresses. DIF is developing delegation chains, authorization boundaries, and human oversight mechanisms using DIDs and Verifiable Credentials. The OpenID Foundation's October 2025 whitepaper explicitly warns that OAuth 2.0 foundations "reveal significant cracks when agents begin operating with greater autonomy." DUADP/OSSA's existing GAID+DID+Cedar+VC architecture is ahead of both these efforts, which remain in specification-drafting phases. - -

What wins: simplicity, infrastructure embedding, and neutral governance

Historical protocol adoption patterns predict which standards win. SMTP's success came from simplicity - RFC 5321 notes that "protocols with few options tend towards ubiquity, whereas protocols with many options tend towards obscurity." TCP/IP won through infrastructure embedding - mandated by the US DoD in 1982, shipped with BSD in 1983. HTTP won through neutral governance at the IETF and W3C. MCP replicated this playbook exactly, going from release to industry standard in 13 months through simplicity (JSON-RPC 2.0), infrastructure embedding (native in Claude, ChatGPT, VS Code, Cursor), and neutral governance (Linux Foundation AAIF).

DUADP should apply these three principles directly. Simplicity: the minimum viable DUADP participation should be a static JSON file at /.well-known/duadp.json - no software installation, no persistent connections, no cryptocurrency. The DNS TXT bootstrap should require a single record following the SPF/DMARC pattern that every sysadmin already understands. Infrastructure embedding: DUADP should ship as a module for Drupal, a plugin for WordPress, a Helm chart for Kubernetes, a GitHub Action for CI/CD, an npm package (@bluefly/duadp) for Node.js applications, and a PyPI package (uadp) for Python services. The target is making DUADP participation a byproduct of existing workflows rather than an additional burden. Neutral governance: OSSA's submission to NIST CAISI (March 5, 2026) and its MIT license establish a foundation, but eventual contribution to the AAIF or Linux Foundation would provide the neutral governance that enterprise and government adopters require.

The NIST CAISI timing is particularly strategic. The RFI on AI Agent Security had an input deadline of March 9, 2026, and OSSA has already submitted a comprehensive response mapping GAID, DUADP, Cedar authorization, and trust tiers to NIST SP 800–53 Rev. 5 control families. The NCCoE's draft concept paper on "Accelerating the Adoption of Software and AI Agent Identity and Authorization" has a feedback deadline of April 2, 2026. OSSA's response already proposes a federal GAID namespace and standardized agent credential format. If NIST references DUADP/OSSA in its guidance, the protocol gains the institutional legitimacy that SMTP gained from DoD adoption.

Conclusion

DUADP occupies the most strategically valuable unclaimed position in the agentic AI stack: the universal discovery layer that sits between protocols and applications. The technical architecture - DNS TXT bootstrap, WebFinger resolution, gossip federation, GAID URIs, .ajson index records, and OSSA governance contracts - addresses real gaps that no competitor fully covers. AGNTCY comes closest but trades accessibility for architectural purity. The "any system can be a node" principle, implemented through static JSON files and CMS plugins, creates an adoption funnel that P2P DHT approaches cannot match. The critical next steps are threefold: formalize the GAID URI scheme as an IETF Internet-Draft before draft-narvaneni-agent-uri gains traction, embed DUADP participation into popular platforms (Drupal module, Kubernetes operator, npm package) to create infrastructure lock-in, and secure NIST reference or AAIF membership to establish the neutral governance credential that enterprise adoption requires. The window is 12–18 months before AGNTCY, ANS, or an AAIF-native discovery protocol consolidates the space.