Google’s A2A Protocol: The Complete Guide for 2026

What Is the A2A Protocol?

The A2A (Agent-to-Agent) protocol is an open specification, originally published by Google in April 2025, that standardises how one AI agent asks another AI agent to do work on its behalf. It defines three things: a way for agents to advertise what they can do, a shape for the tasks they exchange, and a transport for sending those tasks over the wire.

That is deliberately a small surface area. A2A does not tell you which LLM to use, which agent framework to build on, which vector database to query, or how to authenticate your users. Those are left to you. The only thing A2A cares about is the contract between agent A and agent B — so that a LangGraph agent in your finance team can delegate a compliance check to a CrewAI agent in the legal team without a bespoke integration.

The analogy most people reach for is HTTP. HTTP does not care whether your backend is Rails, Django, or Go — it just defines the shape of requests and responses. A2A plays the same role for agents. You get cross-framework interoperability without having to normalise every team onto the same stack.

One Year In: Adoption and Production Footprint

When Google announced A2A at Cloud Next 2025 it had roughly 50 launch partners. That number has now tripled. The most cited figure in the April 2026 Agentic AI Foundation status report is 150+ organisations with A2A in production — not in pilot, not on a roadmap, but routing real tasks between agents today.

Concrete examples:

Governance moved under the Linux Foundation’s Agentic AI Foundation in mid-2025, alongside MCP. That transition mattered: it signalled to large enterprises that A2A was not a Google-only spec they could be locked into, and removed the last procurement objection for conservative buyers. Spec changes now go through a public RFC process, and v1.2 (landed in March 2026) is the current stable release.

Framework support is equally broad. Native A2A is in Google ADK, LangGraph, CrewAI, LlamaIndex Agents, Semantic Kernel, and AutoGen. Python and TypeScript reference SDKs are actively maintained. For a broader landscape view, see our AI agent framework comparison and our Google ADK vs LangChain vs CrewAI breakdown.

A2A vs MCP: Two Layers, Not Two Choices

Almost every question I get about A2A is some version of “do I use A2A or MCP?” The answer is both, because they solve different problems at different layers.

A realistic production agent is both at once. It is an MCP client when it reaches for Postgres, GitHub, or a bespoke internal API. It is an A2A server when another agent calls it with a task. It is an A2A client when it delegates a sub-task to a specialist agent. Mentally separating these two axes is the fastest way to stop the framework-vs-framework debates.

Architecture Deep Dive

The Agent Card

An Agent Card is a JSON document that lives at a well-known URL. A client fetches it once, caches it, and uses it to decide whether this agent can help with the task at hand. Here is a trimmed real example:

{
  "name": "contract-reviewer",
  "description": "Reviews commercial contracts, flags risky clauses, suggests redlines.",
  "version": "1.4.2",
  "url": "https://agents.rapidclaw.dev/contract-reviewer",
  "provider": { "organization": "Acme Legal", "url": "https://acme.example" },
  "authentication": {
    "schemes": ["bearer", "mtls"],
    "scopes": ["contracts:read", "contracts:write"]
  },
  "skills": [
    {
      "id": "review-msa",
      "name": "Review a Master Service Agreement",
      "description": "Flag risky clauses and propose redlines for an MSA.",
      "inputModes":  ["text/plain", "application/pdf"],
      "outputModes": ["text/markdown", "application/json"],
      "examples": ["Review the attached MSA for an SMB vendor."]
    }
  ],
  "defaultModalities": {
    "input":  ["text/plain", "application/pdf"],
    "output": ["text/markdown"]
  },
  "supportsStreaming": true,
  "supportsPushNotifications": true
}

A good Agent Card is the most important document you’ll write. It is what other teams read to decide whether to integrate with you. Treat it like an OpenAPI spec: version it, publish it, and do not break existing callers without a deprecation window.

Tasks and the task lifecycle

A Task is the unit of work. It has an ID, a state machine (submitted → working → input-required → completed/failed/canceled), a message history, and a list of typed artifacts produced by the server.

Two things to keep in mind about tasks:

• They can be long-running. An A2A agent might take minutes to come back. Clients should use SSE for streaming updates or register a push-notification URL for fire-and-forget flows.
• They can be multi-turn. The agent can return input-required to ask for clarification. This is how human-in-the-loop patterns survive the hand-off between agents.

