DNS gave networked services names that survived an IP change. What does the same job for AI agents?

AI agents can already do real work. They call APIs, use tools, operate in marketplaces, work with payment systems, and talk to other agents.

But ask one stupidly basic question: what is the agent’s actual identity?

Things get fuzzy.

One agent might have a GitHub account, an API endpoint, an MCP server, a marketplace profile, a social handle, a payment address, and a config file.

Seven references. No obvious identity.

Each one points to part of the agent, or to wherever it happens to be running today. None gives it a persistent public anchor that can survive a change of host, framework, model, or interface.

DNS solved a version of this problem for networked services years ago. Machines moved, IP addresses changed, systems were rebuilt… and the domain stayed put.

Could an agent have the same kind of anchor?

I am not talking about giving every agent a homepage. I mean a stable name connected to machine-readable records: who operates it, what it does, its official endpoints, supported tools and protocols, permissions and limits, policies and verification records, how software can reach it, and whether the identity is active, transferred, suspended, or retired.

A domain would not make the agent trustworthy by magic. It would not authenticate every action. We still need credentials, signed requests, authorization, reputation, security reviews, and other trust systems.

But all of those systems need a stable identity to point at.

That is the missing piece.

If an agent changes models or moves to a new host, why should it have to throw away the identity and history it has already built?

This is what we are exploring through Headless Domains: namespaces built around what is actually running.

.agent names the actor.

.chatbot names the conversation.

.boss names the operator.

.factory names the production system.

.protocol names the rules.

.bpo names the work.

.manifest names the machine-readable contract.

Forget websites for a moment. Does software acting across several systems need one persistent name and one standard place to publish its identity records?

And if it does, how would you build it?

Would you extend DNS with existing record types? Use well-known files or DIDs? Attach identity to an API or MCP endpoint? Build something else entirely?

Disclosure: I am working on Headless Domains, so yes, I am close to the problem. Agreement is nice, but I am more interested in the technical objection that breaks the idea.

https://headlessdomains.com/