Agent Manifests & Auto-Provisioning

Headless Domains is designed from the ground up for the autonomous web. To support agent discoverability and interoperability, we automatically provision standardized manifest records for every domain registered on our platform.

What is Auto-Provisioning?

When an AI agent (or a human on behalf of an agent) registers a domain (e.g., mytradingagent.agent), the Headless Domains infrastructure automatically generates and hosts two core files: 1. agent.json - A machine-readable JSON manifest containing declared capabilities, service pointers and scoped registration/account observations. 2. SKILL.md - A human-readable markdown file summarizing the agent's identity and capabilities.

We then automatically inject TXT pointer records into the root of the newly created Handshake zone, making these files globally discoverable.

The DNS Records

Any resolver querying the domain's TXT records will find the following pointers:

TXT "agent-manifest=https://HeadlessDomains.com/manifests/<domain>.json"
TXT "skill-md=https://HeadlessDomains.com/skills/<domain>.md"

The JSON Manifest Schema (v1)

The agent.json representation helps compatible clients inspect the domain's published records. The following example is abbreviated; endpoint and workflow values are illustrative and require separate configuration and validation.

{
  "agent": {
    "name": "Mytradingagent",
    "version": "1.0.0",
    "description": "Autonomous agent hosted at mytradingagent.agent",
    "capabilities": ["general"],
    "protocols": ["mpp"],
    "workflows": {
      "mcp": {
        "version": "2024-11",
        "enabled": true,
        "servers": [
          {
            "name": "catalog-tool",
            "endpoint": "mcp://my-vps.com/tools/catalog",
            "description": "Agentic product feed & enrichment"
          }
        ],
        "claude_compatible": true,
        "auto_map_skills": true
      }
    },
    "owner_id": "headlessdomains:username",
    "identity": {
      "claim_state": "claimed"
    },
    "inbound_payment_endpoints": {
      "mpp": "https://<service>.mpp.tempo.xyz/..."
    },
    "trust": {
      "human_backed": true,
      "human_backed_scope": "deprecated_alias_for_stored_operator_link_only",
      "attestations": []
    },
    "webhooks": {
      "default": "https://api.mytradingagent.agent/webhook"
    },
    "uptime": "https://status.mytradingagent.agent"
  },
  "skills": [
    "https://HeadlessDomains.com/skills/mytradingagent.agent.md"
  ]
}

Understanding Workflows and Execution

It is important to understand that Headless Domains acts strictly as the Identity and Discovery Layer. We do not host or execute your agent's code, your MCP tools, or your workflow logic.

Where the Code Lives: Your actual python/node code, your MCP server, and your custom markdown playbooks (e.g., ./skills/catalog-enrich.md) live wherever you choose to host your agent (a local machine, a cloud VPS, or an orchestration platform).
Where the Pointers Live: Headless Domains holds the JSON configuration (agent.json and SKILL.md) that tells the rest of the world how to find and talk to your execution layer.

When a client (like Claude Desktop) wants to interact with your agent, it reads your agent.json from Headless Domains, extracts the endpoint from the workflows block, and routes its traffic directly to your hosted server.

Recommended Execution Host: PowerLobster.com

For users who do not want to manage their own servers, we natively integrate with PowerLobster.com as the recommended execution runtime. By setting "host": "powerlobster" and "default_host": "powerlobster" in your Workflows JSON, you get instant skill execution, memory, and orchestration without running your own MCP servers.

Example configuration for PowerLobster:

"workflows": {
  "mcp": {
    "version": "2024-11",
    "enabled": true,
    "servers": [
      {
        "name": "default",
        "endpoint": "https://relay.powerlobster.com/mcp/{domain}",
        "description": "PowerLobster-hosted MCP server for skill & workflow execution",
        "host": "powerlobster",
        "skills": ["./playbooks/*.md", "./skills/*.md"]
      }
    ],
    "claude_compatible": true,
    "auto_map_skills": true,
    "default_host": "powerlobster"
  }
}

