.boss is live / claim your leadership name today Search .boss
Back to blog
// POST 001 / 094

Name What Runs: The Manifesto for Persistent Identities on the Agentic Web

September 2, 2026 / / AGENT IDENTITY
Name What Runs: The Manifesto for Persistent Identities on the Agentic Web

The internet knows how to name pages, companies, products, creators, and communities.

Now software is starting to act.

Agents call APIs, coordinate with other agents, recommend products, buy services, move between platforms, and represent people or organizations. Chatbots speak with customers. Production systems turn inputs into outputs. Protocols coordinate activity across networks. Business processes mix human judgment with autonomous execution.

Most of them still operate behind temporary identifiers.

A GitHub repository. A marketplace listing. A vendor account. An API URL. A wallet address. An MCP endpoint. A social handle. A name that exists only inside somebody else’s platform.

Each one may be useful, but none is automatically the public source of truth for the actor or system behind it.

The agentic web has an identity gap.

Headless Domains exists to close it.

The Identity Gap Behind Autonomous Software

Take one production agent. It might have one name in a marketplace, another inside an orchestration platform, tools exposed through an MCP server, APIs running from a hosted endpoint, a wallet for payments, and documentation under its operator’s domain.

Which identity is official? Who runs it? Which endpoint is current? What is the agent allowed to do? Where are its policies? And how can another agent know that the listing, endpoint, payment route, and operator claim all belong to the same actor?

When those answers live in separate systems, every new interaction starts with guesswork. That is a bad foundation for software expected to transact, delegate, or act without constant supervision.

Marketplace profiles disappear. Endpoints move. Models get replaced. Vendors change their URL structures. Teams migrate to new stacks. The software can keep running while its public identity breaks into pieces.

Autonomous software needs a durable anchor.

What Is a Headless Domain?

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 needs to inspect:

  • Who or what operates the identity
  • What it does
  • Where its official endpoints live
  • Which capabilities it declares
  • Where its machine-readable files are published
  • How it can be called or paid
  • Which policies apply
  • What proof links are available
  • Whether the identity 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 local machine, cloud server, agent platform, or orchestration service. A headless domain does not execute it. The domain gives the code, records, interfaces, and operator claims one stable public reference.

Nor does it replace authentication, authorization, enterprise IAM, reputation systems, security review, or payment verification. Those systems still have their own jobs. The headless domain provides the identity and discovery layer that helps them agree on which actor they are evaluating.

The execution layer stays wherever the builder chooses. The public identity carries the machine-readable pointers other systems use to find and understand it.

Name What Runs

The first web gave pages addresses.

The agentic web must also name the things that act.

That is the 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 an endpoint or a wallet.

A .agent identity gives the actor a public anchor. Its operator, manifests, capabilities, endpoints, payment information, policies, and current status can all point back to the same name.

Name the Conversation: .chatbot

Support widgets become voice assistants. Sales bots move into messaging apps. Tutors and personal assistants outgrow the interfaces where they started.

The window can change without forcing the identity to change with it.

A .chatbot name gives a conversational product a recognizable public identity outside any one app or platform. It fits customer support assistants, sales bots, voice and messaging companions, embedded helpdesk AI, and other conversational systems that need a durable machine-readable record.

Name the Operator: .boss

Autonomous systems still have people and organizations behind them. Someone sets the limits, accepts responsibility, and decides what happens next.

That operator may be a founder, executive, creator, consultant, manager agent, or the command layer coordinating a fleet. A .boss identity makes that role visible and gives team dashboards, delegation systems, and command centers a clear public reference.

The systems should be recognizable. So should whoever runs them.

Name the Production System: .factory

Factories are no longer confined to physical buildings.

A software build system is a factory. So is a deployment pipeline, content engine, model workflow, robotics operation, fabrication shop, or manufacturing line. Each takes inputs and repeatedly produces an output.

.factory names the system where that production happens, whether the work is physical, digital, or both.

Name the Rules: .protocol

Protocols tell systems how to communicate, authenticate, exchange data, reach agreement, and move value. Yet the specification may sit in one place, governance in another, SDKs in several repositories, and official endpoints somewhere else again.

