Google's A2A Protocol: Standards for AI Agent Communication

Google has released the Agent2Agent protocol. It's a technical spec designed to set a standard for how AI agents talk to each other. In a recent talk, Google Cloud AI developer advocate Holt Skinner walked through the protocol's design and how it fits into the broader AI landscape.

The timing stands out. AI agents -- autonomous software that can run tasks, make decisions, and use tools -- have spread across the industry in the past year. But each one uses its own communication style. That makes it nearly impossible for agents from different companies to work together. Google's proposal tries to fix this by setting a common language.

The Technical Architecture

A2A works through several core parts. First, each agent publishes an "agent card." This is a JSON file served at a standard URL that works like a digital business card. It lists the agent's abilities, available skills, HTTP endpoint, and login requirements. Skinner compares it to robots.txt for web crawlers or service registries in microservice setups.

"Think of this as its digital business card," Skinner explains. "It's a standard JSON file which is served at a well-known URI on the agent's domain. This card tells agent A everything it needs to know to start a conversation."

The actual messaging uses HTTPS with JSON-RPC 2.0 as the envelope. Messages contain "parts" that can hold text, files, mixed media, or structured JSON data. For quick requests, agents reply right away. For longer jobs, the protocol creates a task object with a lifecycle: submitted, working, input required, completed, or failed.

This task-based approach solves a key problem in agent coordination. When Agent A hands work to Agent B, it can't just sit and wait for a reply that might take minutes or hours. Instead, Agent B sends back a task ID right away. Agent A can then poll for updates -- or better yet, use server-sent events to get streaming updates as the task moves forward.

The streaming feature matters for user experience. Users can see progress and results as they come in, rather than waiting for a full response. This works like how modern chat apps show replies token by token.

The Adoption Question

Google's talk lists several industry partners who have "agreed to support A2A." But the specific commitments and timelines are unclear. This is standard for new protocol launches. Vendors signal support early. Actual builds come later. Market forces decide if the standard reaches critical mass.

The protocol lives or dies on how widely it's adopted. A communication standard used only by Google's agents and a few partners doesn't fix the problem. It just creates another walled garden. The docs are open. The Python SDK is on pip. Google accepts pull requests. These are real signs of openness. But openness and adoption are different things.

Think about the possible outcomes. If major agent framework builders like LangChain, Microsoft (with AutoGen), and Anthropic add A2A support, it could become the default fast. If they don't -- or if they push rival standards -- we're back to fragmentation. The protocol's technical quality matters less than the coordination problem it tries to solve.

Relationship to Other Standards

Skinner addresses how A2A relates to MCP (Model Context Protocol), another recent standard that's gained traction. His take: they work together, not against each other.

"MCP is all about how an agent connects to its tools, APIs, and resources," he notes. "A2A on the other hand facilitates dynamic communication between different independent agents acting as peers."

This split is technically right, but it raises questions about complexity. Developers building agent systems now need to wire up multiple protocols. A2A handles agent-to-agent talk. MCP handles tool use. Then there's whatever auth, monitoring, and coordination layers the specific use case demands. Each protocol adds integration work, more testing, and more ways things can break.

Google suggests a specific stack that uses both A2A and MCP. But developers can mix and match. This flexibility is needed, but it means the protocol alone isn't enough for production use. It's one piece among many.

Implementation Details Matter

The protocol keeps agents "opaque" -- their inner workings aren't shared. This is clean design, but it affects debugging, monitoring, and trust. When Agent A calls Agent B and gets an error or a strange reply, fixing the problem means looking across organizational lines. The protocol doesn't spell out how to handle that.

Security auth is mentioned but not fully detailed in the talk. The agent card lists "how to authenticate," but the exact methods -- OAuth, API keys, mutual TLS, or something else -- aren't specified. For enterprise use, these details decide whether the protocol works in practice.

The protocol handles mixed media content. But the talk doesn't say how agents sort out what each one can handle. If Agent A can process video but Agent B only handles text, who manages that mismatch? Does Agent A check Agent B's card before sending? Or does Agent B reject the request with an error? These edge cases shape real-world use.

What This Actually Enables

Skinner's sample use case -- booking flights, hotels, and activities for a trip -- shows the potential. Instead of building all three agents from scratch or wiring each vendor's custom API, developers could build systems from A2A-ready agents no matter who made them.

But this assumes a lot. Agents from different vendors need to truly understand each other's task formats. The security risks of cross-company agent messaging must be manageable. The protocol overhead must stay small enough. None of that is certain.

The protocol is "rapidly evolving," per Skinner. That's both good (active work, quick response to feedback) and risky (building on a moving target, version headaches, backward compatibility questions).

Google has published the spec, released an SDK, and posted sample code. The next phase -- industry testing and real builds -- will show whether A2A becomes vital infrastructure or just another protocol in a crowded field.

Samira Okonkwo-Barnes covers technology policy and regulation for Buzzrag.