What Is A2A Protocol (Agent2Agent)? How Agents Talk to Each Other

AI agents built by different teams rarely speak the same language. One runs on LangGraph, another on CrewAI, a third sits behind a vendor's API. A2A is the open standard designed to let them work together anyway.

This guide explains what A2A is, how it works at the wire level, how it relates to MCP, and when it is worth adopting.

What Is the A2A Protocol?

The A2A (Agent2Agent) protocol is an open standard that lets AI agents from different vendors and frameworks find each other, hand off tasks, and return results over standard web transports. Each agent keeps its internal memory, prompts, and tools private. Only the task, its messages, and its outputs cross the boundary.

A2A version 1.0 is the current stable release. The A2A v1.0 release notes describe it as "marking the first stable, production-ready version of the open standard for communication between AI agents." The project is hosted by the Linux Foundation.

What Problem Does A2A Solve?

A2A solves the integration problem between independent agents. Without a shared protocol, every pair of agents needs custom glue code for discovery, request formats, status updates, and authentication. Connecting five agents from five vendors can mean many one-off integrations.

A2A replaces that glue with one contract. Any A2A client can read any A2A server's capabilities, send it a task, and track the result the same way.

The need grows when teams split work across specialized agents. Gartner's forecast is a prediction, not a measured result, and it does not mention A2A by name. Still, the Gartner agentic AI forecast states: "By 2027, Gartner predicts one-third of agentic AI implementations will combine agents with different skills to manage complex tasks within application and data environments."

Where A2A Came From and Who Runs It Now

Google created A2A, but a vendor-neutral foundation now governs it. Per Google's A2A announcement on April 9, 2025: "Today, we're launching a new, open protocol called Agent2Agent (A2A), with support and contributions from more than 50 technology partners."

Two months later, the protocol moved to the Linux Foundation. The Linux Foundation launch announcement from June 23, 2025 says A2A was "launched by Google in April and with growing support from more than 100 leading technology companies."

The August 2025 merger ended a competing effort. According to the post on the ACP and A2A merger, "the ACP team will be winding down active development and will begin contributing its technology and expertise directly to A2A."

Adoption numbers come from the project itself, so treat them as self-reported. The A2A one-year milestones report from April 2026 states: "Since April 2025, the number of supporting organizations has grown from more than 50 to over 150."

The latest governance change came in August 2026. The post announcing that A2A joins AAIF states: "The Agent2Agent (A2A) protocol has officially been accepted as a Growth Stage project at the Agentic AI Foundation (AAIF)."

How the A2A Protocol Works

A2A works through two roles: a client agent that sends a task and a remote agent that does the work. The remote agent is also called the A2A server. The client never sees how the remote agent reasons or which tools it calls.

A typical exchange follows six steps:

1. Discover: The client reads the remote agent's Agent Card.
2. Authenticate: The client gets credentials using a scheme the card declares.
3. Send: The client sends a message that starts a task.
4. Process: The remote agent works on the task and updates its state.
5. Update: The client receives progress through streaming, push notifications, or polling.
6. Collect: The remote agent returns the results as artifacts.

This is the same delegation idea behind AI agent orchestration patterns, except the agents run as separate services. A2A defines the network contract between them.

Agent Cards: How Agents Find Each Other

An Agent Card is a JSON document that describes what a remote agent can do and how to reach it. In v1.0, every A2A server must publish one. The standard location is https://{server_domain}/.well-known/agent-card.json. Clients can also find cards through registries or direct configuration.

An Agent Card lists the agent's name, skills, supported interfaces, capabilities, and security schemes. Each interface names a protocol binding. The A2A specification states: "The core ones officially supported are JSONRPC, GRPC and HTTP+JSON."

This simplified Agent Card describes a web research agent. It is trimmed for readability, so check the specification for every required field.

{
  "name": "Web Research Agent",
  "description": "Researches topics on the live web and returns cited summaries",
  "version": "1.0.0",
  "supportedInterfaces": [
    {
      "url": "https://research.example.com/a2a/v1",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "competitor-pricing",
      "name": "Competitor Pricing Research",
      "description": "Finds and summarizes recent pricing changes with source URLs",
      "tags": ["research", "pricing", "citations"],
      "examples": ["What did our top 3 competitors change on their pricing pages this week?"]
    }
  ]
}

The skills array is useful for routing. A client agent, or the LLM inside it, can read skill descriptions to decide which remote agent should get a task.

Tasks, Messages, Parts, and Artifacts

A2A moves work through four core objects. Each one has a narrow job:

• Task: The unit of work. It has an ID and a state that changes as work progresses.
• Message: One turn in the conversation. Per the spec's definition of A2A message roles, ROLE_USER marks a message from the client and ROLE_AGENT marks a message from the remote agent.
• Part: A piece of content inside a message or artifact. A part can hold text, a file, or structured JSON data.
• Artifact: An output the task produces, such as a report, a file, or a JSON object.

A client starts a task with the SendMessage method. Over the JSON-RPC binding, a simplified request looks like this:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "parts": [
        { "text": "Summarize pricing changes on these 3 competitor sites this week." }
      ]
    }
  }
}

The response contains either a task object to track or a direct message for quick answers. For live progress, the client uses SendStreamingMessage instead.

The A2A Task Lifecycle

Every A2A task moves through a defined set of A2A task states. Version 1.0 uses names such as TASK_STATE_WORKING. The table below drops the prefix for readability.

