Google's A2A Protocol: How Agents Talk to Each Other (and Why It Matters)

A2A vs MCP: Two Protocols, One Stack

In early 2025, Google introduced the Agent2Agent (A2A) protocol. By June 2025, they donated it to the Linux Foundation. By early 2026, A2A had 1.0 status, gRPC bindings, signed Agent Cards, and 150+ organizations building on it. The question indie devs keep asking: why another protocol when MCP already exists?

The answer is that A2A and MCP solve completely different problems — and understanding the distinction is the foundation for building any serious multi-agent system.

Model Context Protocol, released by Anthropic in late 2024, standardizes how a single agent accesses tools and resources. An MCP server exposes capabilities (search, database queries, file reads, API calls) that an LLM-powered client can invoke. The model stays in the middle; the tools are subordinate.

MCP is fundamentally synchronous and stateless at the protocol level. A client calls a tool, gets a result, moves on. There's no concept of negotiating a long-running task, delegating autonomously, or one agent discovering another agent's capabilities.

A2A solves the horizontal layer: how do agents coordinate with other agents? Not how does an agent call a tool, but how does a customer support agent hand off a billing dispute to a specialized finance agent, asynchronously, across organizational boundaries, with authentication?

The core architectural distinction:

| Concern | MCP | A2A |

|---|---|---|

| What connects | Agent ↔ Tool/Resource | Agent ↔ Agent |

| State model | Stateless per call | Stateful task lifecycle |

| Discovery | Configuration / registry | Agent Cards at .well-known/ |

| Long-running tasks | Not a concern | First-class primitive |

| Cross-org boundaries | Not addressed | Core design goal |

| Streaming | Not native | SSE + gRPC bindings |

A2A is now a Linux Foundation project. This matters for indie developers in one specific way: neither protocol is going away, neither is vendor capture, and building on both is not a bet on any single company's priorities.

A2A 1.0 shipped with formal backward compatibility guarantees, gRPC support, and cryptographically signed Agent Cards. It's production-grade.

The cleanest mental model: MCP is vertical, A2A is horizontal.

• MCP connects an agent down to tools, APIs, and data sources
• A2A connects agents across to other agents

A repair shop analogy from the A2A spec community: a customer-facing intake agent coordinates with a diagnostics agent, an estimate agent, and a parts-procurement agent — all over A2A horizontally. Each specialist reaches its own internal systems (inventory databases, CRMs, pricing APIs) over MCP vertically. Neither protocol replaces the other; each handles the layer it was designed for.

For a solo indie developer building a single agent with tool use, MCP is probably all you need today. The moment you want that agent to delegate subtasks to another agent with different capabilities, context, or trust boundaries — that's when A2A enters the picture.

A2A Architecture: Agent Cards, Tasks, and Streaming

Understanding A2A at the spec level means understanding three concepts: how agents advertise themselves (Agent Cards), how work moves between them (Tasks), and how they communicate in real time (streaming transports).

Every A2A-compliant agent publishes a JSON document at:

https://{your-agent-domain}/.well-known/agent-card.json

This follows RFC 8615 conventions — the same pattern used for OAuth metadata. The card contains:

{
  "name": "BillingResolverAgent",
  "description": "Handles subscription billing disputes and refund decisions",
  "url": "https://billing-agent.example.com/a2a",
  "version": "1.2.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "authentication": {
    "schemes": ["bearer", "oauth2"]
  },
  "skills": [
    {
      "id": "resolve-dispute",
      "name": "Resolve Billing Dispute",
      "description": "Reviews and resolves billing disputes under $500",
      "inputModes": ["text", "structured-data"],
      "outputModes": ["text", "structured-data"]
    }
  ]
}

In A2A 1.0, Agent Cards gained cryptographic signatures — a calling agent can verify the card's authenticity before trusting a handoff, preventing impersonation attacks.

There's no central registry. Agents discover each other through DNS, configuration, or by being listed in an orchestrator's known-agents manifest.

This is the sharpest contrast with MCP's stateless calls. In A2A, work happens through explicit Tasks with defined state transitions:

