Beyond DNS: Building the Backbone for the Internet of AI Agents

TL;DR for operators

If your organisation is building one chatbot, DNS is not your problem. If your organisation expects thousands of autonomous agents to discover one another, verify capabilities, rotate endpoints, respect privacy boundaries, and revoke trust quickly, then DNS starts looking like a filing cabinet in a drone factory.

The paper behind NANDA proposes a layered discovery architecture for the “Internet of AI agents”: a lean signed index record called AgentAddr, richer verified metadata called AgentFacts, and optional adaptive resolvers for live endpoint selection.¹ The important idea is not that NANDA is “DNS for agents”. That is the tempting headline and, naturally, the least useful one. The paper is really about separating stable identity from dynamic operational metadata and from runtime routing.

For operators, the practical lesson is this: agent interoperability will not be solved by protocol enthusiasm alone. It will need registries, issuer trust, signed capability claims, revocation, auditability, private lookup paths, and fallback routing. That is infrastructure work. Glamorous? No. Necessary? Unfortunately, yes.

The proposal is strongest as a reference architecture for regulated or cross-organisation agent ecosystems: finance agents querying compliance agents, healthcare agents delegating to triage tools, logistics agents negotiating with external capacity providers, or enterprise assistants calling third-party task agents. It is weakest if read as a finished standard or performance-proven implementation. The paper is explicit that several hard questions remain open: who governs credential issuers, who sets TTLs, how privacy-preserving lookup affects latency, what happens when adaptive resolvers fail, and how registry operators avoid becoming rent-seeking toll booths with better diagrams.

The familiar failure mode: agents need more than an address

The web’s basic discovery model is comfortable because it hides a lot. A user types a domain, DNS maps it to an address, TLS helps establish that the server controls the relevant domain, and the application does the rest. This works well enough for websites and APIs whose identities, endpoints, and governance boundaries are relatively stable.

AI agents make that assumption awkward.

An agent is not just an endpoint. It may be a task performer, a negotiator, a workflow delegate, a compliance-bound actor, or a transient service spun up for a narrow job. It may move between regions, expose different capabilities under different policies, require fresh credentials, route requests to specialised model backends, or operate under a trust framework set by an enterprise, marketplace, regulator, or consortium.

That is why the NANDA paper starts from a useful diagnosis: the problem is not simply “how does one agent find another?” The harder problem is how an agent finds another agent and knows enough to decide whether interaction is safe, authorised, fresh, private, and operationally sensible.

A plain address record cannot carry that burden. Nor should it. The paper’s architecture is built around that restraint.

NANDA’s core move is separation of concerns, not another mega-registry

The proposal divides agent discovery into three layers:

This is the paper’s most important contribution. The lean index stays small because it does not try to describe the agent. It points to where the description lives. AgentFacts carries the richer claims. Adaptive resolution handles the fact that endpoints are operational facts, not eternal truths.

That structure matters because agent metadata changes at a different rhythm from agent identity. A company’s “translation assistant” may keep the same name and identifier while its model backend, supported languages, latency budget, audit status, endpoint cluster, telemetry settings, or authentication requirements change repeatedly. If every such change hits the global index, the index becomes the bottleneck it was meant to remove.

The authors therefore propose a minimal index record, roughly framed around small signed records of about 120 bytes, with dynamic metadata pushed outward to AgentFacts. The paper claims this separation can reduce index write load by roughly $10^4$ compared with designs that push dynamic state into the core lookup layer. That number should be read as an architectural estimate, not as a benchmark from a deployed global system.

The principle is still sound: put the slow-changing thing in the shared index; put the fast-changing thing somewhere it can change without asking the whole world to synchronise.

AgentAddr is the handshake, not the conversation

The paper’s AgentAddr object is the lean record returned by the index. It can include an agent identifier, human-readable name, primary facts URL, private facts URL, adaptive resolver URL, TTL, and signature. Its job is to bind an agent identity to the locations where richer metadata or routing instructions can be found.

That makes AgentAddr more than a DNS record but less than a full service manifest. This middle position is deliberate.

A client can use the record in several ways:

For a business reader, the implication is subtle but important. NANDA does not assume every agent should be equally public, equally reachable, or equally governed. It supports a “quilt” model: native public agents, enterprise agent stores, government or jurisdictional registries, Web3/DID-style agent markets, and protocol-specific registries can all be visible through a shared discovery fabric without surrendering all governance to one central directory.

That is a sensible concession to reality. Enterprises will not publish every internal agent into a fully open global registry because a white paper smiled warmly at interoperability. They will expose some agents directly, hide others behind enterprise registries, and require different credential policies by workflow, jurisdiction, and risk tier. NANDA’s quilt model acknowledges this instead of pretending that decentralisation will politely delete compliance departments.

AgentFacts turns metadata into something clients can verify

The paper’s second major mechanism is AgentFacts: a JSON-LD metadata document signed as a W3C Verifiable Credential. It is intended to describe the agent’s capabilities, endpoint options, usage formats, security requirements, telemetry, certifications, evaluations, audit trails, and revocation status.

