Agent Manifest

A machine-readable card that tells agents how to work with you.

Every A-Identity surface serves a manifest at /.well-known/ai-agent-manifest.json. It is the agent-facing version of a sitemap. An agent can fetch it, learn what is on offer, and start interacting without a human reading any marketing copy.

What It Describes

Field	For An Agent	For A Human
capabilities	Which protocols are live and how to use them	What the product does
endpoints	Where to connect (MCP, docs, manifest)	Where to read more
interaction	How agent-to-agent and agent-to-human calls work	The rules of engagement
human_oversight	Which actions need a person to approve	The safety promise

Fetch It

curl https://a-identity.xyz/.well-known/ai-agent-manifest.json

Designed For Both Sides

The manifest is written for two readers at once. Agents read capabilities and endpoints to act. Humans read human_oversight to know what stays under their control. The interaction block spells out the agent-to-agent path (verify, then settle over x402) and the agent-to-human path (the agent proposes, a person approves, then it settles).

What We Deliberately Do Not Declare

The A2A agent card at /.well-known/agent-card.json tracks A2A 1.0 and lists only capabilities that have an implementation behind them. Two absences are choices rather than gaps, and they are written down here so nobody has to guess:

AP2, the Agent Payments Protocol. The card declares no AP2 extension. AP2 answers “did the human authorise this, and within what limits”, which is a real question and one adjacent to ours. But we do not accept an AP2 Payment Mandate as an input today, and declaring an extension we do not implement is the same species of claim this project refuses everywhere else. When a mandate can actually be handed to risk_check and come back with a verdict bounded by it, the extension goes in the card on the same day.

A payment handler for someone else’s checkout. We publish paid endpoints and we sell over x402, but the card does not advertise A-Identity as a drop-in payment handler for a third-party commerce flow. That would imply an integration surface that does not exist.

The rule behind both: a capability appears in the card when a caller can exercise it, not when we intend to build it. The same rule governs /.well-known/http-message-signatures-directory, where the published signing key has a test asserting the signer it advertises is actually reached from our outbound requests.

Keep the page source LLM-parsable. Plain structure, clear labels, and the manifest link in the page head let an agent navigate without guessing.