A2A: discovering and describing agents
Understand agent cards without oversharing internal information.
Structured agent self-description
A2A describes AgentCard objects containing a name, description, skills, supported interfaces and security requirements. A card is not a universal trust certificate; its claims require verification.
Discovery and access
A card may be published at a well-known path such as /.well-known/agent-card.json or discovered through other means. Access controls and real capabilities depend on the deployment, not just on a file.
Protocols and tasks
Interoperable agents need agreement on transport interface, content types, task states and errors. Organizations may require human review or authentication before delegation.
Discovery threats
Cards from untrusted actors can make misleading capability claims. Check server identity, any available signatures and data scopes before sending sensitive tasks.
A card is not a certified identity
An Agent Card may advertise a name, skills, interfaces and security requirements. These fields support discovery and communication but do not prove provider trustworthiness or performance. Check URL, origin and real supported interfaces before delegating sensitive data or operations.
Agent qualification procedure
Inspect an agent card in an isolated environment, identify claimed capabilities and attempt a reversible task using fictional data. Check response format, error handling and authorization parameters. Record any mismatch between descriptions and observed behavior, including deployment conditions that may explain it.
Core steps
- 01Retrieve the card
- 02Verify origin and ownership
- 03Compare supported interfaces
- 04Test a low-risk task
Three questions to ask
Who published the agent card?
What authentication is required?
Were the advertised capabilities tested?
Read the source documents
Versions, reuse terms and document status can change. Check them on the original sites.