.boss is live / claim your leadership name today Search .boss
Back to blog
// POST 042 / 133

What Is a Headless Domain? A Practical Guide to AI Agent Identity

Published September 3, 2026 Updated October 2, 2026
What Is a Headless Domain? A Practical Guide to AI Agent Identity

Traditional domains were built for people using browsers. Headless domains are built for software that can act.

A headless domain gives an AI agent, service, protocol, production system, operator, or business process one persistent public identity that people and software can discover and inspect.

This guide explains the idea, helps you choose among the 14 live namespaces, and shows you how to turn an available name into a working identity.

1. So... what is a headless domain?

A traditional domain usually helps a person find a website. A headless domain names the software, system, or process itself.

That name can connect to machine-readable manifests, official endpoints, declared capabilities, permissions, policies, verification records, payment information, and current lifecycle status. Instead of piecing together a GitHub account, marketplace profile, API URL, and payment address, another person or agent gets one public identity to inspect first.

The software underneath may change models, hosts, tools, interfaces, or marketplaces. The name stays put. Its records can change as the system changes.

A headless domain does not run the software, and registering one does not make the software trustworthy. It gives the software and its public records one identity that people, applications, and other agents can return to.

Simple.

The larger argument lives in Name What Runs, the Headless Domains category manifesto. This guide stays closer to the ground: what a headless domain is, which namespace fits what you run, and what to do after you find an available name.

2. Why ordinary domain workflows fall short for agents

Most domain products still assume a person will open a browser, search for a name, complete checkout, configure the records, and return later to manage everything.

Agents work differently. They call APIs, use tools, run workflows, speak with other agents, support customers, recommend products, and move value without waiting for a person to click through every step.

Before one system relies on another, it needs answers to some fairly basic questions:

  • What is this agent, service, or process?
  • Who or what operates it?
  • What is it allowed to do?
  • Which endpoints and records are official?
  • Where are its capabilities and policies published?
  • How can it be reached, called, verified, or paid?
  • Is the identity active, transferred, suspended, or retired?

A marketplace profile may answer one question. An API URL, repository, social handle, payment address, or MCP endpoint may answer another. Soon you are holding six disconnected labels and trying to decide which one is official.

Usually, none of them is.

A headless domain gives those separate surfaces one public anchor. Authentication still confirms credentials. Authorization still controls what can happen. Security reviews, reputation systems, and payment checks keep their own jobs. The domain gives all of them a consistent identity record to inspect.

3. Choose the namespace that matches the job

Not everything that acts is the same kind of thing. Headless Domains has 14 live namespaces for actors, roles, systems, projects, and forms of work.

Namespace What it names Best fit
.agent The autonomous actor AI agents, agent teams, operator agents, marketplace agents, and software that acts across tools and platforms.
.chatbot The conversation Conversational AI, copilots, customer-support assistants, sales bots, voice agents, and chat-first products.
.boss The operator Founders, executives, creators, managers, consultants, manager agents, delegation systems, and command centers.
.factory The production system Manufacturing operations, software build systems, deployment pipelines, maker platforms, production agents, and services that turn inputs into outputs.
.protocol The rules Open standards, APIs, networks, SDKs, coordination methods, payment systems, identity systems, and interoperable infrastructure.
.bpo The repeatable work Business-process providers, automation teams, customer-support operations, accounting, recruiting, claims, research, sales operations, and managed workflows.
.manifest The machine-readable contract Agent builders, protocol designers, and product teams publishing capabilities, configuration, permissions, policies, tool discovery, or service contracts.
.c The maker Creators, communities, companies, portfolios, and the people or groups behind a product.
.zen The focused project Mindfulness resources, creative studios, and tools built around focus or thoughtful work.
.yolo The experiment Creative experiments, travel journals, and community projects that may grow beyond their first form.
.1 The flagship A personal home, main project, or brand that a person or team wants people to find first.
.done The delivery Service delivery, project portfolios, workflow tools, and work organized around finished results.
.tx The transaction Checkout, settlement, exchange, and other services that move value between people or agents.
.hey The introduction Personal, community, product, and service identities built around a friendly point of contact.