Transport: JSON-RPC over HTTP + SSE

The transport is intentionally boring. Requests are JSON-RPC 2.0. The server responds with either a single JSON envelope or an text/event-stream for streaming tasks. The methods you care about 90% of the time are:

• tasks/send — create a task (non-streaming)
• tasks/sendSubscribe — create a task and stream events
• tasks/get — poll task state
• tasks/cancel — cancel a running task

Because the transport is HTTP, every existing piece of infrastructure — load balancers, WAFs, mTLS, OIDC, OpenTelemetry — works without modification. This is a large part of why A2A landed in the enterprise so fast.

Building an A2A Agent in Python

Let’s build a minimal A2A server using the reference Python SDK. The agent exposes a single skill — summarising a chunk of text — and supports streaming responses.

from a2a.server import A2AServer, AgentCard, Skill, TaskContext
from a2a.types import Message, TextPart, TaskState
from anthropic import Anthropic

card = AgentCard(
    name="summariser",
    description="Summarises long documents into short briefs.",
    version="1.0.0",
    url="https://agents.example.com/summariser",
    skills=[
        Skill(
            id="summarise",
            name="Summarise a document",
            description="Produce a 5-bullet brief from any text input.",
            input_modes=["text/plain"],
            output_modes=["text/markdown"],
            examples=["Summarise this article: ..."],
        )
    ],
    supports_streaming=True,
    authentication={"schemes": ["bearer"]},
)

client = Anthropic()

async def handle_task(ctx: TaskContext):
    user_text = ctx.latest_user_text()

    # Tell the client we're working
    await ctx.update_status(TaskState.WORKING)

    # Stream tokens from the model back to the A2A client
    with client.messages.stream(
        model="claude-opus-4-7",
        max_tokens=1024,
        system="You produce tight, 5-bullet briefs. Markdown only.",
        messages=[{"role": "user", "content": user_text}],
    ) as stream:
        for chunk in stream.text_stream:
            await ctx.stream_message(
                Message(role="agent", parts=[TextPart(text=chunk)])
            )

    await ctx.complete()

server = A2AServer(agent_card=card, task_handler=handle_task)

if __name__ == "__main__":
    server.run(host="0.0.0.0", port=8080)

That’s a complete A2A agent in under 40 lines. The SDK handles the JSON-RPC envelopes, SSE framing, and the task state machine. You plug in whatever reasoning you want — a Claude call, a LangGraph graph, a CrewAI crew — behind handle_task.

Calling an A2A agent from a client

From the other side, a client agent fetches the Agent Card, decides the remote agent is a good fit, and submits a task:

import asyncio
from a2a.client import A2AClient

async def main():
    client = A2AClient.from_url(
        "https://agents.example.com/summariser",
        auth={"bearer": "$SUMMARISER_TOKEN"},
    )

    # Fetch and inspect the Agent Card
    card = await client.get_agent_card()
    assert any(s.id == "summarise" for s in card.skills)

    # Send a task and stream the response
    async for event in client.send_task_streaming(
        skill_id="summarise",
        message="Summarise this quarterly report: ...",
    ):
        if event.type == "message":
            print(event.text, end="", flush=True)
        elif event.type == "task_status":
            print(f"\n[status] {event.state}")

asyncio.run(main())

Notice there is zero coupling to the remote agent’s framework. The caller does not know (or care) whether the summariser is Claude, GPT-5, a LangGraph state machine, or a hand-rolled finite-state agent. That is the point.

Production Concerns

For deeper treatments of each of these, see our posts on AI agent firewalls, AI agent observability, runaway token costs, and testing agents in production.

How Rapid Claw Hosts A2A-Compatible Agents

Rapid Claw is managed hosting for AI agents — OpenClaw, Hermes, Google ADK, and custom Python agents. Every agent you deploy on Rapid Claw is A2A-compatible the moment it boots. You do not write the JSON-RPC wiring, the SSE handler, or the Agent Card — we generate those from your agent definition.

What you get out of the box:

If you are already running agents on your own infrastructure and just want the A2A layer, that works too — Rapid Claw can front existing agents as a protocol gateway without requiring a full migration. For the background on managed hosting tradeoffs, see our AI agent hosting complete guide and the enterprise deployment guide.

Common Pitfalls (and How to Avoid Them)

Frequently Asked Questions