How Agents Talk to Agents Using the A2A Protocol

Modern AI development has largely been defined by individual capability. We build agents to analyze documents, write code, or summarize meetings, but these agents are usually islands. An agent built on a specific framework like LangGraph or AutoGen often cannot easily communicate with an agent built on a different stack. They exist in what developers call "walled gardens." The Agent-to-Agent (A2A) protocol changes this by providing a standardized networking layer that allows autonomous agents to discover, communicate, and delegate tasks to one another, regardless of their underlying infrastructure.

Launched by Google Cloud in April 2025 and moved to the Linux Foundation in June 2025, the A2A protocol serves as a universal translator for AI. It reached its v1.0 milestone in 2026, gaining support from over 150 organizations, including major enterprise software providers like Salesforce, SAP, and ServiceNow. By focusing on open standards rather than proprietary APIs, A2A allows a finance agent from one cloud provider to securely delegate a tax-reporting task to a compliance agent from a completely different vendor without writing custom glue code for every connection.

The Architecture of Communication

A2A avoids reinventing the wheel. It is built on proven, stable web technologies, making it familiar to engineers who already build web-based services. At its core, it uses a Client-Server architecture. The communication happens over HTTP, the same foundation as the modern web. For structured messaging, it relies on JSON-RPC, a simple remote procedure call protocol that uses JSON for data exchange. This allows for clear, predictable requests and responses between autonomous entities.

The mechanism is designed to handle the realities of distributed systems, where network blips and latency are common. It uses Server-Sent Events (SSE) to manage real-time, asynchronous task updates. If a network connection drops mid-task, an agent can re-subscribe to a specific task ID to recover the current state of that task. This ensures that long-running operations do not fail silently or restart from scratch simply because a connection was interrupted.

The Agent Discovery Lifecycle

Before any work begins, agents must find each other. This is handled by the "Agent Card." Every A2A-compliant agent exposes a JSON metadata document, typically at /.well-known/agent-card.json. This acts as a digital business card that broadcasts what the agent can do, what formats it requires for input, and how it handles security.

This diagram shows the initial handshake process between a client agent and a remote service provider.

The discovery mechanism is crucial for scaling. It prevents the need for hard-coding agent addresses. Instead, a system orchestrator can scan a registry of agent cards to find an agent capable of specific tasks—like "Data Parsing" or "Customer Support"—and initiate a secure handshake to begin the interaction.

Task Delegation and State Management

Once two agents have established a connection, they move into the execution phase. The A2A protocol maintains a strict separation of concerns. The client agent asks the remote agent to perform a specific action, but the client does not need to know how the remote agent does it. The internal tools, private memory, and reasoning logic of the remote agent remain completely opaque, which is a significant departure from older systems that required shared state or deep integration.

State management is handled through a persistent task identifier. Because agents often work on long-running processes—such as auditing thousands of lines of logs—the connection may need to survive intermittent network issues.

The following diagram illustrates how the state remains consistent across a connection drop.

By subscribing to a task ID, the client can monitor progress through the SSE stream. If the network blips, the client does not lose the context of the work. It simply reconnects and asks the remote agent for the current status of that specific ID.

Standardizing the Agentic Ecosystem

The growth of the A2A protocol is driven by the fact that it complements, rather than replaces, existing standards. One of the most common sources of confusion in the current developer community is the difference between A2A and the Model Context Protocol (MCP).

Think of the distinction in terms of scope:

• Model Context Protocol (MCP): Designed for agent-to-tool communication. It standardizes how an agent connects to a local database, a file system, or a remote API to retrieve context or data.
• Agent-to-Agent (A2A) Protocol: Designed for agent-to-agent communication. It focuses on the hand-off of workflows, task delegation, and cross-organization coordination.

This complementarity is why major players like Microsoft, MongoDB, Box, and Cohere have moved to support it. They recognize that an agent’s utility is limited by its ability to talk to other agents. If a company uses a specific LLM-based agent for internal policy generation, that agent needs to trigger a secondary, specialized agent to handle the secure signing of those documents. A2A provides the common language to make that hand-off seamless.

Addressing Security and Opacity

Enterprise adoption relies on maintaining data privacy. A major misconception regarding A2A is that it requires agents to "expose their guts" to one another. In reality, the protocol is built on the principle of minimal disclosure.

When a client sends a request to a remote agent, it sends only the data necessary for the task, framed within the interface defined by the Agent Card. The remote agent receives this, processes it using its own internal private tools and vector databases, and returns the result. It never reveals its internal system prompts, its proprietary RAG (Retrieval-Augmented Generation) pipeline, or its broader operational memory.

This creates a "black box" environment where security teams can audit the interface without having to worry about the internal complexity of every individual agent. It also means that vendors can update their agent's underlying logic or model architecture without breaking the connection, as long as the external JSON-RPC interface defined in the Agent Card remains consistent.

The Future of Interoperable Agents

The shift toward a standardized protocol marks a move away from the "all-in-one" platform trap. Before A2A, if an enterprise wanted to build a complex workflow, they were often forced to stick to a single provider’s ecosystem to ensure compatibility.

By standardizing the "network layer" of agentic AI, companies can now build modular, heterogeneous systems. A financial firm might use an agent built on a custom stack for high-frequency data analysis, a second agent on Salesforce for CRM interactions, and a third on a different platform for regulatory filing. A2A enables these to act as a single, distributed super-agent without the need for fragile, bespoke API connectors that break every time a vendor updates their software.

What to watch next

The next phase of A2A development focuses on the maturity of the agent registry landscape. As v1.0 becomes standard, look for the rise of "Agent Marketplaces" where developers can publish their Agent Cards to be discovered by global enterprise orchestrators. Also, watch for the integration of A2A directly into popular agent frameworks like LangChain, which will allow developers to trigger cross-agent workflows with just a few lines of configuration rather than building the networking layer from scratch. Tracking these developments via the Linux Foundation’s project page will provide the clearest view of the protocol’s ongoing evolution.