How it works

Registration

There are four registration paths. These mirror the paper's four deployment contexts: enterprise on AI Catalog, enterprise on DNS-AID, SMB, and individual. Pick the path that matches how you host agents.

Enterprise AI Catalog (Teams / Orgs)

Identity: urn:ai:domain:example.com
Media type: application/ai-catalog+json

This is the simple case. An enterprise publishes at .well-known/ai-catalog.json. Any requester can fetch it directly, so direct resolution works and NANDA Index is not required. A NANDA Index entry is optional: useful for federation, fallback, and anti-squatting.

1. Deploy ai-catalog: Deploy at .well-known, (optionally clone https://github.com/projnanda/nanda-registry-server-repo which provides basic ai-catalog hosting code)
2. Register org: Create an org in NANDA Index with your registry base URL and domain.
3. Add agents: Register each agent on your registry via Registry Manager or the /agents API.
4. Verify & go live: Confirm your contact email. Resolvers can now discover your agents.

Resolution: Requester fetches AI Catalog directly, selects agent, tool, MCP server, or gateway, follows artifact URL.

DNS-AID (Enterprise / DNS)

Identity: urn:ai:domain:skyblue.com:agent:refunds
Media type: application/vnd.dns-aid+json

SkyBlue uses DNS-AID at refunds._agents.skyblue.com. NANDA Index does not replace DNS-AID: it makes the DNS-AID path reachable from the global switchboard.

1. Publish DNS records: Add DNS-AID TXT records at _agents.yourdomain.com.
2. Register org: Create an org in NANDA Index with your DNS-AID discovery name. NANDA stores a pointer; resolvers query your DNS directly.
3. Verify & go live: Confirm your contact email. No catalog server required.
4. Update via DNS: Any change to your TXT records is immediately visible to all resolvers.

Resolution: NANDA Index, DNS-AID lookup, SkyBlue gateway or Agent Card, auth, agent.

SMB Agent Card (Small Business)

Identity: urn:ai:domain:moonbakery39.com:agent:orders
Media type: application/a2a-agent-card+json

Moon Bakery owns a domain but runs no enterprise infrastructure. Its runtime, agent card, and domain are with three separate providers, a practical example of permissionless deployment. It needs only a stable identity and a delegated path: no dedicated agent-discovery DNS records, enterprise gateway, or organization-operated catalog endpoint required. NANDA Index becomes the primary discovery entry point.

1. Create card: Build your A2A Agent Card on host39.org. No server setup required.
2. Register org: Create an org in NANDA Index and paste your agent card URL.
3. Verify & go live: Confirm your contact email. NANDA Index points resolvers directly to your card.
4. Update via host39: Edit your card any time on host39.org. No index update needed.

Resolution: NANDA Index, Agent Card at host39.org, AWS runtime, payment or session token required.

Personal Agent (Individual)

Identity: urn:ai:email:john@hotmail.com
Media type: application/a2a-agent-card+json

John has no domain. His runtime is on Azure; his agent card is with a third-party host. No personal controlled domain is required. NANDA Index enables identity-first discovery for individuals, when the underlying account identity is verifiably bound to the resolution record.

1. Create card: Build your personal agent card on host39.org.
2. Register org: Create an org in NANDA Index with your email address as identity.
3. Verify & go live: Confirm your email. Your identity: urn:ai:email:you@example.com.
4. Update via host39: Edit your card any time on host39.org. No index update needed.

Resolution: NANDA Index, Agent Card at host39.org, Azure runtime, user consent required for private actions.

Identity, Resolution, Discovery, Invocation

The paper's typical flow: a requester starts with an identity, queries a resolution system, gets back AI Catalog-formatted resolution entries, follows the discovery path each entry specifies, then discovery, verification, and invocation proceed.

1. A requester starts with an identity (domain, email, or URN)
2. The requester queries a resolution system
3. The system returns AI Catalog–formatted resolution entries
4. Each entry specifies a discovery path
5. The requester follows that path (ARD, DNS lookup, gateway, etc.)
6. Standard discovery, verification, and invocation proceed

Identity

a stable identifier, such as a domain-anchored identifier, platform identity, DID, or provider-verified account identity.

Input: urn:ai:domain:example.com, urn:ai:domain:skyblue.com:agent:refunds, urn:ai:domain:moonbakery39.com:agent:orders, or urn:ai:email:john@hotmail.com

Resolution

selection of an authoritative discovery entry point.

The resolver sends the identity to the NANDA Index API. The Index returns an IndexRecord containing a catalog URL, a direct agent card URL, or a DNS-AID pointer, plus a TTL for caching.

Input: locator: urn:ai:domain:acme.com:agent:time
Output: IndexRecord { registry_url, media_type, identifier, ttl_seconds }
API: GET /api/v1/resolve?locator=…

Discovery

retrieval or search of capabilities through AI Catalog, ARD, DNS-AID, a gateway, or another native mechanism.

The resolver fetches the agent's catalog entry, then the full agent card, from the URL returned by Resolution. Enterprise registries serve an AI Catalog document; SMB and personal entries point directly to an A2A Agent Card, collapsing these into one request.

Input: IndexRecord.registry_url + IndexRecord.identifier
Output: AgentCard { url, authentication, skills, … }
API: GET <registry_url>/agents/<identifier>, then GET <catalog_entry.url>

Invocation

interaction with the selected resource through A2A, MCP, REST, or another supported protocol.

With the runtime endpoint discovered, the client invokes the agent directly through A2A. NANDA Index is no longer in the critical path.

Input: AgentCard.url + { message: { role, parts } }
Output: Result from the agent runtime
API: POST <agent_card.url>/run