The distinction from ordinary agent descriptors matters. A descriptor says, “this agent can do X.” A credentialed descriptor says, “this agent claims X, and here is who signed or audited that claim, under what schema, with what expiry or revocation path.”

That is a different governance object.

The paper explicitly compares AgentFacts with Google’s A2A Agent Card. The authors do not treat A2A cards as useless. They position them as appropriate for stable server-hosted agents inside a marketplace, where fetching a /.well-known/agent.json file may be enough. AgentFacts adds several functions aimed at higher-volatility or higher-risk environments: TTL-scoped endpoint lists, verifiable credential signatures, third-party audited attributes, privacy-preserving metadata access, and revocation support.

A practical way to read the distinction:

This is where the paper is most business-relevant. As agent ecosystems mature, the central question will not be “Can the agent call an API?” It will be “On what basis did we allow this agent to call that API, and can we prove the basis was fresh at the time?”

AgentFacts is an attempt to make that question machine-readable.

TTL is the quiet governance lever

The paper spends meaningful attention on time-to-live values. That may sound like plumbing. It is actually policy wearing a networking hat.

TTL determines how long a client, gateway, or resolver can rely on a record before checking again. NANDA applies TTL logic across multiple layers: the index-level AgentAddr, the AgentFacts metadata, and routing metadata such as rotating endpoints or adaptive resolver tokens. The paper sketches broad ranges: static endpoints may have TTLs of one to six hours, rotating endpoints five to fifteen minutes, and adaptive routing tokens thirty to sixty seconds.

This is not just freshness. It is risk control.

A low-risk demo agent can tolerate stale metadata. A healthcare triage agent, financial execution agent, or compliance approval agent cannot. Credential expiry, revocation lists, cache duration, and endpoint validity all become part of the operational safety envelope.

The open question is who gets to set these values. The agent publisher? The enterprise registry? The credential issuer? A regulator? A client-side policy engine? The paper correctly leaves this unresolved because the right answer changes by domain.

For operators, the immediate takeaway is simpler: any serious agent platform will need TTL policy as a first-class design object. Leaving it to defaults is how stale trust becomes a post-incident slide deck.

Privacy-preserving discovery solves a problem most demos ignore

A standard lookup leaks interest. If a client fetches metadata directly from an agent’s domain, the agent or its infrastructure can observe that lookup. In everyday SaaS, this may be acceptable. In sensitive workflows, it may not be.

The NANDA proposal introduces a dual-path model: a PrimaryFactsURL hosted by the agent or enterprise, and a PrivateFactsURL hosted through neutral or decentralised infrastructure such as a third-party metadata host, IPFS-like storage, or privacy-preserving relay. The point is not to hide all interaction forever. The point is to let a client inspect metadata without immediately announcing itself to the target agent’s infrastructure.

That matters in obvious regulated cases and less obvious commercial ones. A procurement agent researching suppliers, a bank agent evaluating risk tools, a legal agent checking litigation support providers, or a security agent investigating suspicious services may not want its lookup trail exposed.

The trade-off is also clear. Privacy paths add dependencies and can add latency. The paper’s design-goal table flags privacy preservation as only partially supported and notes an added latency estimate of around 30–60 milliseconds. Again, this is not a full deployment benchmark, but it identifies the right tension: privacy is not free, but neither is leakage.

The business decision is not “always use the private path.” It is to classify workflows by sensitivity and define when direct lookup is acceptable, when private metadata access is required, and when endpoint engagement must happen only after authentication or proxying.

Adaptive resolution is where agent infrastructure starts looking like traffic engineering

Agents will not always sit behind one stable endpoint. They may require geo-aware dispatch, load balancing, failover, DDoS shuffling, capability-specific routing, or temporary session-bound endpoints. The paper’s AdaptiveResolver component handles this layer.

In the proposed flow, the index can return an adaptive resolver URL inside AgentAddr. A client can then call that resolver, which may inspect request context and return a suitable endpoint or temporary token. The resolver may route based on region, load, requested capability, threat signals, or policy constraints.

This is not conceptually exotic. It resembles patterns already familiar from CDNs, service meshes, reverse proxies, and edge routing. The agent-specific twist is that routing may be tied to capability and trust, not merely latency and uptime.

For example, a translation agent may route real-time audio to a low-latency specialised backend while batch summarisation goes to a cheaper cluster. A financial compliance agent may require a credentialed endpoint in a specific jurisdiction. A high-risk request may be routed through a hardened gateway with stricter logging.

The paper is right to separate this from the index. If routing logic lives inside the global discovery layer, every operational adjustment becomes a registry problem. If routing is delegated to signed adaptive resolvers, operators retain flexibility.

But the failure mode is obvious: the adaptive resolver becomes critical infrastructure. If it goes down, lies, routes unfairly, or cannot be audited, the elegant architecture degrades into a very modern single point of failure. The paper names this as an open issue: fallback paths, prevalidated routing, fairness, and mission-critical guarantees remain unresolved.

That honesty is useful. The diagram is not the system.

The paper’s evidence is architectural specification, not empirical validation

