A2A Protocol Explained: What Agent2Agent Is and How It Differs From MCP

The Agent2Agent (A2A) protocol is an open standard, originally built by Google and now governed by the Linux Foundation, that lets independent AI agents (built by different vendors, on different frameworks) find each other, share what they can do, and hand off work through a shared wire format. It solves a different problem than MCP. MCP connects one agent to its tools and data. A2A connects one agent to another agent, treating the remote agent as a peer it can delegate to, not a function it can call.

Google published A2A in April 2025. By June 23, 2025, the project moved to the Linux Foundation, with more than 100 companies backing it at launch, including AWS, Cisco, Microsoft, Salesforce, and SAP. As of the latest spec release (version 1.0.0), A2A ships official SDKs in Python, JavaScript, Java, C#/.NET, Go, and Rust, and framework integrations exist for Google's ADK, LangGraph, CrewAI, and Semantic Kernel. That is real engineering investment, well past the press-release stage. What is still thin is public evidence of A2A running multi-vendor agent handoffs in production at scale. Most of what is documented today is SDKs, samples, and framework support, not case studies of agent A from one company routing paid work to agent B from another company in the wild.

Why A2A exists

Picture an AI assistant asked to plan an international trip. Finishing that job means calling a flight-booking agent, a hotel-reservation agent, a currency-conversion agent, and a local-tours agent, each possibly built by a different company on a different stack. Before A2A, the only way to make that work was to wrap each of those agents as a tool and call it the way you'd call a function. The A2A project's own documentation calls this approach "fundamentally limiting": wrapping an agent as a tool strips out everything that makes it an agent, its ability to ask a clarifying question, negotiate scope, or push back mid-task, and reduces it to a single stateless input/output call.

The result, without a shared protocol, is what the A2A docs describe as a stack of point-to-point integrations: custom code per agent pair, security handled ad hoc or not at all, and a system that gets harder to maintain every time you add a new agent. None of that scales past a handful of agents, and it kills the idea of an open ecosystem where agents from different vendors can just work together.

The core mechanism: Agent Cards and tasks

A2A runs over HTTP(S) with JSON-RPC 2.0 as the message format, so it reuses infrastructure teams already have (load balancers, auth, TLS) instead of inventing new transport.

Agent Cards. Every A2A server, meaning every agent that wants to be discoverable, publishes a JSON document at a well-known URL (typically /.well-known/agent-card). This is the agent's business card: its identity, the skills it offers, its endpoint URL, what authentication it expects, and what content types it can handle. A client agent fetches this card first, reads it to decide whether the remote agent can actually help, and uses the security scheme listed in the card to authenticate before sending any real request. No card, no conversation.

Tasks and messages. Once a client has a card, it sends a message. The remote agent can answer in one of two ways. For something quick and self-contained, it replies with a plain message. For anything that needs real work, tracking, or multiple steps, it creates a Task: a stateful object with its own ID that moves through a defined lifecycle (submitted, working, input-required, completed, canceled, failed, and a few others). A contextId ties related tasks and messages together across a longer back-and-forth, and once a task hits a terminal state it's done. Any follow-up, even a small edit like "make that image red," spins up a new task in the same context rather than reopening the old one. That rule (tasks are immutable once finished) is what makes it possible to trace exactly which task produced which output.

For anything that takes a while, A2A supports three interaction patterns: plain request/response with polling, streaming updates over Server-Sent Events, and push notifications to a webhook for tasks that outlive the connection. The output of a task, the actual file, document, or structured result, is called an artifact, and it can stream back incrementally as the agent produces it.

The remote agent stays opaque throughout. A client never sees the other agent's internal reasoning, memory, or tool calls, only its declared capabilities and the messages and artifacts it produces. That's a deliberate design choice: it protects IP and lets a vendor swap out what's running behind an Agent Card without breaking anyone who depends on it.

A2A vs MCP: the distinction that actually matters

This is the question behind most "a2a protocol" searches, so here it is plainly. MCP and A2A are not competing standards. They sit at different layers and solve different problems.