The paused states make multi-turn work possible. A remote agent can stop at INPUT_REQUIRED, ask a clarifying question, and resume once the client replies. Final states accept no further messages, so a follow-up needs a new task.

Transports, Streaming, and Push Notifications

A2A v1.0 supports three standard transports, called bindings: JSON-RPC 2.0 over HTTPS, gRPC, and HTTP+JSON (REST style). All three carry the same operations, so a team can pick the one its stack already uses. Custom bindings are also allowed.

Clients get task updates in one of three ways:

• Streaming: The remote agent pushes updates over Server-Sent Events (SSE) while the connection stays open. This fits tasks that finish in seconds or minutes.
• Push notifications: The remote agent calls a client webhook when the state changes. The spec's A2A push notification setup example uses this for a long-running report job, and it requires the Agent Card to set pushNotifications to true.
• Polling: The client calls GetTask on a schedule. This is the simplest option and works over all three bindings.

Authentication and Security

A2A reuses standard web authentication instead of inventing its own. The Agent Card declares which security schemes the agent accepts. The v1.0 list of A2A security schemes covers API keys, HTTP auth (such as Bearer tokens), OAuth 2.0, OpenID Connect, and mutual TLS.

Credentials travel in HTTP headers, not inside A2A messages. A server can also offer an authenticated extended Agent Card. This version can show extra skills or settings to clients that have signed in.

Authentication does not solve every risk. A remote agent's output is still untrusted input to the client. Teams should validate artifacts before acting on them and watch for prompt injection inside returned text.

A2A vs MCP: How the Two Protocols Fit Together

A2A connects agents to other agents, while MCP connects an agent to tools and data. The Model Context Protocol (MCP) gives an agent access to functions such as a search API, a database, or a file system. A2A lets that agent hand a whole task to another agent. For a deeper look at the tool side, see Model Context Protocol explained.

Both protocols are now AAIF projects. The post on how MCP joins the Agentic AI Foundation states: "MCP will become a founding project of the newly created foundation."

The two protocols stack. A client agent can delegate a task to a remote agent over A2A. That remote agent can then call its own tools over MCP to finish the job.

A2A Protocol Example: A Research Agent Behind an A2A Endpoint

A research agent exposed over A2A shows how the layers fit together. Picture a planning agent that needs a weekly summary of competitor pricing changes.

1. Discovery: The planning agent fetches the research agent's Agent Card and matches the competitor-pricing skill.
2. Delegation: It sends a SendStreamingMessage request with the task and the three competitor URLs.
3. Tool use: The research agent searches and scrapes live pages using its own tools. These might be the Olostep MCP server or direct API calls.
4. Progress: The planning agent receives WORKING updates over SSE.
5. Result: The research agent returns an artifact with a summary and source URLs. A tool such as the Olostep Answers endpoint returns a sources array that can supply those source URLs.

The planning agent never learns which search provider or scraper the research agent used. It only sees the task state and the artifact. That boundary lets each team swap internal tools without breaking the integration.

The same design can also run inside one process. Olostep's multi-agent market research pipeline chains research, extraction, trend, and brief agents with the OpenAI Agents SDK. A2A becomes useful when those agents need to run as separate services owned by separate teams.

The example also shows where web data sits. A2A carries the task and the result. Fetching fresh, structured web data happens beneath it, in the remote agent's tool layer.

Is A2A Dead? When A2A Is Worth It (and When It Isn't)

A2A is not dead, but it fits a specific set of agent systems. Version 1.0 shipped in March 2026, and the protocol joined AAIF in August 2026. Still, many agent systems do not need a network protocol between their agents.

The main cost is overhead. Each delegation is a network call between services. If the remote agent uses its own LLM, the task also pays for a second model call, which adds latency and token spend.

A2A is a good fit when:

• Agents belong to different teams or vendors: A shared contract avoids custom glue for each pair.
• Agents deploy separately: Each service can scale, version, and fail on its own.
• Tasks run long or need input midway: The task lifecycle handles pauses, streaming, and webhooks.
• Internals must stay private: Opaque agents let a vendor expose skills without exposing prompts or tools.

A2A is usually overkill when:

• All agents live in one codebase: An in-process orchestrator is simpler and faster.
• The "agent" is really a tool: If it takes a request and returns data, expose it through MCP or a plain API.
• Debugging speed matters most: Opaque remote agents are harder to trace than local function calls.

Agent stacks that delegate work across services need both layers. A2A handles delegation between agents. A tool layer handles how AI agents access the web and other data, and that layer affects the quality of what each agent returns.

FAQ

Is the A2A Protocol From Google?

Yes, Google created A2A and announced it in April 2025. The Linux Foundation has hosted it since June 2025, and it became part of the Agentic AI Foundation in August 2026.

What Is the Purpose of the A2A Protocol?

A2A gives independent AI agents one standard way to discover each other, delegate tasks, and return results. It removes the need for custom integration code between each pair of agents.

Is A2A a Replacement for MCP?

No, A2A and MCP solve different problems and work together. A2A connects agents to agents, while MCP connects an agent to tools and data.

Where Is the A2A Specification?

The official specification is published at a2a-protocol.org. Version 1.0, released in March 2026, is the current stable version.

What Happened to IBM's ACP?

IBM's Agent Communication Protocol merged into A2A in August 2025. The ACP team wound down active development and began contributing to A2A instead.

Which Languages Have A2A SDKs?

The a2aproject organization on GitHub maintains official SDKs for several languages, including Python and JavaScript. The A2A GitHub repository links to the current SDK list.