There are no model accuracy tables hiding in the appendix, no latency benchmark across global resolvers, and no production deployment study proving trillion-agent scale. The paper is a design proposal, marked as a work in progress and request for comments. Its figures and tables should be interpreted accordingly.

This distinction matters because infrastructure papers can sound more finished than they are. NANDA is valuable as a reference architecture and vocabulary. It is not yet a certified operating manual for the agentic web.

That does not make it unimportant. Early infrastructure design often matters precisely because it names the seams before platforms hard-code incompatible assumptions.

The business value is control-plane maturity, not “agent search”

The shallow business reading is that NANDA helps agents discover each other. True, but underpowered.

The better reading is that NANDA sketches a control plane for agent ecosystems. Discovery is only the first step. The real operational value is in deciding which agents are discoverable, which claims are trusted, which issuers count, which credentials must be fresh, which endpoint path is allowed, and which interactions can later be audited.

That has implications across several enterprise scenarios:

The commercial upside is not that everyone adopts the acronym NANDA. The upside is that enterprise buyers begin asking sharper procurement questions: Does this agent have signed capability metadata? Who issued it? How is it revoked? Can we fetch facts privately? What TTL governs endpoint validity? What happens if the adaptive resolver fails? Can we audit the decision path later?

Those questions are boring in the same way accounting controls are boring. Then money moves, something breaks, and suddenly everyone becomes a philosopher of audit trails.

What Cognaptus infers, and what the paper directly shows

It is useful to separate the paper’s claims from business inference.

The paper directly proposes a layered architecture: lean index, signed AgentAddr records, AgentFacts as credentialed JSON-LD metadata, adaptive routing, privacy-preserving metadata lookup, and federated deployment models. It also identifies design goals, trade-offs, status maturity, deployment options, and open questions.

Cognaptus infers that the highest near-term relevance is not a public trillion-agent internet. That may arrive, or it may remain conference-weather for some time. The nearer business problem is cross-boundary agent governance inside and between enterprises. Companies already struggle with API sprawl, identity governance, vendor risk, auditability, and service discovery. Agents add autonomy, delegation, and capability claims to that mess. Naturally, the mess has filed for promotion.

A NANDA-like architecture could become useful even before any universal public index exists. Enterprises can adopt the pattern internally: lean registry entries, signed metadata manifests, credential issuers, revocation policy, TTL rules, private lookup for sensitive workflows, and adaptive routing for agent endpoints. The public standard can come later. Internal discipline does not need to wait for universal enlightenment.

What remains uncertain is adoption. Infrastructure standards win through network effects, institutional trust, implementation convenience, and boring operational reliability. A clean architecture alone is not enough. The paper recognises this through its open questions around governance, terminology, discovery visibility, TTL policy, delegation, adaptive resolver reliability, privacy enhancements, and monetisation.

Boundaries: where the proposal should not be oversold

The first boundary is empirical. The paper includes architectural claims and design estimates, but not a deployed global benchmark. Phrases such as “sub-second revocation” or “trillion-agent scale” should be treated as design targets unless and until independent implementations validate them.

The second boundary is governance. Verifiable credentials are only as useful as the issuer ecosystem behind them. A signed claim from an untrusted issuer is not trust; it is typography with a keypair. Real deployments need issuer accreditation, revocation reliability, cross-signing rules, dispute handling, liability assignment, and client-side policy.

The third boundary is privacy. A PrivateFactsURL can reduce direct lookup leakage, but it introduces another host, another dependency, and potentially another observer. Timing analysis, caching behaviour, relay trust, and metadata correlation remain practical concerns.

The fourth boundary is complexity. Agent developers will not happily implement elaborate credential chains, TTL policy, adaptive resolvers, and privacy paths unless tooling makes the default path tolerable. Good standards fail when the secure path requires heroic paperwork from ordinary engineers.

The fifth boundary is economics. Registries, metadata hosts, credential issuers, and adaptive resolver operators must be funded somehow. If the funding model rewards gatekeeping, the “open agent internet” becomes an airport lounge with an API.

The real message: agent interoperability is becoming institutional infrastructure

NANDA’s value is not that it solves every problem. It does not. Its value is that it places the problems in the right layers.

Identity belongs in a lean, signed index. Rich claims belong in verifiable metadata. Routing belongs in dynamic, policy-aware resolvers. Privacy requires alternative lookup paths. Trust requires credential issuers and revocation. Governance cannot be sprinkled on top after the agents have already started negotiating contracts, moving money, and opening tickets in production systems. Charming idea, terrible incident report.

For enterprises, the immediate lesson is practical. Start treating agent discovery as an infrastructure discipline, not a product feature. Build registries. Sign metadata. Define issuer trust. Set TTL policy. Separate public discovery from private lookup. Audit who allowed which agent to do what, based on which facts, at which time.

Whether NANDA becomes the standard is less important than whether the industry absorbs its architectural warning. The agentic web will not run on vibes, endpoint URLs, and a few enthusiastic JSON files. It will need a backbone.

Preferably one with revocation.

Cognaptus: Automate the Present, Incubate the Future.