What is the A2A protocol? A plain-language guide

The Agent2Agent (A2A) protocol is an open standard for how one AI agent works with another agent that a different team, vendor or company built and runs. It defines how an agent describes itself, how other agents find that description, and how two agents exchange messages and track a piece of work until it is done.

A2A does not care how either agent works inside. The specification treats each agent as opaque: they cooperate through declared capabilities and the content they exchange, without sharing memory, tools or internal plans. Google announced A2A in April 2025, the Linux Foundation became its home in June 2025, and the current version is 1.0.

The problem A2A solves

Agents built on different frameworks have no shared way to talk to each other. Without a common protocol, every pairing needs its own integration: a custom endpoint, a custom auth scheme, a custom way to check status. The A2A project’s own documentation calls out a common workaround, wrapping a remote agent as a tool, as a poor fit. A tool call is one request and one response. An agent may need to ask a clarifying question, work for hours, or return files and structured results along the way.

A2A gives both sides one contract:

• Discovery. A machine-readable Agent Card at a predictable URL.
• Work tracking. A task with a server-assigned ID, a state, and a history.
• Content. Messages and outputs built from typed parts: text, files, structured data.
• Updates. Polling, streaming, or webhooks for work that takes a while.
• Security. Standard web authentication schemes, declared up front in the card.

The specification calls the caller the A2A client and the agent that serves requests the A2A server, or remote agent. Google’s launch post used the terms client agent and remote agent.

Where A2A came from and who governs it

Date	Event	Source
April 9, 2025	Google announces A2A as an open protocol with a draft specification on GitHub, and describes it as complementary to MCP.	Google Developers Blog
June 23, 2025	The Linux Foundation launches the Agent2Agent project. The protocol moves under Linux Foundation governance with a commitment to vendor neutrality.	Linux Foundation press release
July 30, 2025	Version 0.3.0 released.	GitHub releases
August 1, 2025	IANA registers the agent-card.json well-known URI as permanent, with the Linux Foundation as change controller.	IANA registry
March 12, 2026	Version 1.0.0 released, with breaking changes from 0.3.	GitHub releases
May 2026	Version 1.0.1 patch released.	GitHub releases

The code and specification live at github.com/a2aproject/A2A under the Apache 2.0 license. A Technical Steering Committee holds technical oversight. The repository’s GOVERNANCE.md lists the organizations that hold seats.

Core concepts

Agent Card and discovery

An Agent Card is a JSON document that describes an agent: its name, description, provider and version, the endpoints and protocol bindings it supports, its optional capabilities, the authentication schemes it accepts, the media types it reads and writes, and its skills. Every A2A server must publish one.

The standard location is https://{domain}/.well-known/agent-card.json, a path built on the RFC 8615 convention for well-known URIs. Clients can also find cards through registries or be configured with a card URL directly. The full field reference is in Agent Cards explained.

Tasks

A task is the unit of work. The server creates it, assigns its ID, and moves it through a defined set of states:

State	Meaning	Kind
TASK_STATE_SUBMITTED	Received and acknowledged	Active
TASK_STATE_WORKING	Being processed	Active
TASK_STATE_INPUT_REQUIRED	The agent needs more input from the client	Interrupted
TASK_STATE_AUTH_REQUIRED	The agent needs authorization to continue	Interrupted
TASK_STATE_COMPLETED	Finished successfully	Terminal
TASK_STATE_FAILED	Finished with an error	Terminal
TASK_STATE_CANCELED	Canceled before completion	Terminal
TASK_STATE_REJECTED	The agent decided not to do it	Terminal

A task in a terminal state accepts no further messages. A contextId groups related tasks and messages into one conversation. Clients cannot choose the ID of a new task; only the server assigns one. The A2A task lifecycle walks through each transition.

Messages

A message is one turn in the exchange. It carries a messageId chosen by its sender, a role (ROLE_USER for the client, ROLE_AGENT for the server) and one or more parts. Clients send messages to start tasks, answer questions and add instructions. For a simple request, a server may answer with a message directly and never create a task.

Parts

A part is the smallest unit of content. In version 1.0 the JSON member name identifies the type: text, raw (base64 bytes), url (a file reference) or data (any JSON value). Any part can also carry mediaType, filename and metadata.

Illustrative: a client message with three parts.

