Most AI agents work alone. They call APIs, query databases, and return results to a single user. But the real unlock for agentic systems is agents working together: one agent hands a subtask to another, gets the result back, and keeps going. That is what the Agent2Agent protocol makes possible.

A2A is an open protocol, originally developed by Google and now hosted by the Linux Foundation, that gives AI agents a standard way to discover each other, exchange messages, and coordinate work. It does not matter which framework built the agent or which vendor hosts it. If both sides speak A2A, they can collaborate.

The Core Idea

Today’s agent frameworks (LangChain, CrewAI, Autogen, and others) handle multi-agent workflows inside their own ecosystems. But the moment you need an agent built on one framework to talk to an agent built on another, things break down. There is no shared protocol. No common message format. No way for one agent to find out what another agent can do.

A2A solves this by defining a thin communication layer between agents. Think of it as HTTP for agent-to-agent calls. Each agent exposes a standard endpoint, advertises its capabilities, and accepts tasks from other agents using a shared message format.

The protocol launched in April 2025 with more than 50 technology partners, including Salesforce, SAP, ServiceNow, PayPal, Atlassian, and LangChain. It moved to the Linux Foundation in June 2025 and has since shipped a v1 specification with SDKs in Python and JavaScript.

How It Works

A2A follows a client-server model with three phases: discovery, authentication, and communication.

Discovery. Every A2A-compatible agent publishes an Agent Card, a JSON file hosted at a well-known URL. The card lists the agent’s name, description, capabilities, supported data types, and service endpoint. When a client agent needs help with a task, it fetches agent cards to find the right remote agent for the job. This is similar to how MCP servers advertise their tools, but at the agent level instead of the tool level.

Authentication. Once the client agent picks a remote agent, it authenticates using the security scheme declared in the agent card. A2A supports API keys, OAuth 2.0, and OpenID Connect, the same schemes used in the OpenAPI specification. After authentication, the remote agent handles authorization and access control.

Communication. The client agent sends a task to the remote agent over HTTPS using JSON-RPC 2.0. The remote agent processes the task and sends back a response containing messages and artifacts (files, images, structured data, or any other output). If the remote agent needs more information, it can request additional input before completing the task.

For long-running tasks that take hours or days, A2A supports asynchronous updates through push notifications via webhooks and real-time streaming via server-sent events (SSE). This means an agent can kick off a background research task, get status updates, and collect the final result without blocking.

A2A vs MCP: Different Problems, Same Stack

Developers building with MCP servers often ask how A2A fits in. The short answer: they are complementary, not competing.

MCP (Model Context Protocol) standardizes how an AI agent connects to tools, data sources, and services. It is the protocol for agent-to-tool communication. When your agent needs to query a database, call an API, or read a file system, MCP handles that connection.

A2A standardizes how agents connect to other agents. It is the protocol for agent-to-agent communication. When your agent needs to delegate a subtask to a specialized agent built by a different team or vendor, A2A handles that handoff.

In practice, a single workflow might use both. An inventory agent uses MCP to check stock levels in a database. When stock runs low, it uses A2A to contact a supplier’s purchasing agent and place an order. The inventory agent never needs to know how the supplier’s agent works internally. A2A treats both agents as opaque: they share messages and results, not internal memory or tool configurations.

This opacity is a feature. It means agents can collaborate without exposing proprietary logic, training data, or internal tool implementations.

Key Concepts

A few terms worth knowing if you are building with A2A:

Agent Card. The JSON file that describes an agent’s identity and capabilities. Functions like a business card for your agent. Hosted at a public URL so other agents can discover it.

Task. The unit of work in A2A. A client agent creates a task, the remote agent processes it, and the task moves through defined states: submitted, working, input-required, completed, or failed.

Artifact. The output a remote agent produces after completing a task. Can be a document, image, spreadsheet, or any structured data.

Message. A single exchange in a conversation between agents. Messages contain one or more Parts (text, files, or JSON data).

Why It Matters for Developers

If you are building MCP servers or agent skills today, A2A changes the surface area of what your agents can do. Instead of building one agent that handles everything, you can build specialized agents that each do one thing well and compose them using A2A.

A customer support workflow might chain three agents: one for ticket triage (built on your internal framework), one for knowledge base search (an MCP-connected agent using communication and messaging servers), and one for billing adjustments (a vendor agent exposed over A2A). Each agent is independently developed, deployed, and maintained.

Who Supports A2A Today

The partner list has grown well past the original 50. Notable supporters include:

  • Google Cloud built and maintains the protocol. Vertex AI Agent Builder has native A2A support.
  • Salesforce ships A2A support in Agentforce, their agent platform.
  • SAP is connecting Joule, their AI copilot, to external agents via A2A.
  • ServiceNow integrates A2A for cross-platform support workflows.
  • LangChain and DataStax (Langflow) support A2A as a communication layer between agents built on their frameworks.
  • PayPal is exploring A2A for commerce-related agent interactions.

The Linux Foundation stewardship means the protocol is governed as an open-source project with a clear contribution path, not tied to any single vendor’s roadmap.

FAQ

How is A2A different from just calling an API? APIs are stateless request-response pairs. A2A adds agent discovery (agent cards), task lifecycle management (submitted through completed), multi-turn conversations, streaming, and push notifications. It is purpose-built for autonomous agents that need to negotiate, collaborate, and handle long-running work.

Do I need A2A if I already use MCP? MCP connects agents to tools. A2A connects agents to agents. If your system only needs one agent calling MCP servers, you do not need A2A. If you need multiple agents coordinating across vendors or teams, A2A provides the interop layer.

Is A2A production-ready? The v1 specification is published, SDKs exist in Python and JavaScript, and major platforms (Google Cloud, Salesforce, SAP) have shipped integrations. It is still a young protocol, but it is past the experimental stage.

Can A2A agents use MCP servers? Yes. An A2A-compatible agent can use MCP internally for its tool connections while exposing an A2A endpoint for inter-agent communication. The two protocols operate at different layers and work together cleanly.