Discussion: How Agent Interface Discovery (AID) Complements the NANDA Vision

[nembal]

Discussion: How Agent Interface Discovery (AID) Complements the NANDA Vision

The recent "Upgrade or Switch" paper from Project NANDA provides a comprehensive vision for a decentralized "Internet of AI Agents." I wanted to start a discussion on how our Agent Interface Discovery (AID) specification fits into this broader architectural landscape.

My analysis suggests that AID isn't a competitor to NANDA, but rather a minimalist and essential "Layer 0" bootstrap protocol that solves some of NANDA's most immediate challenges.

How AID Fits into the NANDA Vision

The AID specification can be seen as a practical implementation of a bootstrap protocol for the Internet of Agents. In the context of the NANDA paper's proposed architectural layers, AID would function as a key component of the Orchestration & Coordination Layer.

• A Pragmatic On-Ramp: The NANDA paper discusses the challenge of moving from the current web to a fully agentic one. AID provides an immediate, deployable on-ramp. Any organization with a domain name can start hosting an agent and make it discoverable today using existing, universally understood infrastructure (DNS).
• Solving the Initial Handshake: An agent needs to know two things to start a conversation: where to connect (uri) and what protocol to speak (proto). AID provides exactly this information and nothing more. It's the digital equivalent of a business card.
• Decentralized by Design: AID is decentralized in the sense that it requires no central registry, server, or API. Control is distributed among domain owners. This aligns perfectly with NANDA's goal of avoiding single points of failure and control.

How AID Differs from the Broader NANDA Vision

While AID fits neatly into the NANDA puzzle, it is a very small piece of it. The two approaches differ significantly in scope, philosophy, and complexity.

Dimension	NANDA Vision ("Upgrade or Switch")	Agent Interface Discovery (AID)
Primary Goal	To create a complete, decentralized ecosystem for agent collaboration, including data exchange, compute, identity, trust, and governance.	To solve one specific problem: "Given a domain, where is the agent and which protocol should I speak?"
Identity Model	Aspires to cryptographic, self-sovereign identity (DIDs). An agent's identity is portable and independent of its host or domain.	Domain-based identity. The agent's identity is fundamentally tied to the domain name (e.g., _agent.example.com). Trust in the agent is derived from trust in the domain owner.
Technology Stack	Envisions a new stack leveraging DIDs, Verifiable Credentials, zero-knowledge proofs, and potentially purpose-built ledgers or overlays.	Uses the existing web stack. It relies entirely on DNS (TXT records) and standard web security (HTTPS/TLS).
Trust Mechanism	Trust is granular and verifiable. An agent would prove its capabilities or attributes using signed Verifiable Credentials.	Trust is coarse-grained and based on domain control. If you trust example.com and its TLS certificate, you implicitly trust the agent it points to.
Capability Discovery	A core challenge. The "Switch" path proposes "Capability-First Addressing" where one could query for a function (/translate-en-es) and get a list of verified providers.	No capability discovery. AID explicitly states it "does not include manifests, capability lists, or runtime orchestration." A client discovers the agent first, then must use a richer protocol like MCP to ask it what it can do.

How AID Solves Key NANDA Challenges

AID provides elegant and immediate solutions to some of the complex problems raised in the NANDA paper, particularly around agent mobility and discovery.

1. The Agent Mobility Problem: A key challenge is that agents may not be fixed to one endpoint. The NANDA paper discusses the need for identifiers that are independent of an agent's location. AID solves this perfectly at the domain level. If a booking agent moves from an AWS server to a Google Cloud server, the provider simply updates the uri in their _agent.domain.com DNS TXT record. After the TTL expires, all clients will automatically find the agent at its new location.

2. The Bootstrap/Discovery Problem: The NANDA paper struggles with how billions of agents would find each other in a fully decentralized way. AID provides a simple, scalable, and human-friendly starting point. A user or another agent only needs to know a memorable domain name, not a long, cryptic DID.

3. Avoiding the "Registry Wars": The NANDA paper mentions the risk of fragmentation from over 150 different DID methods. AID sidesteps this entirely by leveraging the one, globally-agreed-upon namespace: DNS.

Critical Analysis: Where AID Falls Short (and Why It's Okay)

AID's strength—its minimalism—is also its primary limitation. It is not a complete solution for a trustless Internet of Agents.

• The Trust Anchor is the Domain, Not the Agent: This is the most significant difference. With AID, trust in an agent is derived from trust in the entity that controls the domain. There is no mechanism within AID to verify the agent's identity or capabilities independent of its DNS record. If evil-corp.com were to take over good-agent.com's domain, they could point the _agent record to a malicious agent, and a client using only AID would have no way of knowing. NANDA's DID-based vision aims to solve this by tying identity to cryptographic keys that the agent itself controls.

• It Doesn't Solve Capability Verification: This brings us to the critical issue of verifying what an agent can do. AID provides a URI and a protocol, but it offers zero proof that the agent at that URI is trustworthy or has the capabilities it claims. After discovering an agent with AID, a client still needs to use a richer protocol (like MCP) to query its capabilities and potentially request a Verifiable Credential to prove them. AID is just the first handshake.

• DNS Latency and Centralization: The NANDA paper correctly identifies DNS update propagation time (minutes to hours) and its centralized governance (ICANN) as major bottlenecks for a real-time, fully autonomous agent ecosystem. AID is explicitly subject to these limitations. An agent that needs to be discovered, used, and revoked in milliseconds cannot rely on a system with a recommended TTL of 5-15 minutes.

Conclusion: A Complementary Relationship

AID is not a competitor to the NANDA vision; it's a brilliant and necessary "Layer 0" protocol that could bootstrap the entire ecosystem. It solves the immediate, practical problem of agent discovery in a way that is simple, decentralized, and immediately deployable using the internet's existing infrastructure.

However, it deliberately and wisely punts on the harder, more complex problems that NANDA is trying to solve: establishing cryptographic trust, verifying capabilities, and enabling fine-grained, real-time governance in a trustless environment.

The two fit together perfectly in a layered approach:

1. A user or agent uses AID to find another agent's endpoint via a human-friendly domain.
2. It connects to that agent using a protocol like MCP.
3. Within that MCP session, it uses DIDs and Verifiable Credentials (the NANDA vision) to cryptographically authenticate the agent and verify its specific capabilities before transacting.

I believe this positions AID as an essential, foundational standard for the emerging Internet of Agents. I'd love to hear what others in the community think about this relationship.