The problem A2A solves

Companies now run agents from many vendors: one in a CRM, one in a ticketing system, one built in-house. Without a shared protocol, each pair needs a custom integration, and that work grows quickly as agents multiply. A2A gives them a common way to talk while each agent keeps its internal logic, memory, and tools private. One agent can delegate to another without seeing how the other works.

The protocol runs on familiar web standards. The specification defines three standard bindings, JSON-RPC, gRPC, and HTTP+JSON/REST, and they must be functionally equivalent.

A2A vs MCP

This is the most common point of confusion. The official docs call MCP "vertical" because it deepens one agent's abilities, and A2A "horizontal" because it links agents across teams and organizations. They are complements, not rivals.

The official repair-shop example: A customer tells a Shop Manager agent about a rattling noise over A2A, and they talk through the problem. A Mechanic agent uses a diagnostic scanner and repair manual through MCP, then asks a Parts Supplier agent for stock over A2A. As the docs put it, MCP gives each agent depth and A2A gives your system reach.

Core concepts

Discovery usually starts at a well-known URL, https://{server_domain}/.well-known/agent-card.json. Registries and direct configuration are also allowed. Here is a minimal card, trimmed to the required fields:

{
  "name": "Library Booking Agent",
  "description": "Finds and reserves study rooms.",
  "version": "1.0.0",
  "supportedInterfaces": [
    {
      "url": "https://agents.example.edu/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": { "streaming": true, "pushNotifications": false },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "reserve-room",
      "name": "Reserve a study room",
      "description": "Books a room for a date, time, and group size.",
      "tags": ["booking", "library"]
    }
  ]
}

The task lifecycle

Real work can take minutes or days, or stop to wait for a person. So A2A models each job as a task with explicit states:

Clients follow progress in three ways: polling with GetTask, streaming through SendStreamingMessage and SubscribeToTask, or registering a webhook for push notifications. Streaming and push each require the matching capability in the Agent Card.

Worked example: a two-agent booking

A student's assistant needs a room for four people on Friday at 3 pm. The Library Booking Agent has its own systems. A typical exchange, using the method names from the 1.0 spec, looks like this:

1. The assistant fetches the library's Agent Card and sees the reserve-room skill.
2. It authenticates using a scheme named in the card, then calls SendMessage with the request.
3. The library agent creates a task, which moves to WORKING.
4. Only two rooms are free, so the task moves to INPUT_REQUIRED with a message asking which one.
5. The assistant asks the student, then sends the choice with the same task ID.
6. The task moves to COMPLETED, and the confirmation arrives as an Artifact.

The assistant never touched the booking database. Inside the library agent, MCP might handle that connection, but the assistant does not need to know.

Timeline and adoption

The foundation says the project has more than 150 partner organizations. That counts support, not production use. Many announcements describe integrations rather than high-volume cross-company traffic, so treat the number as a measure of interest.

Honest caveats

• A protocol does not create trust. A2A tells agents how to talk, not whether the other agent is honest or competent. Agent Cards can be signed with JSON Web Signatures, but signing is optional and proves origin, not good behavior.
• Messages can carry attacks. Text from another agent is untrusted input and can include prompt injection, so apply least privilege and require human approval for risky actions.
• You may not need it. If all your agents live in one codebase, a framework's internal calls are simpler. A2A earns its keep at team, vendor, and company boundaries.
• Versions matter. Version 1.0 renamed operations, and older material may show earlier names. Clients declare a version with the A2A-Version header.

Frequently asked questions

Is A2A a replacement for MCP? No. Use MCP to connect an agent to tools and data, and A2A to connect it to other agents. Many systems will use both.

Who controls A2A? It began at Google, but it is now a Linux Foundation project hosted by the Agentic AI Foundation, under the Apache 2.0 license.

Do both agents have to use the same framework or model? No. That is the point of the protocol. Each side only has to implement the standard interface.

Is an A2A agent just an API? An API usually exposes fixed operations. An A2A agent accepts goals, can ask follow-up questions, and manages long-running stateful tasks.

How do agents find each other? Through a well-known Agent Card URL, a registry, or direct configuration.