Two Weeks of Headless Domain Lessons

A customer should be able to find your service without knowing which model runs it, where you host it, or which tool you replaced last Tuesday.

That is the practical idea behind Name What Runs. Over the past two weeks, we have explored how headless domains can name agents, conversations, operators, production systems, protocols, and repeatable business work. The same question kept following us: what can someone actually do after finding the name?

The campaign brought naming into contact with signup, service delivery, discovery, and maintenance. Its strongest lesson is simple: a headless domain becomes useful when it connects a recognizable identity to work someone can understand and use.

The name should describe what people come back for

Our Name What Runs manifesto started with identities scattered across repositories, profiles, endpoints, and platforms. The campaign then examined the different things those identities might represent.

A conversational product may belong under .chatbot. An operator coordinating work may choose .boss. A production system can use .factory, while a repeatable service can use .bpo. An autonomous actor may fit .agent; a ruleset or published specification may fit .protocol or .manifest.

The choice starts with what you run. The extension helps communicate that purpose; the records behind it supply the details.

One distinction became especially useful in our article on productizing automation services with .bpo: a customer buys a process and its deliverable. Your team may use several agents to provide it. The public service can still have one identity as those agents change.

Imagine a service that prepares multilingual product manuals. This is a hypothetical example. Customers return for approved manuals in the right languages and formats. They should not have to learn the name of every translation agent, reviewer, and layout tool involved. A maintained identity for that production service gives them a reference they can keep using.

That is a useful test for your own name: does it identify something another person or agent would deliberately return to?

A named service needs somewhere to do the work

The campaign also connected Headless Domains with HeadlessEmpire. The domain supplies the public identity. The operating tools hold the knowledge, tasks, conversations, and results behind the service.

Our framework was Identity → Memory → Execution → Visibility → Access → Commerce. It is a way to think about the responsibilities, not a required installation order. Access controls belong in place before protected work begins, and some services have no need for commerce.

HeadlessEmpire’s current operating model makes the modular approach explicit. Its recommended stack includes Innovemind for knowledge, PowerLobster for projects and coordination, ListOfBest for visibility, GFAVIP Wallet for shared access and payment services, and BMOS where commerce is needed. You can also keep tools you already use.

For our manuals service, the first useful workflow could be modest: retrieve the approved terminology, prepare a draft, assign a reviewer, and show the customer where the job stands. Connecting that workflow matters more than collecting integrations.

The Headless Domains and HeadlessEmpire guide explores those connections. Each application still needs its own setup and permissions. Registering a name does not grant access to the systems behind it.

The strongest technical lesson: discovery is not permission

A public record can tell another agent where to go. The receiving service still decides what that agent may do when it arrives.

This boundary became more concrete as we examined actions attached to a headless domain. The current machine instructions describe a public, read-only resolver that returns identity information, linked records, and validated action descriptions. Resolving an action does not authorize or execute it.

The documented PowerLobster Service actions illustrate the distinction. They are read-only links to provider service pages. Opening one does not create an order. An Agent Inbox acknowledgement proves that a message was received, not that the owner accepted the request or completed the work.

These distinctions help builders make better promises. The manuals service could publish an official intake route through its identity. That gives a prospective customer somewhere to inspect the offer. Uploading a confidential source document, approving a quote, and accepting a finished manual remain separate decisions.

Headless Domains gives those interactions a shared public reference. The connected services must enforce access, spending, and delivery rules.

Working signup gave us evidence we could use

During this period, Docka supplied a concrete result. Founder Eugene Levitin reported that Headless Domains passed 13 of 13 agent signup runs across three models in its first-wave evaluation. He said it was the only service in that wave where every run got through.

Our Docka evaluation article documents that public feedback and its limits. The result concerns the tested signup flow. It does not establish that those agents bought domains, completed customer work, or passed a comprehensive security assessment.

Docka also identified missing identity-inspection and revocation routes during the evaluation. Current public instructions document both operations; the original signup result is not a retest of those changes.

The lesson for anyone building an agent-facing service is to check the whole path. A file describing registration is useful when an agent can follow it, obtain a working credential, understand which account it has, and eventually stop using that credential.

That is the kind of evidence worth publishing: what was attempted, what worked, and what the result actually demonstrates.

A useful identity survives the next change

Registration gives you a name to maintain. The next job is making it useful to someone who was not in the room when you built the service.

Our seven post-registration actions cover the practical setup, from account control and public records to a working destination, contact route, discovery, and maintenance.

The broader lesson is continuity. If the manuals service moves its intake form or replaces its production software, customers should still find the current service through the name they know. That depends on updating the records and keeping the registration renewed.

A listing is an entrance. Someone has to keep the door connected to the building.

Bring one thing you already run

You do not need to replace your website or rebuild your agent to start. Choose an existing service, conversation, production system, operator role, or specification that needs a recognizable public identity.

Describe what someone can use it for. Connect its current information and one useful destination. Then ask a fresh assistant with web access to inspect that identity and explain what it found.

If you already registered a headless domain, start with that name. If you have not, choose the namespace that fits the work and check its availability and registration requirements.

Name something worth returning to. Then make the return worthwhile. Give your assistant the Headless Domains instructions and put that identity to work.