A2A Key Concepts and Components

A2A uses a set of core concepts to define how agents interact. Understanding these building blocks is essential when developing or integrating A2A-compatible systems.

Core actors

• User: The end user, a human operator or an automated service. The user initiates a request or defines a goal that needs help from one or more AI agents.
• A2A client (client agent): An application, service, or another AI agent acting on behalf of the user. The client initiates communication with the A2A protocol.
• A2A server (remote agent): An AI agent or agentic system that exposes an endpoint implementing the A2A protocol. It receives requests from clients, processes tasks, and returns results or status updates. To the client, the remote agent is an opaque (black-box) system: its internal logic, memory, and tools stay hidden.

Fundamental communication elements

Each element has its own page with fields, rules, and examples: Agent Card , Task , Message , Part , and Artifact .

Interaction mechanisms

A2A supports three interaction patterns, each suited to different needs for responsiveness and persistence:

• Request/response (polling): The client sends a request and the server responds. For long-running tasks, the client polls periodically for updates.
• Streaming with Server-Sent Events (SSE): The client receives real-time, incremental results or status updates over an open HTTP connection.
• Push notifications: The server calls a client-provided webhook on significant task updates. This suits very long-running tasks or disconnected clients.

For more on streaming and push notifications, see Streaming and Async .

Agent Card

The Agent Card is a JSON document that works like a digital business card, providing the metadata needed for discovery and interaction setup. Clients use it to decide whether an agent fits a task, how to structure requests, and how to communicate securely. It lists the agent’s identity, service endpoints (URLs), A2A capabilities, authentication requirements, and skills. See Agent Discovery .

Messages and Parts

A Message represents one turn of communication between a client and an agent. It carries a role (user or agent), a unique messageId, and one or more Parts. Parts are the granular containers for the actual content, which makes A2A modality independent.

A Part uses a oneof structure and must contain exactly one of these content fields:

• text: a string of plain text
• raw: inline binary file data (bytes)
• url: a URI referencing external file content
• data: a structured JSON value (object, array, and so on) for machine-readable data

Every Part can also carry:

• mediaType: the MIME type of the content (for example text/plain, image/png, application/json)
• filename: an optional file or content name
• metadata: a key-value map for additional context

Artifacts

An Artifact is a tangible output a remote agent generates during a task. Unlike general messages, artifacts are the actual deliverables. Each has a unique artifactId, a human-readable name, and one or more Parts. Artifacts are tied to the task lifecycle and can be streamed to the client incrementally.

Agent response: Task or Message

An agent response is either a new Task (when a long-running operation is needed) or a Message (when the agent can answer immediately). See Life of a Task .

Other important concepts

• Context (contextId): A server-generated identifier that groups related Task objects and carries context across a series of interactions.
• Transport and format: A2A works over HTTP(S) and other transports, and defines three protocol bindings: JSON-RPC 2.0, gRPC, and HTTP+JSON/REST. All bindings share one canonical data model defined with Protocol Buffers, and the Agent Card declares the interfaces a server supports through supportedInterfaces.
• Authentication and authorization: A2A follows standard web security practice. Authentication requirements are declared in the Agent Card, and credentials (OAuth tokens, API keys) are typically sent in HTTP headers, separate from A2A protocol messages. See Enterprise-Ready Features .
• Multi-tenancy: One endpoint can serve multiple tenants. See Multi-Tenancy .
• Extensions: Agents can declare custom protocol extensions in their Agent Card. See Extensions .

Source: Official A2A documentation: Key Concepts