What Is the A2A (Agent2Agent) Protocol?

Key facts

What is the A2A protocol?

The Agent2Agent (A2A) protocol is an open standard for agent-to-agent communication. It defines how one AI agent can discover another agent, learn what it can do, send it a task, follow progress, and receive results — even if the two agents were built by different companies with different frameworks, such as LangGraph, CrewAI or Google's ADK.

Google introduced A2A in April 2025 with a large group of technology partners and later handed it to the Linux Foundation, so no single company controls it. The specification and SDKs (Python, JavaScript, Java, Go, .NET) are open source at a2a-protocol.org.

Why it matters: real businesses will not run one giant agent. A travel agent will ask an airline's agent for fares; a hiring agent will ask a background-check agent for a report. Without a shared protocol, every pair of agents needs custom glue code. A2A is that shared protocol.

How A2A works: the core ideas

• Client agent and remote agent — the client agent delegates work; the remote agent (the A2A server) does it. Remote agents are *opaque*: they share results, not their internal prompts, memory or tools.
• Agent Card — a JSON document that describes a remote agent: its name, description, skills, the endpoints it listens on, and how to authenticate. By convention it is published at /.well-known/agent-card.json on the agent's domain, so other agents can discover it.
• Task — a unit of work with an ID and a lifecycle (for example submitted → working → input-required → completed, failed or canceled). Long jobs can run for minutes or hours.
• Message — one turn in the conversation between agents, made of parts: text, files, or structured JSON data.
• Artifact — the output a task produces, such as a report, an image or a JSON result.
• Streaming and push notifications — progress updates over server-sent events, or webhooks for very long tasks.

A simplified Agent Card looks like this (field names vary between spec versions — check the current spec before you publish one):

{
  "name": "Fee Assistant",
  "description": "Answers questions about course fees and payment plans.",
  "version": "1.0.0",
  "capabilities": { "streaming": true },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "fee-lookup",
      "name": "Fee lookup",
      "description": "Looks up the fee and early-bird deadline for a course.",
      "examples": ["How much is the AI agents course?"]
    }
  ]
}

A2A vs MCP: what is the difference?

This is the most common question, and the answer is short: MCP connects an agent to tools and data. A2A connects an agent to other agents. They are complementary, and many systems use both.

A useful picture: inside each company, agents use MCP to reach their own tools. Between companies (or between teams), agents use A2A to talk to each other. Read the full MCP guide for the other half.

A2A vs multi-agent frameworks

Frameworks such as LangGraph, CrewAI and AutoGen already let several agents cooperate — but only inside one program, written in one framework. A2A is for agents that live in different services, often owned by different teams, written in different languages. Many frameworks can now expose an agent as an A2A server or call A2A agents, so you can build with your favourite framework and still interoperate. See AI agent frameworks compared.

When do you need A2A?

• You don't need it yet if you are building a single agent, or several agents inside one LangGraph app. Plain function calls are simpler.
• You need it when agents are separate services owned by different teams or companies, when you want to offer your agent for others to call, or when you want to swap one specialist agent for another without rewriting the caller.
• Security still matters. Treat everything a remote agent returns as untrusted input — the same prompt-injection rules as for web pages and tool results apply. Authenticate both sides and limit what a remote agent's answer can trigger.

For students, the practical path is: build one solid agent, add tools through MCP, split it into multiple agents in LangGraph, and only then expose agents over A2A. The agentic AI roadmap lays out that order.

Learn MCP and agent-to-agent systems live

AI Season's 6 weeks agentic AI course covers the full stack these protocols sit on: tool calling, RAG, agent design patterns, LangGraph, the Model Context Protocol and agent SDKs, agent-to-agent communication, guardrails, deployment and a voice agent — 12 live sessions in Urdu and English with projects in every module.

Cohort 02 starts 1st January 2027. Early-bird fee PKR 3,000 (about ₹1,040) until 30th November 2026, and the top three scorers are refunded in full.

Frequently asked questions

What is the A2A protocol?

A2A (Agent2Agent) is an open protocol for AI agents to communicate with each other. An agent publishes an Agent Card describing its skills; other agents discover it, send it tasks over HTTP using JSON-RPC, and receive messages, progress updates and results. Google started it in 2025 and it is now governed by the Linux Foundation.

What is the difference between A2A and MCP?

MCP connects an AI agent to tools, data and prompts. A2A connects AI agents to other AI agents. MCP's other side does exactly what it is told; A2A's other side is an autonomous agent that can reason, ask questions and run long tasks. Most real systems can use both.

What is an Agent Card in A2A?

An Agent Card is a JSON file that describes an A2A agent: its name, description, skills, service endpoints, supported input and output types, and authentication requirements. It is usually served at /.well-known/agent-card.json so other agents can discover it.

Is A2A only for Google agents?

No. A2A is an open, vendor-neutral standard under the Linux Foundation, with SDKs in several languages, and is supported by many companies and agent frameworks beyond Google.

Should a beginner learn A2A or MCP first?

Learn MCP first. Most agents need tools and data before they need to talk to other agents, and A2A makes more sense once you have built and deployed at least one tool-using agent.