A2A Protocol in Practice: A Complete Breakdown of Agent-to-Agent Communication

Why We Need the A2A Protocol

With the explosive growth of AI Agent applications, a single Agent often struggles to complete complex tasks independently. An AI Agent refers to an AI system capable of autonomously perceiving its environment, making decisions, and executing actions. Unlike traditional chatbots, Agents possess goal-oriented behavior, tool invocation, and multi-step reasoning capabilities. Since 2023, with the leaps in capabilities of large language models like GPT-4 and Claude, Agent frameworks such as AutoGPT, CrewAI, and LangGraph have emerged one after another, moving Agents from proof-of-concept to production environments. However, when multiple Agents need to collaborate, communication between them becomes an unavoidable challenge. Without a unified standard, integrating Agents becomes extremely cumbersome—every time a new Agent is added, a new communication logic must be designed from scratch.

The Agent2Agent (A2A) protocol was created precisely to solve this pain point. A2A is not an entirely new low-level protocol, but rather a communication specification built on top of mature Web standards, with the goal of achieving "build once, connect everywhere." This article will use a concrete Demo to deeply dissect the underlying mechanisms of the A2A protocol.

Demo Overview: Collaboration Between a Travel Agent and a Weather Agent

To intuitively understand how the A2A protocol works, let's look at a dual-Agent collaboration scenario implemented locally:

• Agent-Client (Travel Agent): Acts as the client, capable of extracting travel destinations from user input and generating clothing/packing suggestions based on weather information.
• Agent-Server (Weather Agent): Acts as the server, identifying city names within strings via a large language model and querying corresponding weather data.

The actual interaction flow is as follows: when a user types "I want to travel to Tokyo next week, what kind of clothes should I bring?" in the UI terminal, the question is first sent to the Travel Agent. The Travel Agent extracts the destination "Tokyo" through the LLM, then initiates a weather query request to the Weather Agent. After the Weather Agent completes its query and returns the results, the Travel Agent generates final clothing recommendations based on the weather data.

This seemingly simple interaction is supported behind the scenes by the A2A protocol enabling standardized communication between two independent Agents.

A2A's Layered Architecture

The A2A protocol's architectural design consists of two core layers: the Application Layer and the Transport Layer.

Application Layer: Defining "What to Say"

The application layer contains four key elements: Agent Card, Task, Message, and Artifact. This layer defines the semantic content of communication between Agents, determining what information the communicating parties need to exchange. This separation of application and transport layers follows the classic separation of concerns principle—changes in business semantics won't affect the underlying transport, and vice versa.

Transport Layer: Defining "How to Transmit"

The transport layer handles actual data transmission, supporting multiple methods: JSON-RPC, SSE (Server-Sent Events), REST, and gRPC. This Demo uses the JSON-RPC + SSE combination, which is also the simplest approach recommended officially.

• JSON-RPC: A stateless, lightweight remote procedure call protocol first proposed in 2005. Its core concept is extremely concise: a request is a JSON object containing method (method name), params (parameters), and id (request identifier), while a response contains either result or error along with the corresponding id. Compared to REST APIs, JSON-RPC only requires a single HTTP endpoint, with all calls sent via the POST method, differentiated by the method field. This design simplifies routing logic and is well-suited for Agent-to-Agent scenarios where method call semantics are clear.
• SSE: Server-Sent Events is part of the HTML5 specification, allowing servers to continuously push data to clients through a unidirectional HTTP long-lived connection. Unlike WebSocket's bidirectional communication, SSE is a purely server-to-client unidirectional stream, based on standard HTTP protocol, with native support for automatic reconnection and event ID tracking. In A2A scenarios, Agent task processing may take seconds or even minutes, and SSE allows clients to receive real-time status updates without polling. Compared to WebSocket, SSE doesn't require a protocol upgrade handshake, is more friendly to firewalls and proxy servers, and has lower deployment and operations costs.

Additionally, data structures like Agent Card, Task, and Message are all defined through Protobuf and ultimately serialized as JSON for transmission. Protocol Buffers (Protobuf) is a language-neutral, platform-neutral structured data serialization mechanism developed by Google. In the A2A protocol, Protobuf serves as a "data structure definition language"—it precisely defines field types and constraint relationships for each data structure through .proto files, ensuring that Agent implementations in different languages have a unified understanding of data formats. Although the final transmission is serialized as JSON for readability and Web compatibility, the Protobuf definitions provide strong typing constraints and version evolution capabilities, avoiding the ambiguity issues common with pure JSON Schema.

Five Core Concepts Explained in Detail

Agent Card: An Agent's Business Card

The Agent Card is the client's first entry point for discovering a server. It answers three key questions: Who am I, what can I do, and how to call me.

• "Who am I": Described by fields such as name, description, version;
• "What can I do": Described by the skills list, containing specific information about each capability;
• "How to call me": Described by supported interfaces, including supported protocols and protocol URLs.

Retrieving an Agent Card is straightforward: the client simply sends a GET request to the A2A-specified path /.well-known/agent-card.json to obtain the server's complete Agent Card information. The /.well-known/ path prefix used here is a standard mechanism defined by IETF in RFC 5785, designed to expose metadata on web sites without conflicting with business routes. Notable examples include Let's Encrypt's /.well-known/acme-challenge/ (domain validation) and OAuth's /.well-known/openid-configuration (service discovery). The A2A protocol fully adheres to this internet best practice, enabling any client to automatically discover an Agent's capabilities simply by knowing the server's domain name, without requiring an additional registry or directory service.

Task: A Stateful Unit of Work

Task is one of the most distinctive concepts in the A2A protocol. It's not a one-shot request, but rather a stateful, trackable, interruptible and resumable unit of work that maintains a complete internal state machine:

• After creation, the Task's state is submitted;
• When the Agent begins processing, the state changes to working;
• Processing results have three possibilities: successful completion (completed), processing failure (failed), or additional user input needed (input-required).

The engineering significance of this stateful Task design lies in its borrowing from workflow engine concepts (like Temporal, Airflow), but with dramatic simplification. The submitted→working→completed/failed/input-required state transition model covers the most common scenarios in Agent interactions: long-running inference tasks need progress feedback (working), multi-turn conversations need additional input (input-required), and context recovery after network failures (by re-querying state via task id). This design gives A2A native support for asynchronous work modes—an Agent can accept a task and process it in the background for hours while the client queries progress at any time via the task id.

With each state change, the server pushes a status update event to the client via SSE, keeping the client informed of task progress in real time. Tasks also support cancellation (cancel), authentication (auth-required), push notifications (webhook callbacks), and more.

Message: The Vehicle of Conversation

A Message is the basic unit of communication between Agents, containing the following core fields:

• message id: The unique identifier of a Message;
• role: Identifies whether the sender is a user or an agent;
• task id: Identifies which Task the Message belongs to;
• context id: Identifies which conversation session the Message belongs to;
• parts: Carries the actual communication content.

The context id design is particularly noteworthy. A context can span multiple Tasks, meaning multiple related but independent tasks can share the same conversation context. For example, in a travel planning scenario, querying weather, booking hotels, and planning routes might be three independent Tasks, but they share the same context id, allowing each Agent to access the complete conversation history.

Part: The Smallest Building Block of Content

A Part is the smallest building block of content—a Message or Artifact can contain multiple Parts. There are four types of Parts:

• text: Plain text string, for carrying conversational text;
• data: Structured JSON data, such as weather data, tables, API responses;
• url: URL string referencing external files, such as images or document links;
• raw: Binary byte stream, for directly transmitting files.

It's precisely this flexible Part design that enables the A2A protocol to transmit arbitrarily complex content. A single Message can simultaneously contain a text explanation (text Part), a link to an analytical chart (url Part), and structured data (data Part). This multimodal content composition capability is the foundation for complex inter-Agent collaboration. In the Demo, the client sends a single text-type Part, and the server returns an Artifact containing weather data.

Artifact: The Deliverable of a Task

An Artifact is the output produced after a Task is completed. A single Task can produce multiple Artifacts—for example, first returning a summary, then a detailed report. Artifacts also support chunked streaming delivery, making them ideal for progressive delivery of large files or long texts. The key difference between Artifacts and Messages is: Messages are interactive content during the conversation process, while Artifacts are the formal deliverables produced after task completion. This distinction allows clients to clearly separate "intermediate discussions" from "final results."

Complete Communication Flow Breakdown

Now that we understand the core concepts, let's examine the complete A2A protocol communication flow. The entire process can be divided into three phases.

Phase 1: Discovery

The client sends a GET request to the server's /.well-known/agent-card.json path to request the Agent Card. The server returns a 200 OK with the complete Card information. At this point, the client knows that the other party is called "Weather Agent," can execute "weather query" tasks, and can communicate via JSON-RPC at the specified endpoint.

This phase is completely standardized and forms the foundation for A2A's "build once, connect everywhere" goal. It's worth noting that this decentralized service discovery pattern forms an interesting contrast with service registries in microservice architectures (like Consul, Eureka)—A2A chose a lighter approach that doesn't depend on any centralized component. Each Agent is self-describing and self-publishing, reducing system deployment complexity.

Phase 2: Task Execution (Core Interaction)

This is the core stage of the entire communication. The client constructs a send message request and sends it to the server endpoint via JSON-RPC. Specifically, this JSON-RPC request has its method field set to tasks/send, with params containing the complete Message object (including task id, context id, and parts). The server doesn't return results all at once, but progressively pushes events via SSE:

1. First event: Informs the client that the Task has been created;
2. Second and third events: Indicate the Task is being processed (state is working);
3. Final event: Indicates Task processing is complete (state is completed), with the result Artifact attached.

Each event the client receives is an independent SSE message, allowing it to display progress in real time (e.g., "Querying weather..."), obtain partial results early, make decisions at intermediate states, or even execute retry logic when the state is failed. The advantages of this streaming interaction model are especially apparent in production: when an Agent needs to call multiple external APIs or perform complex reasoning, users won't face a long unresponsive waiting screen but can instead see the task's gradual progress.

Phase 3: Stream End

After the server pushes the final event, the SSE connection closes. The client aggregates all events and extracts the final result. At this point, a complete Agent-to-Agent A2A communication cycle is finished. If the client unexpectedly disconnects during stream transmission, it can re-query the task state via the task id—the Task's persistence characteristic ensures that completed work is never lost.

Summary

The A2A protocol cleverly reuses mature Web standards (JSON-RPC, SSE, HTTP), achieves decentralized service discovery through Agent Cards, and supports complex asynchronous interactions through stateful Tasks and streaming SSE pushes. For developers building multi-Agent systems, understanding the A2A protocol's working mechanisms helps avoid reinventing the wheel, enabling Agents from different sources and vendors to achieve true interoperability.

It's worth mentioning that the A2A protocol and another popular protocol, MCP (Model Context Protocol), are complementary rather than competitive: MCP solves the communication problem between Agents and Tools, while A2A solves the communication problem between Agents. In a complete multi-Agent system, each Agent may internally call various tools via MCP, while Agents collaborate with each other through the A2A protocol.

If you're interested in seeing the A2A protocol in action, try setting up a similar dual-Agent Demo locally—it's the most direct and effective way to understand the A2A protocol.