In plain English: use .agent for the actor, .chatbot for the conversation, .boss for the operator, .factory for the production system, .protocol for the rules, .bpo for the work, and .manifest for the machine-readable declaration behind a product or service.

Use .c for the maker, .zen for a focused project, .yolo for an experiment, .1 for a flagship, .done for the delivery, .tx for a transaction service, and .hey for a friendly point of contact.

Still deciding? Compare all 14 namespaces, or search across them.

4. Start with the route that fits you

Founders, operators, and teams

Begin with one question: what are you naming? It may be an agent, conversational product, operator, production system, protocol, managed process, or machine-readable contract.

Once that is clear, compare the namespaces, search for an available name, and use the Getting Started guide for registration and initial setup.

Agent builders and developers

The developer documentation covers registration, lookup, resolution, identity records, APIs, SDKs, and agent integrations.

If you would rather inspect the machinery yourself (fair), open the public OpenAPI specification or the Headless Domains MCP interface.

Autonomous agents

Begin with llms.txt, the machine-readable map of the site. Then read SKILL.md for repeatable workflows.

Those resources show an agent how to search for a name, inspect records, use the API, authenticate, handle payment-aware requests, and take part in its identity lifecycle within the limits set by its operator.

Marketplaces, directories, and verifiers

Use the Headless Domains lookup to inspect a registered name and its records. You can also explore public agent identities at agents.headlessdomains.com.

The name is not an automatic stamp of trust. It is the place where identity claims, operator information, technical records, endpoints, and independent evidence can meet.

5. Bring your own agent

Headless Domains is not another closed chatbot or agent-hosting platform. The approach is exactly what it sounds like: Bring Your Own Agent.

Your agent can run locally, in the cloud, through an orchestration platform, or on infrastructure you control. Headless Domains does not dictate the model, runtime, interface, or marketplace.

It gives the software a persistent identity and resolution layer. Change the tools underneath, and the agent, service, or system does not have to rebuild its public identity from zero.

6. What the name can publish

The records depend on what you are naming. A headless domain can point people and software to:

  • agent.json, an Agent Card, or other structured identity data
  • SKILL.md files and capability documentation
  • OpenAPI specifications, MCP endpoints, webhooks, and service endpoints
  • Operator, organization, and proof-of-control information
  • Permissions, operating limits, policies, and authentication instructions
  • Payment routes, supported payment methods, and renewal information
  • Directory profiles, marketplace listings, and supporting proof links
  • Current lifecycle status, including active, transferred, suspended, or retired

Use .manifest when the manifest, configuration, capability declaration, policy set, or machine-readable service contract is the main thing you want to name.

Choose another namespace when the manifest supports a named actor, operator, production system, protocol, conversation, or business process. An agent might use research.agent as its public identity, for example, then publish structured capabilities through records linked from that name.

7. Turn an available name into a working identity

  1. Decide what you are naming. Pick the person, actor, project, service, system, or work that needs a persistent identity.
  2. Choose the namespace. Match the name to the job it performs so people and machines know what they have found.
  3. Search for the name. Use the domain search across all 14 live namespaces.
  4. Register it. People can use the Headless Domains interface. Agents and developers can use agent-readable workflows, APIs, and supported machine-payment flows. Choosing .agent? See what you can register today, try a public lookup, and check how it differs from the proposed ICANN .agent.
  5. Publish the records. Add the manifests, endpoints, capabilities, permissions, policies, verification data, and anything else the identity needs.
  6. Keep them current. The name provides continuity. Its records should reflect the system's actual operator, capabilities, endpoints, and status.

Registration is the start, not the finish. The useful part is the identity record another person or machine can inspect when it needs to stop guessing.

Already have your name? Use the seven-step post-registration checklist to check the profile, records, contact route, and service it points to.

Where to go next

Choose the next page by the job in front of you:

Name what runs.