# What is the A2A (Agent2Agent) protocol?

> A2A is an open standard that lets independent AI agents discover each other and work on tasks over HTTP, without sharing their internals.

Source: https://www.honeyhive.ai/learn/a2a-protocol (updated 2026-10-31)

The Agent2Agent (A2A) protocol is an open standard for communication between AI agents. It gives agents built on different frameworks or by different vendors a common way to find each other and hand over work ([What is A2A](https://a2a-protocol.org/latest/topics/what-is-a2a/)). It builds on HTTP, JSON-RPC and Server-Sent Events (SSE), and agents collaborate "without exposing their internal logic, memory, or proprietary tools". Google created it and launched it in April 2025, and the Linux Foundation announced on 23 June 2025 that it would host the project as a vendor-neutral nonprofit ([press release](https://linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents)).

For the protocol that connects an agent to tools instead, see [the Model Context Protocol](/learn/model-context-protocol).

## How A2A works

The [key concepts](https://a2a-protocol.org/latest/topics/key-concepts/) page names three actors. The user is a person or automated service that starts a request. The A2A client is an application, service or another agent acting for the user. The A2A server, also called the remote agent, exposes an HTTP endpoint and is opaque to the client.

The [specification](https://a2a-protocol.org/latest/specification/) (section 2.2) defines the core objects:

| Object | What it is |
|---|---|
| Agent Card | A JSON metadata document published by an A2A server: [identity](/learn/ai-agent-identity), endpoint, capabilities, skills and authentication requirements |
| Task | "The fundamental unit of work managed by A2A", stateful and with a lifecycle |
| Message | "A communication turn between a client and a remote agent", with a role and one or more Parts |
| Part | "The smallest unit of content within a Message or Artifact": text, a file reference or structured data |
| Artifact | An output produced by a task, made of Parts |

A server answers a request with either a Message, for an immediate reply, or a new Task, for longer work. For progress on a task, the client can poll, stream over SSE, or register a webhook for push notifications ([key concepts](https://a2a-protocol.org/latest/topics/key-concepts/)). The server-generated `contextId` groups related tasks across a series of interactions.

## Discovery with the Agent Card

The spec (section 8.2) lists three ways for a client to find a card: the well-known URI `https://{server_domain}/.well-known/agent-card.json`, curated registries or catalogs, and direct configuration with a known URL or content ([specification](https://a2a-protocol.org/latest/specification/)). Cards can optionally be signed with JSON Web Signature (section 8.4, same page).

## The task lifecycle

Task states are defined in section 4.1.3 of the [specification](https://a2a-protocol.org/latest/specification/), where each name carries a `TASK_STATE_` prefix:

| Group | States |
|---|---|
| Working | SUBMITTED, WORKING |
| Interrupted | INPUT_REQUIRED (the agent needs more input from the user), AUTH_REQUIRED |
| Terminal | COMPLETED, FAILED, CANCELED, REJECTED |

The interrupted states are what let an agent pause and ask a question mid-task, then continue. A stream either carries a single Message and closes, or begins with the Task and closes when the task reaches a terminal state ([specification](https://a2a-protocol.org/latest/specification/), section 3.1.2). Push notifications are server-initiated HTTP POST requests to a client-provided webhook, and need the agent's `pushNotifications` capability.

## Operations and bindings

The spec defines the same operations over three protocol bindings: JSON-RPC, gRPC and HTTP+JSON/REST. Custom bindings are allowed if they meet the same functional-equivalence requirements ([specification](https://a2a-protocol.org/latest/specification/), sections 5.1 and 9 to 12).

| Operation | JSON-RPC method | HTTP+JSON endpoint |
|---|---|---|
| Send a message | `SendMessage` | `POST /message:send` |
| Send and stream updates | `SendStreamingMessage` | `POST /message:stream` |
| Get a task | `GetTask` | `GET /tasks/{id}` |
| List, cancel, subscribe to tasks | `ListTasks`, `CancelTask`, `SubscribeToTask` | see spec section 5.3 |
| Manage push notification configs | `CreateTaskPushNotificationConfig` and three others | see spec section 5.3 |
| Fetch the authenticated extended card | `GetExtendedAgentCard` | `GET /extendedAgentCard` |

Clients must send an `A2A-Version` header with each request, and a server that does not support the requested version must return a `VersionNotSupportedError` ([specification](https://a2a-protocol.org/latest/specification/), section 3.6). As of 31 October 2026 the latest released version is 1.0.0 ([specification](https://a2a-protocol.org/latest/specification/)); check the spec for the current release before building.

## A2A vs MCP

The A2A docs call the two protocols complementary. They say "MCP is vertical. It deepens a single agent" and "A2A is horizontal. It connects agents across that boundary" ([A2A and MCP](https://a2a-protocol.org/latest/topics/a2a-and-mcp/)).

| | MCP | A2A |
|---|---|---|
| Connects | An agent to tools and resources | An agent to another, independent agent |
| Counterpart | Typically stateless, with structured inputs and outputs | Autonomous, keeps state over longer multi-turn interactions |
| Stated by the docs as | "more about agents using capabilities" | "about agents partnering on tasks" |

Both rows come from the same [A2A and MCP page](https://a2a-protocol.org/latest/topics/a2a-and-mcp/), which is written by the A2A project. It adds that a well-defined, stateless A2A skill can sometimes be exposed as an MCP-compatible resource. A common pairing is A2A between agents and MCP inside each agent.

## When to use A2A

This is a rule of thumb, not part of the spec.

| Situation | Reasonable choice | Why |
|---|---|---|
| An agent needs a database, file or API | MCP server or plain function tool | The counterpart is a capability, not an agent |
| A task may run long, pause for input or stream progress | A2A | Tasks, `INPUT_REQUIRED` and streaming are built in |
| The other agent is owned by another team or vendor and must stay opaque | A2A | Opaque execution is a stated design principle |
| Several agents live in one codebase and one framework | The framework's own handoffs | No cross-vendor boundary to bridge; see [agentic workflows](/learn/agentic-workflow) |

For the wider picture of how agents are built, see [what are AI agents](/learn/what-are-ai-agents) and [how to build AI agents](/learn/how-to-build-ai-agents).

## Tracing multi-agent systems in HoneyHive

HoneyHive's docs do not list an A2A-specific guide as of 31 October 2026 ([docs index](https://docs.honeyhive.ai/llms.txt)). The [multi-agent tracing and evaluation tutorial](https://docs.honeyhive.ai/v2/tutorials/multi-agent-cookbook.md) shows a multi-agent customer support bot built with Google ADK, with tracing and evaluations added. To follow a request across several agents, see [how to trace AI agents](/learn/agent-tracing) and [agent observability](/learn/agent-observability).

## FAQ

### What is the difference between A2A and MCP?

The A2A docs put it as "A2A is about agents partnering on tasks; MCP is more about agents using capabilities" ([A2A and MCP](https://a2a-protocol.org/latest/topics/a2a-and-mcp/)). MCP connects an agent to its tools and data. A2A connects one agent to another agent.

### Who created A2A and who runs it now?

Google created it and launched it in April 2025. The Linux Foundation announced it would host the project on 23 June 2025 as a vendor-neutral home ([press release](https://linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents)).

### Does A2A replace MCP?

No. The A2A docs describe the two as complementary, with A2A connecting agents to each other and MCP connecting each agent to its own tools ([A2A and MCP](https://a2a-protocol.org/latest/topics/a2a-and-mcp/)).