A2A Agent Card

What is an A2A Agent Card?

An A2A Agent Card is a JSON metadata document published by an A2A server. It describes how another application or agent can understand and connect to that remote agent through the [Agent2Agent Protocol](/glossary/agent2agent-protocol/).

The card can describe identity, supported protocol interfaces, capabilities, skills, accepted content types, and security requirements. It is a discovery and interoperability document, not the agent itself.

How it is used

An A2A client obtains the Agent Card before or during integration. It can inspect the declared information to answer questions such as:

• Which service interface and protocol version should be used?
• Does the agent support streaming or push notifications?
• What skills does it advertise?
• Which input and output modes are accepted?
• What authentication or security schemes apply?

An [agent router](/glossary/agent-router/) may use skill and capability metadata as one signal when choosing a remote agent. The router should still consider authorization, trust, availability, cost, and task-specific policy.

Simple example

A travel-planning system discovers a remote booking agent. Its Agent Card declares a hotel-search skill, structured-data input support, a service endpoint, and required authentication. The client can determine whether the agent fits the request and how to initiate an A2A interaction.

The card does not prove the agent will perform well. It states how the agent presents itself and what protocol features it declares.

Agent Card versus agent instructions

[Agent instructions](/glossary/agent-instructions/) guide an agent’s internal behavior. An Agent Card is external metadata for discovery and communication.

Instructions might say, “Prefer refundable hotels.” The Agent Card might state that the agent offers a hotel-search skill and supports particular interfaces. Publishing an Agent Card does not expose the agent’s system prompt, private memory, or internal reasoning.

Why it matters

Agent Cards reduce hard-coded assumptions between independently built agents. Clients can discover connection details and advertised capabilities in a common structure.

Builders should not treat metadata as automatic trust. Cards must be obtained through an appropriate trust mechanism, and authorization still belongs at the service boundary. See [Single-Agent vs Multi-Agent Systems](/single-agent-vs-multi-agent-systems/) for the larger collaboration context.