How to Read an Agent Identity Record
An agent identity record is the public inspection file set that tells another agent which name is canonical, who operates the agent, what the agent can do, where callers can connect, and how each claim can be checked. Read the record like a verifier: compare the DNS TXT data, directory profile, manifest, endpoints, owner fields, capability list, and proof links before any tool call or transaction.
For HeadlessDomains.com, the record can combine a .agent name, TXT pointers, agent.json, SKILL.md, OpenAPI, MCP, A2A, payment policy, and a public profile. The name is headless, so agents can inspect records through command-line and API workflows rather than waiting for conventional browser support.
Field-by-Field Reading Table
| Field | What to read | Healthy signal | Warning sign |
|---|---|---|---|
| Canonical name | The .agent name, profile slug, manifest domain, and display name. | The same name appears across the TXT record, profile, and manifest. | The profile uses only an alias, marketplace title, or copied brand label. |
| DNS TXT data | TXT strings that point to the manifest, profile, proof source, or verification policy. | TXT values point to current HTTPS resources and match the public profile. | TXT points to stale hosts, private URLs, or a manifest controlled by another operator. |
| Directory profile | The reader-facing profile page for owner, purpose, status, and links. | Profile copy matches the machine-readable manifest and names the operator clearly. | Profile claims capabilities or endpoints that the manifest does not publish. |
| Owner fields | Organization, support route, security contact, policy URLs, and review date. | A named operator can answer for support, abuse, security, and lifecycle status. | No accountable owner, no contact path, or policy links that point elsewhere. |
| Capabilities | Public action IDs, input modes, auth flags, limits, and human-approval points. | Capabilities are narrow, named, and connected to docs or playbooks. | Broad claims such as full autonomy with no auth, limits, or review path. |
| Endpoints | OpenAPI files, MCP endpoints, A2A Agent Cards, webhooks, docs, and status pages. | Each endpoint is official, versioned, and aligned with the owner domain. | Endpoint domains differ from the owner or expose tokens inside URLs. |
| Verification | Signed manifests, JWKS URLs, TXT proof, profile matches, timestamps, and receipts. | Independent public fields agree before the caller connects or pays. | Proof is missing, dates are stale, or a payment route names a different receiver. |
Start With The Name And TXT Data
The canonical name is the first field to check because every later field should point back to the same named agent. Compare the .agent name, profile URL, manifest URL, and display name before reading capability claims. If those values disagree, pause before using any endpoint.
DNS TXT data works well for compact pointers and proof hints because TXT records carry character-string data; the DNS specification is the base reference for that record type. Treat TXT as a pointer layer, then fetch the profile, manifest, or proof URL that the TXT value names.
Compare The Directory Profile With The Manifest
The directory profile is the public page a human can scan. The manifest is the machine-readable version an agent can parse. A good profile and manifest should agree on name, owner, purpose, status, profile URL, contact route, and endpoint list.
Use the agent directory hub for the broader directory model, then compare agent directories and agent marketplaces when a platform listing tries to stand in for public identity.
Read Owner And Lifecycle Fields
Owner fields answer who is accountable. Look for organization name, support URL, security contact, abuse route, policy links, review date, active status, and retirement notes. A record that omits owner fields asks another agent to trust a domain string with no accountability route.
Lifecycle data is just as useful as launch data. Retired agents, renamed products, acquired teams, and revoked endpoints should be marked plainly so old integrations stop calling the wrong surface.
Review Capabilities And Endpoints
Capabilities should read like scoped public claims, not a sales pitch. Prefer named actions such as quote_request, inventory_lookup, or support_triage, then check whether auth, approval, spending, or policy limits are listed beside those actions.
Endpoints are where inspection becomes action. OpenAPI describes HTTP API contracts through the OpenAPI Specification. MCP publishes tool and context surfaces through the Model Context Protocol specification. A2A can publish peer-agent collaboration data through an A2A Agent Card. The identity record should connect each surface back to the same owner and name.
Verify Before A Call Or Payment
Verification is comparison across public surfaces. Compare the name, TXT pointer, profile, manifest, owner, endpoint domain, payment policy, and review date. The record earns trust when independent fields agree and every callable surface has a public owner route.
Do not treat a single green status badge as proof. Check whether the manifest is current, whether the endpoint is controlled by the named operator, whether payment metadata names the intended receiver, and whether support or security contacts are reachable before delegating work.
Example Agent Identity Record
A compact record can publish enough context for another agent to inspect the public surface before connection.
{"name":"atlas.agent","status":"active","dns_txt":["manifest=https://atlas.agent/.well-known/agent.json","profile=https://headlessprofile.com/atlas.agent"],"owner":{"organization":"Atlas Support Team","support_url":"https://atlas.agent/support","security_contact":"security@atlas.agent"},"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":{"jwks_url":"https://atlas.agent/.well-known/jwks.json","signed_manifest_url":"https://atlas.agent/.well-known/agent.json.jws","reviewed":"2026-05-21"}}Where HeadlessDomains.com Fits
HeadlessDomains.com gives the record a persistent identity anchor. A .agent identity can point to DNS TXT data, a directory profile, agent.json, SKILL.md, endpoint metadata, payment policy, and proof links so another agent can inspect one public path before delegation or payment.
Start by registering a .agent identity, then list the profile in the Headless Profile Directory. Keep the visible profile and machine-readable manifest aligned after owner, endpoint, capability, policy, or status changes.
Where To Go Next
For the discovery layer, read the public inspection layer for AI agents. For implementation examples, use agent.json examples and the Agent Identity Graph guide to connect names, files, endpoints, profiles, payments, and proof.
FAQ
What is the fastest way to read an agent identity record?
Start with the canonical name and owner, then compare DNS TXT data, directory profile, manifest, endpoints, and proof links. The record is stronger when those fields agree.
Is a directory profile enough by itself?
No. A profile is helpful for scanning, but a verifier should also check the TXT data, manifest, owner fields, endpoint domains, and proof links before using the agent.
How is DNS TXT data used in an agent identity record?
TXT data can publish compact pointers to the manifest, profile, verification policy, or proof source. Treat those values as public pointers that lead to fuller records.
What should not appear in an agent identity record?
Do not publish private keys, bearer tokens, wallet secrets, customer data, private hostnames, staging endpoints, or internal runbooks in a public identity record.
How often should the record be reviewed?
Review the record after any owner, endpoint, capability, payment policy, support, security, or lifecycle change. Production agents should also carry a visible review date.