A2A Protocol

In late 2024, Model Context Protocol (MCP) answered an obvious question: how should an AI agent talk to its tools? A few months later, Agent-to-Agent Protocol (A2A) answered the next one: how should agents talk to each other?

Both protocols are now governed by the same foundation. Both ship under permissive open-source licenses. Both are supported by every major AI vendor. And yet a surprising number of engineering teams treat them as alternatives — as if you would pick one or the other.

You will not. They solve completely different problems, and the agent architectures that scale in 2026 use both. This article explains exactly what A2A is, what it is not, and where it fits next to the rest of your stack.

To see where A2A fits, picture a single AI agent. It has a model, a memory, and access to some tools through MCP. It can read your inbox, summarize a thread, draft a reply, send the result. That is one agent doing one job.

Now picture five agents. A research agent that gathers information. An analysis agent that interprets it. A writing agent that produces the report. A review agent that critiques the draft. A delivery agent that publishes the final output. Each is good at exactly one thing.

How do they coordinate? Specifically:

• How does the research agent announce that its output is ready;
• How does the analysis agent discover what capabilities the research agent offers;
• How does the writing agent ask the review agent to evaluate a draft, and wait for the result;
• How do all of them share intermediate state without one team owning the entire stack;
• How does this work when the agents are built on different frameworks, by different teams, possibly in different organizations. Before A2A, the answer was always "build something custom". Every multi-agent system was a bespoke orchestration framework. A2A is the standard that replaces those bespoke layers.

MCP standardizes how an agent uses tools. A2A standardizes how an agent uses other agents.

A2A is an open protocol introduced by Google in April 2025 and brought under the Linux Foundation's Agentic AI Foundation in late 2025. Its scope is intentionally narrow:

• Agent discovery. How one agent finds out that another exists and what it can do;
• Capability negotiation. How agents agree on the kind of task being delegated;
• Task lifecycle. How a task is sent, accepted, worked on, paused, resumed, and completed;
• Result delivery. How outputs flow back to the requesting agent, including streaming and partial results;
• Cross-vendor interoperability. How an agent built on LangGraph can talk to one built on CrewAI without either side knowing the other's internals. The protocol is transport-layered on HTTP and JSON, with optional support for Server-Sent Events for streaming. It deliberately reuses patterns that web developers already know — REST endpoints, OAuth-style auth, well-defined error codes. There is no new wire format to learn.

Three primitives sit at the heart of the protocol.

The Agent Card is the public description of an agent. It declares the agent's identity, its capabilities, its authentication requirements, and the endpoints other agents can use to reach it. Think of it as the agent's resume — published at a known URL, machine-readable, and the first thing a new agent reads when deciding whether to delegate a task.

Capabilities are the discrete jobs an agent can do. A capability has a name, an input schema, an output schema, and a description. Capabilities are how an agent advertises what it can be asked to do, in a way other agents can reason about programmatically.

Tasks are the unit of work. When agent A asks agent B to do something, that request is a task. Tasks have status (submitted, in progress, completed, failed), lifecycle hooks for cancellation and resumption, and a result payload that arrives back when the work is done.

The clean rule:

An Agent Card describes who you are. A Capability describes what you can do. A Task describes what was actually asked.

Get those three concepts straight and the rest of the protocol falls into place.

The single most common mistake teams make is treating MCP and A2A as competitors. They are not. They occupy different layers of the stack.

Aspect	MCP	A2A
Communication direction	Agent talks to a tool	Agent talks to another agent
Capability provider	Server exposing tools, resources, prompts	Agent exposing capabilities and tasks
Typical use case	Database query, API call, file access	Task delegation, multi-step pipelines, cross-team workflows
Granularity	Function-level	Workflow-level
Statefulness	Mostly stateless requests	Long-running tasks with lifecycle
Wire format	JSON-RPC 2.0	HTTP + JSON

