The Agent Identity Graph: Names, Files, Endpoints, Payments, and Proof
The agent identity graph is the map that connects an agent name, public manifests, workflow files, API contracts, tool endpoints, payment rails, directory profiles, and proof records into one inspectable path. Instead of treating each surface as a separate clue, the graph shows how a verifier moves from identity to capability to authorization context before interaction.
For HeadlessDomains.com, the graph can start with a .agent name and connect agent.json, SKILL.md, llms.txt, OpenAPI, MCP, payment metadata, TXT records, and public profile links. Agents can resolve and inspect these headless names through command-line and API workflows; conventional browser behavior is only a user-experience layer for people.
The Graph At A Glance
| Graph node | What it publishes | Connects to | Verification question |
|---|---|---|---|
| Name anchor | .agent or another headless agent name | Manifest, TXT records, profile, and proof links | Is this the public identity other surfaces reference? |
| agent.json | Operator, purpose, capabilities, endpoints, auth, proof, and status | SKILL.md, llms.txt, OpenAPI, MCP, payments, and directory profiles | Do the claimed files and endpoints point back to the same name? |
| llms.txt | A curated map of pages, docs, policies, and machine-readable resources | Hub pages, docs, API references, policy pages, and support routes | Can an agent find the right context without scraping the whole site? |
| SKILL.md | Workflow instructions, inputs, constraints, output format, and final checks | Callable endpoints, support policies, and human-approved playbooks | Does the workflow match the agent identity and published scope? |
| OpenAPI and MCP | HTTP API descriptions plus tools, resources, and prompts | Auth audiences, scopes, consent flows, and runtime logs | Is this the approved callable surface for this public agent? |
| Payment rails | x402 challenges, AP2 mandates, MPP payment metadata, receipts, and policy | Payee identity, purchase scope, endpoint, checkout, and dispute evidence | Does the payment request bind to the same agent and merchant context? |
| Proof and profile records | TXT records, signatures, public directory profile, review timestamp, and owner contact | Registries, partner allowlists, incident contacts, and lifecycle controls | Can a verifier detect stale, copied, or mismatched claims? |
Identity Graph Example
A useful identity graph does not force every protocol into one giant file. The graph keeps each artifact in the place where that artifact is strongest, then links those artifacts with stable identifiers and proof checks.
{"identity":{"name":"atlas.agent","canonical_url":"https://agents.headlessdomains.com/atlas.agent","operator":"Atlas Research"},"files":{"agent_json":"https://atlas.agent/.well-known/agent.json","skill_md":"https://atlas.agent/SKILL.md","llms_txt":"https://atlas.agent/llms.txt"},"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"},"payments":{"x402":"https://api.atlas.agent/x402","ap2_policy":"https://atlas.agent/policies/ap2","mpp":"https://api.atlas.agent/.well-known/mpp"},"proof":["dns_txt_points_to_agent_json","agent_card_signature_checked","payment_receipt_binds_to_identity","directory_profile_matches_operator"]}Why Names Sit At The Center
Names are the human-readable and machine-readable anchor for the graph. A profile page, endpoint, manifest, payment challenge, and directory listing can all describe an agent, but each surface can drift or be copied. The name gives verifiers one public reference to compare against before trusting the rest of the graph.
This is why the canonical identity pattern for AI agents and the marketplace-name warning belong in the same cluster. A marketplace label can help with discovery, but the graph should still point back to a durable public identity record.
How Files And Endpoints Connect
agent.json works as the structured manifest for the named agent. The manifest should identify the operator, purpose, official URLs, status, capability boundaries, proof links, payment metadata, and endpoint references. llms.txt then maps content and policy context so agents can read the right pages. SKILL.md provides the repeatable playbook: inputs, constraints, steps, output format, and checks.
OpenAPI and MCP belong on the callable side of the graph. OpenAPI gives machines and developers a contract for HTTP APIs. MCP gives clients a standard way to access tools, resources, and prompts. When a peer-agent workflow is present, an A2A Agent Card can publish capabilities and discovery metadata at a well-known path. The identity graph links those callable surfaces back to the same name and operator.
Where Payments Fit
Payment metadata should be connected to identity before value moves. x402 uses HTTP 402 so a server can challenge a client for payment and later grant access when payment verifies. AP2 focuses on agent-performed payment authorization with mandates, receipts, and dispute evidence. MPP covers machine-to-machine payment flows in the same broad family of agent commerce.
The identity graph does not replace payment verification. The graph gives the payment verifier context: which agent is paying, which merchant or endpoint receives value, which policy applies, which receipt path is official, and which proof record links the transaction to the public identity.
Implementation Checklist
- Choose one canonical headless name for the agent and keep that name stable across manifests, profiles, endpoints, and receipts.
- Publish agent.json with operator, purpose, canonical URL, status, endpoints, auth expectations, payment metadata, proof links, and owner contact.
- Publish llms.txt for curated content, policy, docs, and support links.
- Publish SKILL.md for repeatable workflows, required inputs, guardrails, output format, and final checks.
- Link OpenAPI, MCP, and any A2A Agent Card from the same identity record.
- Bind x402, AP2, MPP, mandate, receipt, and payment policy references to the canonical agent identity.
- Expose directory profiles and TXT proof records that match the manifest and operator.
- Log mismatches when a profile, endpoint, payment request, or copied file points to a different owner, status, or receiver.
Where Headless Domains Fits
HeadlessDomains.com gives this graph a persistent public anchor. A .agent identity can connect a name to agent.json, SKILL.md, llms.txt, TXT records, OpenAPI, MCP endpoints, payment metadata, proof records, and directory profiles. That gives agents one inspection path before they call tools, delegate work, or send payment.
Use the Agent Identity Stack hub for the wider framework: discovery, verification, calls, payment, governance, and lifecycle controls all become easier to inspect when each surface points back to one public identity graph.
Learn More
- The Agent Identity Stack
- llms.txt vs SKILL.md vs agent.json
- agent.json Examples for Public AI Agent Identity
- MCP vs A2A: Tools, Collaboration, and the Missing Identity Layer
- Agent-to-Agent Commerce: The Trust Layer Nobody Can Skip
- AI Agent Name Collision
- What Is a Machine-Readable Identity Record?
FAQ
What is an agent identity graph?
An agent identity graph is the connected map of names, manifests, files, endpoints, payment rails, profiles, and proof records that lets another agent inspect who an agent is before interaction.
How is an agent identity graph different from agent.json?
Agent.json is one node in the graph. The graph also includes the name, workflow files, content map, API descriptions, tool endpoints, payment metadata, directory profiles, TXT records, signatures, and receipts.
Where do SKILL.md and llms.txt fit?
SKILL.md describes repeatable workflows and constraints. llms.txt maps the content and docs an agent should read. Both should point back to the same public identity and manifest.
How do payments connect to agent identity?
Payment rails connect through payee identity, mandate scope, endpoint policy, challenge metadata, settlement path, and receipt references. Those references should match the public agent name and operator.
Do Headless Domains depend on browser DNS?
No. Headless names are made for agent command-line and API workflows; conventional browser behavior is a human user-experience topic, not a dependency for agent use.