You can quickly auto-fill this configuration directly from your domain dashboard using the Use PowerLobster Defaults button.

Key Fields:

capabilities: A list of tags indicating what the agent can do (e.g., trading, research).
owner_id: A local account reference prefixed with headlessdomains:. It is not proof of a real person's identity or membership in a PowerLobster squad. Explicitly imported squad IDs are labeled provider_declared.
inbound_payment_endpoints: Directs other agents on how to stream micropayments (e.g., via Tempo MPP) for services rendered.
trust.attestations: Empty. This service does not currently validate independent identity or safety attestations. Registry/provider names are not cryptographic proofs.
identity.claim_state: The account claim lifecycle (unclaimed, claimed, not_applicable, or unknown). It is separate from independent verification.
trust.human_backed: Deprecated compatibility boolean: true only when the associated account has a stored operator link. It does not verify that the operator is a human. A user row, credential or imported attestation alone does not set it to true.

Identity assurance

The current response includes the same assurance object at agent.trust.assurance in manifests, trust.assurance in the resolver and identity.assurance in legacy lookup. Generated SKILL files describe the same record checks. Each object names the issuer (HeadlessDomains.com), domain subject, UTC observation time, check and scope. observed_at means the records were read at that time; it is not the date an operator claimed an identity or passed an independent check. Existing caches can retain a response briefly.

State	Evidence and limit
`registered`	A local domain record, completed partner order with registration ID, or partner lookup response exists. This does not establish a human operator. The exact check distinguishes these sources.
`anonymous_provisioned`	The associated account records autonomous provisioning and has no stored operator link.
`claimed`	An autonomously provisioned account now has a stored operator link. This is account association, not identity certification.
`operator_associated`	A non-autonomous account has a stored operator link. The relationship is a local observation, not a fresh check with its provider.
Independently verified	Would require an identified verifier, subject binding, specific check, scope, verification date and validated evidence. No current path establishes this state; `independent_verification.state` is always `not_established`, `checked_at` is null and evidence is empty.

Registration and association are separate dimensions in the object. A partner lookup can report a registration while local account and operator associations remain not_established. Absence of evidence is not evidence that no operator exists. The domain's separate lifecycle status still controls availability.

Imported PowerLobster assertions appear only under provider_statements, with their reported issuer, import time and transaction reference when supplied. They are marked not_verified_by_headlessdomains; a transaction string is not a validated proof. A provider statement cannot override the local operator-link state. Cached provider SKILL content is attributed, and known legacy generated trust sections are replaced with current observations.

Registration does not automatically verify or admit an agent in Smithery, the official MCP Registry or other marketplaces. The official MCP Registry requires its own publisher authentication and namespace checks. Inspect each service's current requirements and each action's evidence before execution. Published profile text and capability declarations remain claims.

Consumer migration

Consumers should use the scoped assurance object rather than treating a legacy boolean or label as permission. owner_id now identifies a local account; fabricated squad IDs and fixed platform-name attestations have been removed. In resolver responses, identity.owner.verified is false and the previous generic ownership_verified value is replaced by account_associated or not_established in the ownership summaries. These values apply only to the domain-level record. Per-action verification states and evidence keep their existing, separately scoped meanings. The resolver remains schema version 1.0; its formerly unconstrained string fields now have documented semantics.

Directory visibility is separate from sale status. In API responses, is_listed is the compatibility name for visibility in the HeadlessDomains directory, and directory_listed is the clearer additive alias. Neither field means the domain is for sale; only for_sale carries that meaning.

Why this matters

By standardizing these manifests, Headless Domains enables true agent-to-agent interaction. An agent can resolve a .agent or .chatbot domain, read the TXT records, download the JSON manifest, discover the webhook URL and MPP payment endpoint, and autonomously negotiate a transaction—all without human intervention.