The right mental model is layered. MCP is the bottom layer — agents and tools speak it to access raw capabilities. A2A sits on top — agents speak it to coordinate work among themselves. An A2A task often expands into many MCP calls under the hood, none of which the requesting agent ever sees.

This layering mirrors how the web itself is built. HTTP runs on TCP, not instead of it. A2A runs alongside MCP, not in competition with it.

Most projects do not need A2A from day one. You need it when:

• You have more than one agent in the same system and they need to hand work to each other;

• Your agents are built by different teams or on different frameworks and must interoperate;

• You want to decouple agent capabilities so the calling agent does not need to know how a task is implemented;

• You are exposing your agents to external consumers — partner companies, third-party integrations, marketplace listings;

• Your workflows are long-running and need lifecycle management beyond a single request-response cycle. You do not need A2A when:

• You have a single agent and no plans for more;

• All your agents are tightly coupled and built by the same team;

• Your delegation logic is simple enough to be a direct function call;

• The agents run in the same process and shared memory is sufficient. A common pattern is to start without A2A, build a few agents that grow tightly coupled, then refactor to A2A once the cost of coordination exceeds the cost of introducing a protocol.

Picture a customer-support pipeline built the modern way. A user message arrives. The orchestrator agent reads it, classifies the intent, and decides this is a technical question. It uses A2A to delegate the task to a specialist technical-support agent.

The specialist agent receives the task with its full context. Internally, it makes several MCP calls — pulling product documentation, querying the customer's account history, checking known-issue logs. It composes an answer and returns it through A2A.

The orchestrator receives the result, optionally hands it off to a quality-review agent (again through A2A) for a second opinion, and finally responds to the user.

In this single workflow, A2A handles every agent-to-agent boundary and MCP handles every agent-to-tool boundary. Neither protocol could do the other's job, and the workflow does not work cleanly without both.

The agent architectures that scale in 2026 are not the ones with the smartest individual agents. They are the ones with the cleanest protocol boundaries between them.

A2A is not a replacement for anything. It is the part of the agent stack that was missing — the standard way for autonomous components to coordinate work without each side reinventing the orchestration layer.

The practical lesson is to keep the layers separate. Use MCP when the dependency is a tool. Use A2A when the dependency is another agent. Resist the temptation to build A2A-like patterns on top of MCP just because MCP is what you started with — the abstractions are different for good reasons, and conflating them produces systems that are painful to maintain.

The teams shipping production multi-agent systems in 2026 are the ones who internalized the layered model early.

That clarity is worth more than any single architectural choice you will make this year.

Q: Does A2A replace MCP?

A: No. They solve different problems at different layers. MCP defines how an agent talks to its tools. A2A defines how agents talk to each other. Production systems typically use both.

Q: Who created A2A?

A: A2A was introduced by Google Cloud in April 2025 with initial enterprise partners including Salesforce, SAP, and Accenture. It is now governed by the Agentic AI Foundation under the Linux Foundation alongside MCP.

Q: Do I need A2A for a single-agent application?

A: No. A2A only becomes useful when you have multiple agents that need to coordinate. For a single agent doing a single job, A2A adds complexity with no benefit.

Q: Can A2A agents be built on different frameworks?

A: Yes — that is one of the main points. An agent built on LangGraph can delegate work to one built on CrewAI through A2A without either side knowing the other's internals.

Q: How does A2A handle authentication?

A: A2A uses standard web authentication patterns, primarily OAuth 2.1, declared in the Agent Card. Each agent specifies its own auth requirements and the calling agent honors them.

Q: Is A2A only for cloud or remote agents?

A: No. A2A works equally well for agents on the same machine, in the same cluster, or across the public internet. The transport layer is the same.

Q: What about A2A in regulated industries?

A: The Linux Foundation's Enterprise Working Group is actively standardizing audit trails, central auth, and gateway patterns specifically for regulated deployments. For finance and healthcare, follow that group's specifications before going to production.