MCP standardizes how one agent talks to its tools and data: a database, a calculator, a file system, a search API. Those things are usually stateless, and MCP's job is to describe their inputs and outputs so a model can call them predictably. A2A standardizes how one agent talks to another agent: something autonomous, that reasons, plans, holds state across a multi-turn exchange, and might say "I need more information before I can finish this" instead of just returning a value.

The A2A project's own comparison doc puts it this way: A2A is about agents partnering on tasks, MCP is about agents using capabilities. In a real system, both show up in the same stack. An A2A-based travel-planning agent might negotiate with a hotel-booking agent over A2A, while that hotel-booking agent internally uses MCP to query its own room-availability database. One protocol governs the conversation between agents; the other governs what each agent can reach on its own.

Real adoption vs announced adoption

Here's the honest read as of late 2026.

What's real: A2A reached a stable 1.0.0 spec. It has official SDKs in six languages. Its GitHub repository shows sustained engineering activity and thousands of forks, the kind of number you only see when developers are actually building on something. Framework-level support exists for Google's ADK, LangGraph, CrewAI, and Semantic Kernel, meaning you can build an A2A-compliant agent today without hand-rolling the protocol. Governance sits with the Linux Foundation, which matters because it means no single vendor, including Google, controls the spec's direction.

What's still mostly announcement-stage: broad, cross-company production deployments. The June 2025 launch came with supportive quotes from AWS, Cisco, Microsoft, Salesforce, and SAP, and those companies described integration plans (Cisco's Outshift explicitly said it was wiring A2A into its AGNTCY components, for instance) rather than shipped, load-bearing production traffic between independently owned agents. If you're evaluating A2A for a real build, treat the spec, SDKs, and framework integrations as production-ready, and treat any specific vendor's "we support A2A" claim as something to verify against their actual docs and endpoints rather than take at face value from a press quote.

FAQ

What does A2A stand for? Agent2Agent. It's commonly written as A2A or "the Agent2Agent protocol."

Who created A2A? Google published the initial protocol in April 2025. In June 2025, the project moved to the Linux Foundation, which now governs it as a vendor-neutral open source project.

Is A2A a Google product? No, not anymore. Google originated it and remains an active contributor, but governance sits with the Linux Foundation, and more than 100 companies, including AWS, Cisco, Microsoft, Salesforce, and SAP, backed the move to neutral governance.

What is an Agent Card? A JSON document an A2A-compliant agent publishes at a well-known URL, describing its identity, skills, endpoint, and authentication requirements. Other agents fetch it first to decide whether and how to interact with that agent.

Is A2A the same as MCP? No. MCP connects an agent to tools and data sources. A2A connects one agent to another agent as a peer, supporting multi-turn negotiation and delegation rather than a single tool call. Most real systems use both: A2A between agents, MCP inside each agent for its own tools.

Does A2A replace MCP? No. The two are designed to be complementary, not competing. The A2A project's own documentation is explicit that they solve different problems and expects most agentic systems to use both.

Is A2A actually being used in production, or is it still mostly announced? Both, depending on what you mean. The spec, SDKs, and framework integrations are real and shipping; the 1.0.0 release and multi-language SDK support back that up. Documented, at-scale, cross-vendor production traffic between independently owned agents is thinner and harder to verify. Treat vendor "A2A support" claims individually rather than assuming universal production maturity from the size of the launch coalition.

What frameworks support A2A today? Google's Agent Development Kit (ADK), LangGraph, CrewAI, and Semantic Kernel have documented A2A integrations. Official SDKs also exist in Python, JavaScript, Java, C#/.NET, Go, and Rust for teams building agents without a higher-level framework.

Where this fits if you're building agents

If you're scoping a multi-agent system today, MCP is the settled choice for connecting any single agent to its tools; that decision isn't really in question anymore. A2A is the newer, and still-settling, choice for the layer above it: getting separately built agents to discover and delegate to each other. It's mature enough to build on (stable spec, real SDKs, serious backers) but young enough that you should verify any specific integration claim before betting a deadline on it.

AY Automate builds agent systems on Claude Code, the Claude Agent SDK, and the MCP and A2A ecosystems. If you're scoping a multi-agent build and trying to figure out where A2A actually helps versus where a simpler MCP-only design is enough, book a consultation and we'll walk through your architecture.