What Is the A2A Protocol?

The Core Idea Behind A2A

AI agents are increasingly specialized. One agent might excel at research, another at data analysis, another at writing code, and another at managing customer conversations. The problem is that these agents are typically built on different frameworks (LangGraph, CrewAI, AutoGen, Google ADK) and deployed on different servers by different teams. Without a shared communication protocol, these agents exist in isolated silos where they cannot leverage each other's capabilities.

A2A solves this by defining a standard wire protocol for agent-to-agent communication. Any agent that implements the A2A specification can communicate with any other A2A-compliant agent, regardless of what framework it uses, what language it is written in, what models power it, or where it is deployed. A Python research agent running on AWS can seamlessly collaborate with a Java data analysis agent running on Google Cloud, because both speak the same protocol.

Google announced A2A in April 2025 with immediate backing from over 50 technology companies including Salesforce, SAP, ServiceNow, MongoDB, Intuit, and Deloitte. The protocol is open source under the Apache 2.0 license, with official SDKs in Python, Go, JavaScript, and Java. As of mid-2026, the GitHub repository has accumulated over 24,000 stars, and framework adapters are available for every major agent platform.

The Five Design Principles

Google built A2A around five explicit design principles that shape every aspect of the protocol. Understanding these principles explains why certain design decisions were made and helps developers use the protocol effectively.

Agentic collaboration. A2A is specifically designed for interactions between autonomous agents, not between a user and an agent, or between an agent and a tool. Both participants can reason, ask questions, refuse requests, and make decisions. The protocol supports multi-turn conversations where the server agent requests clarification, proposes alternatives, or negotiates scope. This is fundamentally different from tool-calling protocols where one side is always passive.

Opacity preservation. Agents collaborate by exchanging messages and artifacts, never by sharing internal state. No A2A method exposes an agent's memory, prompt templates, tool configurations, or reasoning chain. This means organizations can offer agent services externally without revealing proprietary implementations, and agents from competing vendors can collaborate without security concerns about internal exposure.

Flexible modality support. Agents can exchange text, structured data (JSON), files (images, documents, spreadsheets), and forms. The multi-part message system lets agents send rich, mixed-content responses. A data analysis agent can respond with a text summary, a JSON data structure, and a chart image all in a single message. This flexibility prevents the protocol from becoming a bottleneck when agents need to exchange complex outputs.

Long-running task support. Some agent tasks complete in seconds, others take hours or days. A2A handles both through its task lifecycle model, which supports synchronous responses for quick tasks, SSE streaming for medium-duration tasks, and push notifications for long-running asynchronous work. An agent can transition tasks between these modes as needed, starting with streaming and switching to push notifications if the client disconnects.

Enterprise readiness. A2A includes authentication (OAuth 2.0, API keys), transport security (HTTPS), audit trails (task message history), and access control (per-skill authentication requirements) as core protocol features, not optional extensions. The specification was designed from the start for production enterprise environments, not just developer prototypes.

What A2A Looks Like in Practice

A typical A2A interaction follows a predictable pattern. First, the client agent fetches the server agent's Agent Card from its well-known URL (/.well-known/agent.json). The Agent Card describes the server's identity, available skills, supported content types, and authentication requirements.

The client agent examines the Agent Card to determine whether the server can handle the desired task. If the server lists a relevant skill, the client constructs a task containing a message that describes what it needs. This message might include text instructions, structured parameters, or file attachments depending on the skill's input requirements.

The client sends the task using one of the submission methods: tasks/send for synchronous operation, or tasks/sendSubscribe for streaming. The server receives the task, processes it using whatever internal logic it has, and either returns a completed result or begins streaming updates. If the server needs more information, it transitions the task to the input-required state and sends a message asking the client for clarification.

When the server finishes, it marks the task as completed and attaches artifacts containing the results. The client retrieves the artifacts and integrates them into its own workflow. The entire interaction is recorded in the task's message history, providing a complete audit trail.

The Technical Foundation

A2A runs on JSON-RPC 2.0 over HTTP(S), two technologies that have decades of proven reliability in production systems. JSON-RPC provides a simple, well-documented format for remote procedure calls: every request has a method name and structured parameters, every response has either a result or an error. HTTP provides the transport layer with all its existing infrastructure support for load balancing, caching, compression, TLS, monitoring, and authentication.

This choice of foundation technologies is pragmatic rather than novel. The A2A team deliberately avoided inventing new transport or serialization formats, choosing instead to build on standards that every programming language, every cloud platform, and every enterprise firewall already supports. A2A messages can be inspected with standard HTTP debugging tools, logged with existing monitoring infrastructure, and routed through existing API gateways without any modifications.

The protocol defines six core methods: tasks/send, tasks/sendSubscribe, tasks/get, tasks/cancel, tasks/pushNotification/set, and tasks/pushNotification/get. This small method set keeps the protocol surface area manageable while covering the full lifecycle of task-based agent collaboration.

Why A2A Matters Now

The timing of A2A's release coincided with a critical inflection point in AI agent development. Through 2024, most organizations experimented with single-agent systems where one AI handled a specific task. By early 2025, the industry was moving toward multi-agent architectures where specialized agents collaborate on complex problems. This transition revealed the interoperability gap that A2A fills.

Without A2A, organizations building multi-agent systems face a framework lock-in problem. If you start with CrewAI for your first few agents, all subsequent agents must also be CrewAI agents to participate in the same system. If a different framework is better suited for a new agent's task, you either compromise on the framework choice or build custom integration code. A2A eliminates this trade-off by making framework choice an implementation detail that does not affect interoperability.

The protocol also enables a new category of agent services. Organizations can build specialized agents and offer them as A2A services that other organizations consume. A company specializing in financial analysis can deploy agents that accept tasks through A2A, letting any client agent leverage their expertise without needing custom integrations. This creates an ecosystem dynamic similar to APIs, but for autonomous, reasoning agents rather than deterministic endpoints.