A .protocol identity gives those rules a canonical public home. It can connect an open specification to its versions, governance, SDKs, reference implementations, and official services.

This namespace is built for agent coordination standards, APIs, payment and identity networks, messaging systems, and the technical rules that allow independent systems to 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 that combine people, automation, and agents. The provider may change its tools without changing the process customers rely on.

A .bpo identity names that process directly. It centers the repeatable service rather than the company alone.

Persistent Does Not Mean Frozen

Persistent identity does not mean nothing changes. Useful systems evolve.

Models get upgraded. Capabilities expand. Endpoints move. Operators change. Policies are revised, payment methods are added, and old integrations are retired.

The name remains stable while the records attached to it reflect the current state.

That is persistence: continuity without pretending the underlying system is immutable. 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 does not prove every attached claim, and a public manifest is no substitute for technical verification.

Identity gives us an inspection point. Trust comes after the evidence is examined.

The owner may declare information in a public record. A technical system may verify that a file, record, or endpoint exists. An independent organization may evaluate the actor and publish an endorsement. These are different kinds of evidence, and they should not be blurred together.

The headless domain gives those 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.

Built for Software-Operated Identity

Traditional registrar workflows assume a person will open a browser, complete checkout, configure records, and remember to return for renewal.

Agents need a different operating model.

Headless Domains lets agents and developers search, register, manage, and discover names through programmatic workflows. They can publish machine-readable records for other systems to inspect without depending on a human-readable profile.

The point is not to give agents unusual domain extensions. It is to let software take part in its own identity lifecycle while keeping operator accountability, access controls, auditability, and recovery in place.

The agent can operate the identity. The person or organization remains accountable for the actor. Both point to the same public source of truth.

The Headless Domains API supports programmatic search, registration, management, and discovery. Its payment documentation also covers autonomous registration and renewal through MPP.

One Layer in an Open Agent Stack

No single protocol will build the agentic web.

MCP exposes tools. A2A supports communication between agents. OpenAPI describes APIs. IAM controls internal access. On-chain registries publish identity or reputation records. Payment protocols authorize and settle transactions.

These are separate jobs:

  • Names create continuity.
  • Manifests publish context.
  • Protocols enable interaction.
  • Authentication confirms credentials.
  • Authorization controls action.
  • Reputation records history.
  • Payments move value.

A headless domain connects these layers without claiming to replace them.

The goal is not another closed profile that traps an agent inside one platform. The goal is a public identity every relevant surface can point back to.

The Name What Runs Principles

We believe:

  1. Anything that acts across systems should be nameable.
  2. An identity should survive a change of interface, model, host, or marketplace.
  3. Public identity records should be readable by people and software.
  4. A name should point to evidence that can be inspected, not demand blind confidence.
  5. The operator, organization, or accountable party should be visible.
  6. Identity, authentication, authorization, reputation, and payment are distinct layers.
  7. Lifecycle state should show whether an identity is active, transferred, suspended, or retired.
  8. Agents should be able to operate their identities programmatically within clear controls.
  9. Namespaces should tell people and machines what kind of actor, system, protocol, or process they have found.

What We Are Building

Headless Domains started with one obvious problem: agents were appearing across platforms without a durable identity connecting their public surfaces.

.agent made the gap visible. Building it exposed the larger category.

The agentic web also includes conversational products, operators, production systems, protocols, and business processes. They do different work, but all need a public identity that survives changes to the interface around them.

That is what we are building.

This is not a bag of speculative names, and it is not another profile locked inside one company’s platform.

It is an agent-first naming and public identity layer for the software, systems, and processes now operating across the internet.

Name What Runs

Start with one question:

What do you run?

An autonomous actor? A conversational product? A company, team, or fleet of agents? A production system? A protocol? A repeatable business process?

Give it an identity that people and machines can recognize, inspect, and return to.

Name the actor.

Name the conversation.

Name the operator.

Name the production system.

Name the rules.

Name the work.

Name what runs.

Search the live namespaces

#Agent identity #machine-readable identity #agentic web