What is A2A protocol? Google's Agent2Agent standard explained

A2A (Agent2Agent) is Google's open protocol for agent-to-agent communication, the multi-agent counterpart to MCP. Where MCP standardizes how an agent talks to tools, A2A standardizes how an agent talks to another agent.

TLDR

A2A defines how AI agents from different vendors discover each other, delegate tasks, stream responses, and authenticate. Announced by Google in April 2025 with 50+ partners; by mid-2026 it's the de facto standard for cross-vendor multi-agent stacks. Built on HTTP + JSON + Server-Sent Events — boring, web-native, easy to adopt.

Read the long version in the A2A glossary entry.

The problem A2A solves

In 2024 the multi-agent ecosystem looked like:

• An agent built on LangGraph wanted to delegate work to a Salesforce-hosted Agentforce agent
• A CrewAI crew wanted to call out to a partner's specialist agent
• An OpenAI Assistant wanted to coordinate with an Anthropic Claude agent
• None of them shared a protocol — every cross-vendor handoff was custom integration

The N×M problem reappeared, this time at the agent layer instead of the tool layer.

The A2A solution

A2A defines:

• A capability card — a standard JSON document each agent exposes describing what it can do, what auth it requires, what formats it speaks
• A task delegation protocol — how one agent submits a task to another, with structured inputs + expected outputs
• Streaming responses — long-running tasks (research, code generation, multi-step workflows) stream progress via Server-Sent Events
• Authentication — pluggable auth (OAuth, JWT, custom) so enterprise scenarios are first-class

Any A2A-compliant agent can call any other A2A-compliant agent's capabilities without bespoke integration code.

A2A vs MCP

The most common confusion. They're complementary, not competitive.

Most serious production stacks in 2026 use both — MCP at the bottom (agent uses tools), A2A at the top (agents coordinate with other agents).

A2A in practice

A typical A2A interaction:

1. Discovery: Agent A reads Agent B's capability card. Sees: B can do "summarize legal contract" with input format "PDF URL" and output format "JSON {risks, key_terms, recommendations}".
2. Auth: Agent A authenticates with Agent B (OAuth, JWT, or other configured method).
3. Delegation: Agent A submits a task with the required inputs.
4. Streaming: Agent B streams progress updates as it works.
5. Result: Agent B returns the structured output. Agent A continues its workflow.

In code (conceptual):

const a2aClient = new A2AClient("https://contract-agent.legal.com");
const capabilities = await a2aClient.discover();
const task = await a2aClient.delegate({
  capability: "summarize-contract",
  input: { pdfUrl: "..." },
});
for await (const update of task.stream()) {
  console.log(update);
}
const result = await task.result();

The ecosystem in mid-2026

Launch partners (April 2025) and ongoing adopters:

• Atlassian (Jira AI agent)
• Salesforce (Agentforce)
• ServiceNow (Now Assist)
• SAP (Joule)
• Workday (Workday AI)
• Box, Cohere, Elastic, Glean, Microsoft (selectively), MongoDB, PayPal, Slack, Snowflake, UKG, Wipro
• 50+ at launch; ~200 by mid-2026

Frameworks supporting A2A:

• Google ADK (Agent Development Kit) — A2A-native
• LangChain/LangGraph — A2A client + server adapters
• CrewAI — A2A interop
• Custom: any framework can adopt A2A since it's just HTTP

When A2A matters

You should care about A2A if:

• You're building agents that need to coordinate with agents from other vendors (your CRM's agent, your ticketing system's agent, your partner's agent)
• You're a vendor shipping an AI agent and want enterprise integrability
• You're an enterprise architect designing a multi-agent stack across vendor boundaries

You probably don't need A2A if:

• All your agents are in one codebase + one framework → in-process function calls are simpler
• You're a solo developer building a personal agent → overkill
• You're an end user using off-the-shelf agents → it's plumbing under the hood

A2A vs alternative approaches

• A2A vs message queues (Kafka, NATS): Message queues work but they're transport-only — A2A adds capability discovery + structured task semantics on top.
• A2A vs REST APIs: REST APIs work for one-off integrations but don't standardize the agent semantics (capabilities, tasks, streaming progress). A2A is REST + the agent abstraction.
• A2A vs LangGraph subgraphs: LangGraph subgraphs work great within one framework. A2A handles the cross-framework / cross-vendor case.

Common A2A misconceptions

1. "A2A replaces MCP" — No. They solve different problems. Most stacks use both.
2. "A2A is Google-only" — No. Google created it but it's open + vendor-neutral. Salesforce, Atlassian, SAP, etc. adopted it.
3. "I need A2A for my agent to do anything useful" — No. A2A's value is interop across boundaries. Single-org agents don't need it.

See also

• A2A glossary entry
• What is MCP
• How to set up multi-agent workflow
• LangGraph vs CrewAI vs AutoGen vs OpenAI Agents SDK

Bottom line

A2A is the standard that made cross-vendor multi-agent workflows tractable. By mid-2026 most enterprise multi-agent stacks adopted it; the protocol is stable + widely supported. If you're building agents that talk to agents you don't control, A2A is the path of least resistance.

Read the A2A glossary entry →