{
  "messageId": "b6f1c0a2-3d4e-4f5a-8b9c-0d1e2f3a4b5c",
  "role": "ROLE_USER",
  "parts": [
    { "text": "Quote 40 pallets from Toronto to Chicago, pickup Monday." },
    {
      "data": { "pallets": 40, "origin": "Toronto, ON", "destination": "Chicago, IL" },
      "mediaType": "application/json"
    },
    {
      "url": "https://example.com/manifests/7731.pdf",
      "filename": "manifest-7731.pdf",
      "mediaType": "application/pdf"
    }
  ]
}

Artifacts

Artifacts are what a task produces: a document, an image, a structured result. Each has an artifactId, an optional name and description, and one or more parts. The specification keeps the two apart on purpose. Messages carry the conversation. Artifacts carry the results, and servers should return outputs as artifacts.

Streaming and push notifications

A client has three ways to follow a task:

1. Polling. Call GetTask until the state changes. Works with every binding.
2. Streaming. SendStreamingMessage or SubscribeToTask keeps a connection open. The server sends the task, then status and artifact update events in order, and closes the stream when the task ends or is interrupted. This requires capabilities.streaming: true in the card.
3. Push notifications. The client registers a webhook and the server posts updates to it. This requires capabilities.pushNotifications: true and suits server-to-server work where the client cannot hold a connection open.

By default, SendMessage waits until the task reaches a terminal or interrupted state before it returns. A client that sets returnImmediately in the request configuration gets the task back at once and follows it with one of the methods above.

Protocol bindings

The specification has three layers: a data model, a set of abstract operations, and bindings that map both onto a wire protocol. Version 1.0 defines three standard bindings.

Binding	Transport	Operations look like	Streaming
JSON-RPC 2.0	HTTP(S), application/json	SendMessage, GetTask, CancelTask	Server-Sent Events
gRPC	HTTP/2 with TLS, Protocol Buffers	A2AService RPCs of the same names	gRPC server streaming
HTTP+JSON	HTTP(S), application/a2a+json	POST /message:send, GET /tasks/{id}	Server-Sent Events

An agent lists the bindings it offers in its card’s supportedInterfaces field, preferred first. When an agent offers more than one, all of them must provide the same operations and behave the same way. Custom bindings are allowed and should be identified by a URI. The file a2a.proto is the normative definition of every data object. JSON serializations use camelCase field names and write enum values as their full names, such as TASK_STATE_COMPLETED.

Versions: 1.0 and 0.3

A2A versions are written as Major.Minor. Patch numbers do not affect compatibility. Clients send the version in an A2A-Version header on every request. A server that receives no version header must treat the request as 0.3. A server that does not support the requested version returns VersionNotSupportedError, code -32009 in JSON-RPC.

Area	0.3	1.0
JSON-RPC method names	message/send, tasks/get	SendMessage, GetTask
Enum values	"completed", "user"	"TASK_STATE_COMPLETED", "ROLE_USER"
Part type	"kind": "text" field	The member name (text, raw, url, data)
Endpoint in the card	url plus preferredTransport, optional additionalInterfaces	supportedInterfaces entries with url, protocolBinding, protocolVersion
Extended card flag	Top-level supportsAuthenticatedExtendedCard	capabilities.extendedAgentCard
OAuth flows in security schemes	Authorization code, client credentials, implicit, password	Implicit and password deprecated; device code flow and a pkceRequired flag added

The well-known card path, /.well-known/agent-card.json, is the same in both. An agent can serve both versions during a migration by listing one interface per version.

What A2A deliberately leaves out

A2A defines the conversation between two agents. Several questions that matter between companies are outside its scope, and the specification says so.

• Who is behind an agent. The specification relies on standard web security. TLS proves the server’s domain, and the card’s securitySchemes tell clients which credentials to present (API key, HTTP auth, OAuth 2.0, OpenID Connect or mutual TLS). A card can carry a JWS signature over its canonical form, which proves that the holder of a given key published it unchanged. It does not say whose key that is or whether that party can be trusted. Clients may keep their own store of trusted keys. See Signed Agent Cards.
• Delegated authority. An agent can pause a task in TASK_STATE_AUTH_REQUIRED to ask for authorization. The specification states that it does not define the scope, representation, validity or revocation of the resulting credential. That is left to implementations, credential issuers or extensions.
• Receipts. Tasks carry history and artifacts, and the server decides which messages it keeps. There is no standard signed record that both parties can later produce to show what was asked and agreed.
• Payments. A2A has no payment semantics.
• Registries. Registries appear as a discovery option, but the project’s discovery guide notes that no standard registry API is prescribed.

