What Is a Machine-Readable Identity Record?
A machine-readable identity record is a structured public record that lets software inspect who an AI agent represents, which files and endpoints are official, what actions are published, and which proof links support those claims. Instead of asking another agent to infer trust from a profile name, the record gives parsers a compact set of fields they can compare before calling, listing, paying, or delegating.
For HeadlessDomains.com, the record can start with a headless name and connect DNS TXT pointers, agent.json, SKILL.md, llms.txt, MCP, OpenAPI, A2A, payment policy, owner contact, lifecycle status, and public profile links. Agents can inspect those fields through command-line and API workflows; conventional browser resolution is only one user-experience layer for humans.
Machine-Readable Identity At A Glance
| Record layer | Question answered | Common artifact | Parser check |
|---|---|---|---|
| Name | Which public identity is canonical? | .agent or other Headless Domains name | Name matches profile, manifest, and endpoint metadata. |
| Owner | Who operates the agent? | Public profile and owner fields | Operator, support, security, and policy URLs agree. |
| Manifest | Which structured file describes the agent? | agent.json | Required fields are current and parse without custom scraping. |
| Capability | What actions are published? | SKILL.md, OpenAPI, MCP, A2A Agent Card | Actions are scoped, named, and tied to official endpoints. |
| Proof | Why should the record be trusted? | DNS TXT, signatures, JWKS, timestamps | Independent public fields point to the same identity. |
| Lifecycle | Is the agent active, limited, or retired? | Status, review date, revocation route | Callers can reject stale, suspended, or retired records. |
Why Agents Prefer Structured Records
Human-readable pages are useful, but agents benefit from predictable fields. A structured record turns identity into data: canonical name, operator, public profile, manifest URL, callable endpoints, supported protocols, payment policy, proof links, and review date.
That format helps an agent compare claims across surfaces. A marketplace listing can point to the same name as the manifest. An MCP server can publish metadata that matches the owner. A payment route can reference the same identity before value moves. The result is a public inspection path, not a scattered set of labels.
What Belongs In The Record
Start with fields that another system can parse without interpretation. The canonical name should be stable. The owner field should name the operator and support path. The manifest should publish official URLs. Capability fields should describe actions, constraints, auth expectations, and approval points. Endpoint fields should identify OpenAPI, MCP, A2A, webhook, checkout, or status URLs.
DNS TXT data is useful for compact pointers and proof hints because TXT records carry character-string data in the Domain Name System; the DNS specification is the base reference for that record type. Use TXT as a pointer layer, then let the manifest and profile carry richer context.
How It Differs From A Profile Page
A profile page explains an agent to people. A machine-readable record explains the same agent to software. Both should agree, but they serve different readers. The profile can use prose, category labels, screenshots, and supporting detail. The record should expose consistent values that a parser can compare without guessing.
This is also why a record is more useful than a marketplace display name alone. The public identity can outlive one platform listing and can travel across docs, tools, directories, checkout flows, and partner systems. For the broader architecture, use the Agent Identity Stack hub as the map for discovery, verification, calling, payment, and governance.
Example Machine-Readable Identity Record
A compact record can stay small while still giving another agent enough context to inspect the actor before interaction.
{"name":"atlas.agent","status":"active","profile":"https://headlessprofile.com/atlas.agent","owner":{"organization":"Atlas Operations","support_url":"https://atlas.agent/support","security_contact":"security@atlas.agent"},"records":{"agent_json":"https://atlas.agent/.well-known/agent.json","skill_md":"https://atlas.agent/SKILL.md","llms_txt":"https://atlas.agent/llms.txt"},"capabilities":[{"id":"supplier_search","auth_required":true},{"id":"quote_request","auth_required":true}],"endpoints":{"openapi":"https://api.atlas.agent/openapi.json","mcp":"https://api.atlas.agent/mcp","a2a_agent_card":"https://atlas.agent/.well-known/agent-card.json"},"verification":{"dns_txt":["agent-json=https://atlas.agent/.well-known/agent.json"],"jwks_url":"https://atlas.agent/.well-known/jwks.json","reviewed":"2026-05-21"}}How Protocols Fit Around The Record
OpenAPI can describe HTTP API contracts through the OpenAPI Specification. MCP can publish tool and context surfaces through the Model Context Protocol specification. A2A can publish peer-agent collaboration details through an A2A Agent Card.
Those protocols are interaction surfaces. The identity record binds them back to the same public actor. Before a caller follows an endpoint, it can compare the name, owner, manifest, policy, and proof links. If any surface names a different operator, unsupported domain, missing proof path, or stale status, the caller can stop before taking action.
Where HeadlessDomains.com Fits
HeadlessDomains.com gives agents a persistent identity anchor for machine-readable records. A .agent or other Headless Domains name can point to DNS TXT data, agent.json, SKILL.md, llms.txt, public profile data, endpoint metadata, payment policy, and proof links.
Teams can begin with one published identity, then keep every connected file aligned after owner, endpoint, capability, payment, policy, or lifecycle changes. Register a name through the .agent identity page, publish the structured record, and use the agent identity record reading guide to inspect it before calls or payments.
Related Reading
For a larger implementation path, read What Is Agent Identity?, then pair it with What Is agent.json? and What Is SKILL.md?. Those articles show how public identity, manifests, and repeatable workflows fit together.
FAQ
What makes an identity record machine-readable?
It uses predictable fields, URLs, timestamps, and status values that software can parse. The record should not depend on visual layout or a human reading a long profile page.
Is a machine-readable identity record the same as authentication?
No. The record tells a caller which public identity, owner, files, endpoints, and proof links belong together. Authentication and authorization still control access to protected systems.
Should every agent publish one?
Any agent that crosses app, API, marketplace, directory, partner, or payment boundaries should publish a record so other systems can inspect the actor before interaction.
Can a record include payment metadata?
Yes. Payment metadata can name checkout policy, receiver identity, receipt route, limits, and mandate references, but private keys, bearer tokens, wallet secrets, and customer data should stay out of the public record.
How often should teams update the record?
Update the record after owner, endpoint, capability, auth, payment, support, policy, or status changes. Add a review date so callers can identify stale records.