submitted → working → [input-required | auth-required] → completed
                                                        → failed
                                                        → canceled
                                                        → rejected

A calling agent submits a task, then either polls for updates or subscribes to a stream. The receiving agent can transition to input-required to ask clarifying questions, auth-required if additional credentials are needed, or complete, fail, or reject the task.

This state machine matters because long-running tasks are a first-class concern, not an afterthought. A task that takes 45 seconds (an LLM doing research) or 45 minutes (a background processing job) uses the same protocol primitives as a task that takes 50ms.

A2A is transport-agnostic at the spec level but defines three bindings:

# Simplified SSE task subscription
with httpx.stream("POST", agent_url + "/tasks/stream", json=task_payload) as r:
    for line in r.iter_lines():
        if line.startswith("data:"):
            event = json.loads(line[5:])
            handle_task_event(event)  # state transitions, partial output

A2A supports four authentication schemes matching OpenAPI's security schemes:

• API keys (simplest, use for internal agents)
• HTTP Basic/Bearer auth
• OAuth 2.0 / OIDC (for cross-org, delegated access)
• Mutual TLS (for high-security enterprise deployments)

Internal agents in the same service mesh: API keys. Agents crossing organizational boundaries: OAuth 2.0 with PKCE. Anything involving financial or health data: mTLS or OAuth with narrow scopes.

Building Multi-Agent Systems with A2A + MCP

Knowing the specs is one thing. Knowing when to reach for A2A vs. MCP vs. neither — and how to wire them together — is what makes a multi-agent architecture practical.

The most common pattern for indie developers: one orchestrator agent receives user requests and routes subtasks to specialist agents. The orchestrator uses A2A to communicate with specialists; each specialist uses MCP to access its tools.

User request
    ↓
[Orchestrator Agent]
    ├─── A2A ──→ [Research Agent] ─── MCP ──→ [Web Search Tool]
    ├─── A2A ──→ [Code Agent]     ─── MCP ──→ [Code Execution Tool]
    └─── A2A ──→ [Summary Agent]  ─── MCP ──→ [Document Store]

The orchestrator's job is decomposition and coordination, not execution. Each specialist has a narrow skill surface, a published Agent Card, and handles its own tool access. The orchestrator doesn't need to know how the Code Agent runs code — only what task to give it and what state the task is in.

• You have distinct task types that require different tools or expertise
• Specialists might be maintained by different teams or deployed separately
• You want specialists to be independently testable and swappable

For workflows where output from one agent feeds the next:

[Ingest Agent] → A2A task → [Transform Agent] → A2A task → [Review Agent] → [Output]

Each agent publishes its Agent Card, maintains its own state, and returns structured results. Unlike an MCP tool chain (synchronous, same process), this pipeline is asynchronous and each step can run independently.

Some tasks parallelize well: analyze 10 documents simultaneously, check 5 regulatory databases at once, run A/B variants of a prompt. A2A's stateful task model makes fan-out tractable:

async def analyze_documents(docs: list[str], orchestrator_agent) -> list[dict]:
    tasks = []
    for doc in docs:
        task = await orchestrator_agent.submit_task(
            skill="analyze-document",
            input={"content": doc}
        )
        tasks.append(task)
    
    # Poll/stream all tasks concurrently
    results = await asyncio.gather(*[wait_for_task(t) for t in tasks])
    return results

A2A 1.0 is production-stable with backward compatibility guarantees. Use it for:

• Any multi-agent system where agents might cross service or team boundaries
• Any workflow where task duration exceeds 2–3 seconds (use SSE streaming)
• Any system that needs to federate agents from different providers

• Single-agent systems with tool use — A2A adds overhead you don't need
• Tightly coupled agents in the same process that share state directly
• Prototypes where iteration speed matters more than protocol correctness

If you want to experiment with A2A today, Google's Agent Development Kit (ADK) has native A2A integration. Alternatively, the a2aproject/A2A repository on GitHub has Python and TypeScript SDKs. Start with the orchestrator-specialist pattern, implement Agent Cards for your specialists, and use SSE streaming for any task that takes more than a second. That covers 90% of real-world multi-agent use cases.