TL;DR:

  • Google’s A2A protocol is an open standard for agent-to-agent communication across different frameworks and organisations
  • Agents advertise capabilities via Agent Cards at /.well-known/agent.json and communicate using HTTP, SSE, and JSON-RPC 2.0
  • Now at version 1.0.1 with 150+ organisational supporters, A2A is emerging as the enterprise standard for multi-agent interoperability

Most multi-agent systems today are islands. You build a research agent in LangGraph, a data analysis agent in AutoGen, and a document generation agent using the Anthropic SDK — and then spend significant engineering time writing the glue code that lets them talk to each other. You rebuild that glue for every new agent you add. The whole arrangement becomes a maintenance burden.

Google’s Agent2Agent (A2A) protocol is the answer to this problem. It’s an open standard, now governed by the Linux Foundation and supported by 150+ organisations including Salesforce, MongoDB, ServiceNow, Accenture, and IBM, that gives AI agents a common language for discovering each other and delegating work across framework and organisational boundaries.

The Core Idea: Agent Cards and Task Delegation

A2A has two central concepts. The first is the Agent Card — a JSON metadata file that every A2A-compatible agent publishes at /.well-known/agent.json. An Agent Card declares what the agent can do: its name, endpoint URL, available skills, supported input and output types, and authentication requirements. Think of it like a business card that another agent can read to understand whether you can help with a given task.

The second concept is task delegation. When one agent needs work done that another agent is better suited for, it sends a task to that agent via A2A, waits for progress updates (via Server-Sent Events), and receives the result when it’s done. The requesting agent doesn’t need to know how the other agent works internally — it just sends a structured request and handles the response.

Here’s what a minimal Agent Card looks like:

{
  "name": "Data Analysis Agent",
  "description": "Analyses datasets and generates statistical summaries",
  "url": "https://agents.example.com/data-analyst",
  "version": "1.0",
  "skills": [
    {
      "id": "analyse-dataset",
      "name": "Analyse Dataset",
      "description": "Accepts a dataset URL, returns statistical summary and key insights",
      "inputModes": ["text/plain", "application/json"],
      "outputModes": ["application/json", "text/markdown"]
    }
  ],
  "authentication": {
    "schemes": ["Bearer"]
  }
}

Any A2A-compatible agent can read this card, understand what the data analyst can do, and delegate appropriate work to it.

How It Differs from MCP

A2A is often mentioned alongside MCP (Model Context Protocol), but they solve different problems. MCP connects an agent to tools and data sources — APIs, databases, file systems. It’s about what an agent can access. A2A connects agents to other agents — it’s about task delegation and coordination between autonomous systems.

In practice, they’re complementary. A single agent might use MCP to access tools (run a SQL query, read a file, call an API) while using A2A to delegate entire tasks to specialised agents that handle their own tool use internally. The requesting agent doesn’t need visibility into what tools the delegated agent uses.

Version 1.0.1 and the Extension Mechanism

A2A 1.0.1, released in May 2026, added an extension mechanism that allows agents to declare and support non-standard capabilities beyond the base protocol. Extensions can define new data formats, new RPC methods, or new state machine transitions for long-running tasks.

This matters because different domains have different coordination requirements. A medical imaging agent and a financial analysis agent both benefit from A2A’s base task delegation model, but they may need domain-specific data types and workflow patterns. The extension mechanism allows that without fragmenting the protocol.

Version 1.0.1 also improved the streaming model. Long-running tasks can send intermediate progress updates — structured messages that tell the requesting agent what stage the work is at — not just a final result. For workflows where the end-to-end task might take minutes, that’s a significant usability improvement.

Getting Started

The simplest way to try A2A is with Google’s Agent Development Kit (ADK), which has native A2A support. But A2A is framework-agnostic, and there are A2A client libraries for Python and TypeScript.

A minimal Python server that exposes an agent via A2A:

from a2a.server import A2AServer, AgentCard, Skill
from a2a.types import TaskRequest, TaskResult

agent_card = AgentCard(
    name="Summariser Agent",
    description="Summarises long documents into concise bullet points",
    url="http://localhost:8000",
    version="1.0",
    skills=[
        Skill(
            id="summarise",
            name="Summarise Document",
            description="Takes a document and returns a bullet-point summary",
            input_modes=["text/plain"],
            output_modes=["text/markdown"],
        )
    ]
)

async def handle_task(request: TaskRequest) -> TaskResult:
    document = request.message.parts[0].text
    summary = await your_llm_summarise(document)
    return TaskResult(content=summary)

server = A2AServer(agent_card=agent_card, handler=handle_task)
server.run(port=8000)

Any other A2A-compatible agent can now discover your summariser at /.well-known/agent.json, understand what it does, and delegate summarisation tasks to it.

When to Use A2A

A2A makes sense when you have agents that need to collaborate across team or organisational boundaries, agents built on different frameworks that need to interoperate, or specialised agents that other systems should be able to discover and delegate to without tight coupling.

For single-team, single-framework orchestration, the native multi-agent features of your framework (LangGraph’s subgraph routing, AutoGen’s GroupChat, the Microsoft Agent Framework’s event subscriptions) are simpler. A2A adds value when the boundary between agent teams or systems is where interoperability breaks down — and in enterprise deployments, it usually does.

The 150+ organisational supporters is a signal that vendor support is materialising. Several major enterprise software providers have committed to A2A-compatible agent endpoints in their platforms. By the end of 2026, the expectation is that most enterprise agentic software will publish Agent Cards as a standard interoperability feature.

References