GenAI Systems Lab Open interactive version →
Agents & Tool Use 10 min read

A2A Protocol: How Agents Talk to Each Other at Scale

Google's Agent-to-Agent protocol explained end to end. The N×M problem, Agent Cards, Task lifecycle, push notifications, how A2A + MCP compose into a full agent integration architecture, and current framework support.

In early 2025, Google released the Agent-to-Agent (A2A) Protocol — a specification for how AI agents communicate with each other. The timing was deliberate: as multi-agent systems moved from demos to production, the field hit the N×M problem hard. Here is what A2A is, why it matters, and how to think about it alongside MCP.

The N×M Problem

Without a standard protocol, every agent-to-agent integration requires a custom API contract. N callers × M agents = N×M bespoke integrations to build and maintain. Every new agent you add requires N new integrations from existing callers. A2A solves this the same way MCP solved it for tools: standardize the protocol so any caller can talk to any server with no custom code.

With A2A: each agent publishes one Agent Card; any A2A client reads it and knows exactly how to invoke that agent. N+M integrations instead of N×M. Adding a new agent = 1 new Agent Card.

Agent Cards

An Agent Card is a JSON manifest that describes an agent's capabilities, input/output schemas, authentication requirements, and transport endpoints. Think of it as an OpenAPI spec for an agent. A2A clients discover capabilities from Agent Cards without custom documentation or pre-arranged contracts.

The Task Lifecycle

A2A models work as Tasks — first-class objects with explicit state. This is the key architectural decision. Where function calling is fire-and-forget, A2A Tasks persist and can be polled or subscribed to.

input-required is A2A's human-in-the-loop primitive. An agent can pause mid-task and request clarification from a human or upstream orchestrator without losing task context. The task ID persists; the caller resumes it with additional input.

Push Notifications

For long-running tasks (minutes to hours), polling is wasteful. A2A supports server-initiated push notifications via webhooks. The caller provides a notification endpoint when creating the Task; the agent POSTs status updates to that endpoint as the task progresses. This enables fully async workflows where the orchestrator does not have to maintain an open connection.

A2A + MCP: The Full Architecture

MCP and A2A are complementary, not competing. MCP is vertical — model to tools and data sources. A2A is horizontal — agent to agent. A production multi-agent system typically uses both: each agent uses MCP to access its own tools (filesystem, databases, APIs), and agents communicate with each other via A2A.

Mental model: MCP = what an agent can do. A2A = how agents delegate to each other. An orchestrator agent uses A2A to hand off subtasks to specialist agents; each specialist uses MCP to do its work.

Framework Support (as of 2026)

What A2A Doesn't Solve

A2A standardizes the communication layer, not trust, authorization, or billing. If Agent B performs a paid action on behalf of Agent A, the billing model is undefined by the protocol. Access control (can Agent A invoke Agent B at all?) requires application-level auth built on top of the securitySchemes field. A2A is a transport contract, not a governance framework.

Try it interactively

GenAI Systems Lab is a free platform for AI engineers — configure real failure modes, break things, and build the judgment that gets you hired.

Open GenAI Systems Lab →