How Google’s A2A Protocol Enables Seamless AI Agent Collaboration

Overview

On April 9, 2025, Google announced the open‑source Agent‑to‑Agent (A2A) protocol at Google Cloud Next 2025. A2A is an open standard designed to enable seamless, secure communication and cross‑platform collaboration among heterogeneous AI agents, facilitating complex enterprise workflow automation.

Core Design Principles

Agent Capability: Enables agents to cooperate in natural, unstructured ways without sharing memory, tools, or context, supporting true multi‑agent scenarios.

Protocol Standards: Built on mature web standards such as HTTP, Server‑Sent Events (SSE), and JSON‑RPC, allowing easy integration with existing IT stacks.

Enterprise‑grade Security: Incorporates identity verification and authorization consistent with OpenAPI, ensuring data privacy and access control.

Long‑running Task Support: Handles tasks ranging from instant to multi‑day operations, providing real‑time feedback, push notifications, and status updates.

Modality‑agnostic: Supports not only text but also audio and video streams for multimodal interaction.

Key Concepts

The protocol revolves around several core concepts:

Agent Card

An Agent Card is a public metadata file (typically located at /.well-known/agent.json) that describes an agent’s name, capabilities, API endpoint, authentication methods, and more. It acts like a business card for agents.

{
  "name": "Google Maps Agent",
  "description": "Plan routes, remember places, and generate directions",
  "url": "https://maps-agent.google.com",
  "provider": {"organization": "Google", "url": "https://google.com"},
  "version": "1.0.0",
  "authentication": {"schemes": "OAuth2"},
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/html"],
  "capabilities": {"streaming": true, "pushNotifications": false},
  "skills": [
    {
      "id": "route-planner",
      "name": "Route planning",
      "description": "Helps plan routing between two locations",
      "tags": ["maps", "routing", "navigation"],
      "examples": [
        "plan my route from Sunnyvale to Mountain View",
        "what's the commute time from Sunnyvale to San Francisco at 9AM",
        "create turn by turn directions from Sunnyvale to Mountain View"
      ],
      "outputModes": ["application/html", "video/mp4"]
    },
    {
      "id": "custom-map",
      "name": "My Map",
      "description": "Manage a custom map with your own saved places",
      "tags": ["custom-map", "saved-places"],
      "examples": [
        "show me my favorite restaurants on the map",
        "create a visual of all places I've visited in the past year"
      ],
      "outputModes": ["application/html"]
    }
  ]
}

A2A Server

Any implementation exposing an HTTP endpoint that follows the A2A specification can act as an A2A Server, receiving requests and managing task execution.

A2A Client

A client application or another agent that consumes A2A services by sending requests to the server’s URL.

Task

A Task is the fundamental unit of collaboration. Clients start a task via tasks/send (synchronous/short‑lived) or tasks/sendSubscribe (long‑lived/streaming). Each task receives a unique ID and progresses through defined lifecycle states: submitted, working, input‑required, completed, failed, or canceled.

Message & Part

Communication occurs via Messages exchanged between client (role: "user") and server (role: "agent"). Each Message consists of one or more Parts, which can be:

TextPart – plain text.

FilePart – binary file data or a URI reference.

DataPart – structured JSON data, often used for form submissions or structured results.

Artifact

An Artifact represents any output generated during task execution, such as files or structured data, and may also contain Parts.

Streaming

For long‑running tasks (e.g., report generation, video processing), servers supporting streaming can use the tasks/sendSubscribe endpoint. Clients receive Server‑Sent Events (SSE) with TaskStatusUpdateEvent or TaskArtifactUpdateEvent in real time.

Push Notifications

When persistent connections are not feasible, servers with push‑notification support allow clients to register a webhook via tasks/pushNotification/set, enabling the server to actively push status updates.

Interaction Flow

The typical A2A interaction proceeds through five stages:

Discovery: The client fetches the Agent Card from /.well-known/agent.json on the server.

Initiation: Using the Card information, the client sends a tasks/send or tasks/sendSubscribe request containing an initial user message and a unique Task ID.

Processing: The server processes the request. For streaming tasks, it streams status and artifact updates via SSE; for non‑streaming tasks, it returns a final Task object.

Interaction: If the task enters the input‑required state, the client can send additional messages using the same Task ID.

Completion: The task reaches a terminal state— completed, failed, or canceled.

Relation to MCP (Model Context Protocol)

The Model Context Protocol (MCP) acts like a USB‑C port for AI models, standardizing connections to data sources and tools. A2A and MCP are complementary: MCP enables a single agent to use diverse tools, while A2A allows multiple agents to collaborate on complex tasks.

Conclusion

Previously, AI agents operated in isolated silos, limiting enterprise digital transformation. The A2A protocol bridges these islands by standardizing the JSON‑based Agent Card, enabling capability discovery, task negotiation, and real‑time synchronization, allowing agents to collaborate as efficiently as humans and opening new possibilities for AI‑driven workflows.