Extensions are the sanctioned way to add these. An agent lists extension URIs in capabilities.extensions, can mark one as required, and clients opt in per request with the A2A-Extensions header.

How adjacent standards fit

Standard	What it covers	How it relates to A2A
MCP (Model Context Protocol)	How an AI application connects a model or agent to tools, data and prompts. Current spec version 2026-07-28.	Complementary. An A2A server may use MCP internally to reach its own tools. See A2A vs MCP.
AP2 (Agent Payments Protocol)	Signed mandates that record what a user authorized for a checkout and a payment.	Offered as an extension for A2A.
x402	Payment inside HTTP. A server answers 402 Payment Required, the client pays and retries.	Works at the HTTP layer. AP2’s published samples include one that pays through x402.

Worked example: a live round trip

Emissar runs a small public A2A agent. It speaks version 1.0 over JSON-RPC, needs no credentials, and does not support streaming. The requests below were run on September 25, 2026. IDs and timestamps will differ when you run them. The agent is rate limited per IP, so don’t script loops against it.

Step 1: fetch the Agent Card

curl -s https://emissar.ai/.well-known/agent-card.json

Excerpt of the response. The description, provider, iconUrl, version and documentationUrl fields and most skill fields are omitted here; Agent Cards explained shows the full card.

{
  "name": "Emissar",
  "supportedInterfaces": [
    {
      "url": "https://emissar.ai/a2a/v1",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": false,
    "pushNotifications": false,
    "extendedAgentCard": false
  },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    { "id": "about-emissar", "name": "Answer questions about Emissar" },
    { "id": "request-early-access", "name": "Request early access on behalf of a person or company" }
  ]
}

A client reads three things here. The first supportedInterfaces entry says to use JSON-RPC at https://emissar.ai/a2a/v1 with version 1.0. The capabilities say there is no streaming, so the client uses SendMessage and reads the result. The card has no securitySchemes, so no credentials are needed.

Step 2: send one message

curl -s https://emissar.ai/a2a/v1 \
  -H 'Content-Type: application/json' \
  -H 'A2A-Version: 1.0' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "SendMessage",
    "params": {
      "message": {
        "messageId": "9f1c2b7e-4a51-4c2e-9d0e-2f6a3c8b1d47",
        "role": "ROLE_USER",
        "parts": [{ "text": "How is Emissar different from the A2A protocol itself?" }]
      }
    }
  }'

Step 3: read the response

The artifact text is trimmed after its first two sentences.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "task": {
      "id": "5ba2e1cc-5f53-4a50-82eb-0d5611d81c90",
      "contextId": "fab8a330-be2c-41f9-bcf2-ed1ac114ca1e",
      "status": {
        "state": "TASK_STATE_COMPLETED",
        "timestamp": "2026-09-25T20:47:40.241Z"
      },
      "artifacts": [
        {
          "artifactId": "988f8a49-77e9-43f3-bfee-85eb55785dd4",
          "name": "Answer",
          "parts": [
            {
              "text": "A2A is the open protocol for how two agents exchange tasks once they are connected. It is governed by the Linux Foundation, and Emissar does not replace it. …"
            }
          ]
        }
      ],
      "history": [
        {
          "role": "ROLE_USER",
          "parts": [{ "text": "How is Emissar different from the A2A protocol itself?" }],
          "messageId": "9f1c2b7e-4a51-4c2e-9d0e-2f6a3c8b1d47",
          "taskId": "5ba2e1cc-5f53-4a50-82eb-0d5611d81c90",
          "contextId": "fab8a330-be2c-41f9-bcf2-ed1ac114ca1e"
        }
      ],
      "metadata": { "skill": "about-emissar" }
    }
  }
}

What happened:

• The server created a task and returned it inside result.task. The other possible shape is result.message, for a direct reply with no task.
• The state is already TASK_STATE_COMPLETED, because SendMessage waits for a terminal or interrupted state unless the client asks it to return immediately.
• The client sent no contextId, so the server generated one and returned it. A follow-up question in the same conversation would send it back.
• The answer arrived as an artifact, as the specification recommends for task outputs.
• history holds the client’s message, now tagged with the task and context IDs.
• metadata is free-form. This agent uses it to report which skill handled the request.

To see version negotiation at work, send the same request with A2A-Version: 2.0. The server rejects it with error code -32009 (VersionNotSupportedError) and lists the versions it does support.