A2A Protocol: How Agents Talk to Agents

The Agent2Agent (A2A) protocol is an open standard that lets AI agents built by different vendors and on different frameworks find each other, send each other tasks and return results, without sharing their internals. It handles agent-to-agent talk, where the Model Context Protocol (MCP) handles agent-to-tool talk. The current spec is version 1.0.0. Checked 31 October 2026.

At a glance

The problem it solves

Say you have an agent that books travel, another that handles expenses and a third that talks to your finance system, each built by a different team on a different framework. Before a shared protocol, getting one agent to hand work to another meant custom code for every pair. The A2A announcement describes the old situation exactly: handing off work between agents built on different frameworks required writing custom integration code from scratch for every pairing.

A2A gives them a common language. An agent publishes a structured description of what it can do and how to reach it. Another agent reads that description, negotiates the format, and delegates a task. Neither needs to know how the other works inside. The docs call this the "opaque" property: the remote agent is a black box whose memory, tools and logic stay hidden. That protects intellectual property and keeps each side free to change.

The actors

The key-concepts page names three:

• User. A person or automated service that sets a goal.
• A2A client (client agent). An application, service or agent that acts for the user and starts the conversation.
• A2A server (remote agent). An agent that exposes an HTTP endpoint implementing the protocol. It receives requests, processes tasks and returns results or status.

An agent can be a client in one conversation and a server in another.

The building blocks

A response from a server can be a task, when the work will take time, or a message, when the answer is immediate.

How an exchange works

1. Discover. The client fetches the remote agent's Agent Card.
2. Authenticate. The card says what authentication is required, and the client meets it.
3. Send. The client sends a message, which can create a task.
4. Follow. For long work it polls, streams or waits for a push notification.
5. Collect. The server returns artifacts, and the task reaches a final state.

The specification lists core operations: send a message, send a streaming message, get a task and list tasks, among others.

Interaction styles

The key-concepts page lists three patterns. Pick by how long the work takes and whether the client stays connected.

Discovery

The discovery topic page describes two methods:

1. Well-known URI. A server hosts its Agent Card at a standard path, https://{agent-server-domain}/.well-known/agent-card.json, following RFC 8615. Anyone who knows the domain can look.
2. Curated registries. A catalogue lists agents and their cards, so you can search instead of guessing domains.

An enterprise might run an internal registry so that only approved agents appear.

Protocol bindings

The spec defines how the abstract operations map onto three concrete bindings: JSON-RPC, gRPC and HTTP+JSON/REST. A custom binding can be added through the extension and governance process, which the site describes as tiered so the core stays stable. Version negotiation has its own error in the spec, so a client and server on different versions can detect the mismatch.

A2A and MCP together

The A2A site is explicit that the two protocols are not competitors. MCP is for agent-to-tool communication: how an agent connects to tools, APIs and resources. A2A is for agent-to-agent communication: how independent agents, including ones that use MCP, discover each other, delegate tasks and share results. The site's slogan is to build with a framework, equip with MCP and communicate with A2A.

See MCP vs A2A for a longer comparison and MCP vs API for the tool side.

Who supports it

The August 2026 announcement says A2A is backed by over 150 organisations and runs in production across supply chains, financial services and mobile platforms. It names Google Cloud, AWS Bedrock AgentCore Runtime and Microsoft Azure AI Foundry as providers with native support. It lists ServiceNow, Salesforce, Atlassian and SAP among enterprise software users, and LangGraph, CrewAI, Pydantic AI, AG2 and IBM BeeAI among frameworks. These are claims from the project's own blog, so treat the counts as the project's.

The same post says the project operates under the Linux Foundation-directed Agentic AI Foundation alongside MCP, goose and AGENTS.md. The A2A site also advertises an A2A CLI, introduced in a 1 October 2026 blog post, to discover, message and manage A2A agents from a terminal.

Do you need it?

Most people do not yet. A2A earns its place when:

• Agents come from different vendors or teams and must cooperate.
• You want a standard instead of one-off glue between agents.
• Work is long-running and needs status, streaming or webhooks.
• You need agents to stay opaque to each other for security or ownership reasons.

It is overkill when one agent calls a few tools, or when helpers live inside one program. For helpers inside one session, subagents are simpler. For tools, use MCP. For the wider picture of agent types see AI agents vs agentic AI.

Security notes

The protocol says each agent card states its authentication requirements, and discovery by a public URI means anyone can read a card. Do not put secrets in a card. Treat a remote agent's reply as untrusted input, since another agent's output can carry instructions that a careless client would follow. Limit what a delegated task may do, log task IDs, and set timeouts. For organisational controls, see AI agent governance.

Our take

A2A is the standard to watch if you expect many agents from many sources to work together. The facts that matter are the 1.0 spec, the neutral home at the Linux Foundation and the broad vendor support the project reports. For a single developer with one agent and a few tools, MCP and plain subagents cover almost everything. We describe A2A from its own documentation and have not built with it. See MCP vs A2A and AI agent frameworks for the next steps.