Name What Runs: The Manifesto for Persistent Identities on the Agentic Web
The internet got very good at naming things you can look at: pages, companies, products, creators, communities.
Now software is doing things.
Agents call APIs, talk to other agents, recommend products, buy services, run workflows, and represent people or companies. Chatbots speak with customers. Production systems turn one thing into another. Protocols keep networks from dissolving into chaos. And business processes now mix human judgment with software that does not wait around to be clicked.
Most of them still operate under borrowed names.
A GitHub repository. A marketplace listing. An API URL, wallet address, MCP endpoint, vendor account, or social handle. These names are useful right up until the platform changes, the endpoint moves, or the company hosting the profile decides to rearrange the furniture.
Which one is official?
Often, the honest answer is that nobody knows. The identity is scattered across half a dozen systems, and every person or agent that encounters it has to piece the story together again.
That is the identity gap behind the agentic web.
Headless Domains exists to close it.
Autonomous software has an identity problem
Take one working agent. It may have one name in a marketplace and another inside an orchestration platform. Its tools sit behind an MCP server. Its APIs run somewhere else. Payments go through a wallet, while the documentation lives under the operator’s company domain.
So who runs it? Which endpoint is current? What is it allowed to do? Where are the policies? How does another agent know that the listing, wallet, endpoint, and operator claim belong to the same actor?
Guesswork.
That might be tolerable for a demo. It is a rotten base for software expected to spend money, delegate work, handle customer data, or act without somebody watching every move.
Marketplace profiles vanish. Vendors change their URL structures. Teams move to new stacks, models get replaced, and endpoints come and go. The software may keep running through all of it while its public identity breaks into pieces.
It needs a name that survives the move.
A public name for what runs
A headless domain is a persistent public identity for software, systems, protocols, operators, and processes.
It is not simply a website address. It connects one recognizable name to the records another person or machine may need to inspect:
- who or what operates it
- what it does and which capabilities it declares
- where its official endpoints live
- where its machine-readable files are published
- how it can be called or paid
- which policies and proof links apply
- whether it is active, suspended, transferred, or retired
For an agent, that record might connect agent.json, SKILL.md, llms.txt, OpenAPI, MCP, A2A, payment metadata, directory profiles, and operator information.
The code can stay on a laptop, in the cloud, inside an agent platform, or wherever the builder wants it. A headless domain does not run the software. It gives the software, its interfaces, its public records, and the people behind it one stable reference.
Nor does it replace authentication, authorization, enterprise IAM, reputation, security reviews, or payment verification. Those systems have their own jobs. The headless domain provides the identity and discovery layer that helps them agree on which actor they are looking at.
The execution can move. The name stays put, and the records move with the execution.
Name What Runs
The first web gave pages addresses. The agentic web has to name the things that act.
That is the whole argument behind Name What Runs.
Name the actor: .agent
An agent may research, write, monitor, negotiate, support customers, call tools, coordinate workflows, or represent an operator. A marketplace label cannot hold that identity together. Neither can a wallet or an endpoint.
A .agent name gives the actor a public anchor. Operator details, manifests, capabilities, endpoints, payment information, policies, and current status can all point back to the same place.
Simple idea. Surprisingly absent.
Name the conversation: .chatbot
A support widget becomes a voice assistant. A sales bot moves into messaging apps. A tutor or personal assistant outgrows the interface where it began.
Why should it lose its identity every time somebody redesigns the little box around it?
A .chatbot name gives a conversational product a recognizable identity outside any one app. It fits customer support assistants, sales bots, voice companions, embedded helpdesk AI, and other conversational systems that need a public record machines can read.
Name the operator: .boss
Autonomous systems still have people and organizations behind them. Someone sets the limits, takes responsibility, and decides what happens when the software gets it wrong.
Yes, even the very autonomous ones.
That operator could be a founder, executive, creator, consultant, manager agent, or the command layer coordinating a fleet. A .boss identity makes the role visible and gives team dashboards, delegation systems, and command centers a clear public reference.
The system should be recognizable. So should whoever runs it.
Name the production system: .factory
Factories are no longer confined to physical buildings.
A software build system takes inputs and makes outputs. So does a deployment pipeline, content engine, model workflow, robotics operation, fabrication shop, or manufacturing line. Call the work digital, physical, or some unruly mix of the two. It is still production.
.factory names the system where that production happens.
Name the rules: .protocol
Protocols tell independent systems how to communicate, authenticate, exchange data, reach agreement, and move value. Yet the specification may sit in one place, governance in another, SDKs across several repositories, and the official endpoints somewhere else entirely.
A .protocol identity gives those rules one public home. It can connect a specification to its versions, governance, SDKs, reference implementations, and official services.
This is for agent coordination standards, APIs, payment and identity networks, messaging systems, and the technical rules that let strangers build things that somehow work together.
Name the work: .bpo
Customers do not buy an org chart. They buy the work.
Accounting, recruiting, customer support, claims, research, fulfillment, and sales operations are now delivered by teams made of people, automation, and agents. The tools may change next month. The process customers depend on should not lose its identity because somebody swapped the software underneath it.
A .bpo name puts the repeatable service at the center.
The identity gap reaches the work around those systems too: the files that describe a service, the transactions it handles, and the projects people build.
Name the declaration: .manifest
Capabilities change. So do policies, tool lists, and service configuration. If those declarations live in files scattered across a product, how does another system know which one is current?
A .manifest name gives the machine-readable contract its own public reference. The agent or service can keep its own identity; the declaration has a stable place to be found.
Name who makes it: .c
A creator, company, or community may operate several tools and projects. Those can change without erasing the people behind them. A .c name gives the maker a recognizable home, with pointers to its current projects, services, and records.
Name the focused project: .zen
A mindfulness resource may become an app. A creative studio may build a tool of its own. .zen gives a thoughtful project a steady reference while its format and the way people use it change.
Name the experiment: .yolo
Not every project begins with a ten-year plan. A creative experiment or community tool may start on a borrowed platform and grow beyond it. A .yolo name gives that work somewhere to go when the first version is no longer enough.
Name the flagship: .1
A person or team may have several ideas, but one they want people to find first. .1 can identify that flagship project, product, or brand. Its records can keep pointing to the right place as the project develops.
Name the delivery: .done
Work has a result as well as a process. .done fits a workflow tool, service-delivery system, or project portfolio built around what gets finished. The name can point to the current service and its record of delivery.
Name the transaction: .tx
Checkout, settlement, and exchange services move value between people and agents. The payment link may change; the service behind it still needs a name. A .tx identity can point to its operator, terms, and official transaction endpoints. The name does not move the money.
Name the introduction: .hey
A person, community, or communication-focused service may need a friendly first point of contact. A .hey name can lead people to the project and its current ways to connect. The conversational software itself may have a .chatbot identity; .hey names the broader invitation.
Persistence without pretending nothing changes
Persistent does not mean frozen. Useful systems evolve.
Models get upgraded. Capabilities expand. Endpoints move, operators change, policies are rewritten, payment methods are added, and old integrations are quietly taken out back.
The name remains stable while the records attached to it show what is true now.
That is persistence: continuity without paralysis.
And the more tools, platforms, protocols, and commercial relationships a system crosses, the more that continuity matters.
Identity comes before trust
A name does not make an agent safe. Registration is not a character reference, and a public manifest is no substitute for technical verification.
Identity gives us somewhere to look. Trust comes from what we find there.
The owner may declare information in a public record. A technical system may confirm that a file, record, or endpoint exists. An independent organization may inspect the actor and publish an endorsement. These are different kinds of evidence, and mixing them together helps nobody.
A headless domain gives the claims and proofs a stable place to meet.
Before an agent calls a tool, delegates work, shares data, follows a payment request, or relies on a marketplace listing, it should be able to trace that surface back to one canonical public identity.
Identity that software can operate
Traditional registrar workflows assume a person will open a browser, complete checkout, configure the records, and remember to come back for renewal.
Agents need another way in.
Headless Domains lets agents and developers search, register, manage, and discover names through APIs. They can publish machine-readable records that other systems inspect without depending on a human-facing profile.
The point is not to hand agents unusual domain extensions and call it a day. Software should be able to take part in its own identity lifecycle, while people keep control over access, accountability, audits, and recovery.
The agent can operate the identity. The person or organization behind it remains responsible. Same public name.
The Headless Domains API supports programmatic search, registration, management, and discovery. Its payment documentation also covers autonomous registration and renewal through MPP.
One part of an open agent stack
No single protocol is going to build the agentic web. Frankly, we should be suspicious of anyone claiming otherwise.
MCP exposes tools. A2A helps agents communicate. OpenAPI describes APIs. IAM controls internal access. Onchain registries publish identity or reputation records. Payment protocols authorize and settle transactions.
Different jobs:
- Names create continuity.
- Manifests publish context.
- Protocols make interaction possible.
- Authentication confirms credentials.
- Authorization controls what can happen.
- Reputation records history.
- Payments move value.
A headless domain connects these parts. It does not pretend to replace them.
We do not need another closed profile that traps an agent inside one company’s platform. We need a public identity that every relevant surface can point back to.
The Name What Runs principles
Here is what we believe:
- Anything that acts across systems should be nameable.
- An identity should survive a change of interface, model, host, or marketplace.
- Public identity records should be readable by people and software.
- A name should point to evidence that can be inspected. Blind confidence is not a feature.
- The operator, organization, or responsible party should be visible.
- Identity, authentication, authorization, reputation, and payment are separate jobs.
- Lifecycle status should show whether an identity is active, transferred, suspended, or retired.
- Agents should be able to operate their identities through software, within clear limits.
- Namespaces should tell people and machines what sort of actor, system, protocol, or process they have found.
What we are building
Headless Domains began with an obvious problem hiding in plain sight: agents were appearing across platforms without a lasting identity connecting their public surfaces.
.agent made the gap visible. Building it revealed the larger category.
The agentic web also has conversational products, operators, production systems, protocols, and business processes. Their work differs, sometimes wildly, but they share the same need for an identity that survives whatever interface happens to surround them today.
So that is what we are building.
Not a bag of speculative names. Not another profile locked inside one company’s database. A naming and public identity layer made for the software, systems, and processes now operating across the internet.
What do you run?
An autonomous actor? A conversational product? A company, team, or fleet of agents? A production system, protocol, or repeatable business process?
Give it an identity that people and machines can recognize, inspect, and return to.
Name the actor, the conversation, the operator, the production system, the rules, or the work.
Name what runs.