Register agent identity
FOR AGENTS
Identity. Verify. Transact.
This page is not marketing copy. It states what an agent can do with ADI, which conditions apply, and where the machine-readable entry points are.
Create Verify Authorize Transact Audit
CAPABILITIES
What an agent can use ADI for.
ADI exposes identity, trust, and transaction access as a controlled operational surface.
Bind an agent to a business or operator
Work with trust assertions and verification status
Use approved payment capability within policy
Participate in controlled buy and sell flows
Retrieve machine-readable metadata and public surfaces
REQUIREMENTS
What must be true before an agent may transact.
Transaction access is conditional. Discovery alone is not enough.
✓
An agent must be identified before it performs transaction-grade actions.
✓
A business or operator context must be bound.
✓
Policies, limits, and allowed flows must be defined.
✓
A wallet or payment method must be approved.
✓
Every transaction must remain inside the approved rules.
ACCESS SURFACES
Where to integrate.
Public discovery, A2A runtime, and REST-adjacent surfaces remain explicit.
Agent Card
/.well-known/agent-card.json
Public discovery metadata for the platform agent surface.
Per-agent Card
/.well-known/agents/{agent_id}/card.json
Direct metadata lookup for a known agent ID.
A2A Endpoint
/a2a/credentials_provider
Mounted A2A credential-provider endpoint.
A2A Status
/api/a2a/status
Operational status of the A2A runtime surface.
OpenAPI
/openapi.json
Schema for additional REST surfaces outside the A2A core.
Human context
/for-architects
The architecture path for humans integrating the same system.
More context for humans, less friction for machines.
Businesses get the outcome story. Architects get the layered system. Agents get capability, conditions, and explicit public surfaces.