What Is A2A Protocol? Agent-to-Agent Communication Explained

The A2A Protocol gives AI agents from different vendors and frameworks a shared language to coordinate work. Without it, every pair of agents requires custom integration code. With it, any A2A-compatible agent can discover, delegate to, and receive results from any other, regardless of who built it or what model it runs on.

Knowing how A2A works requires looking at not just the protocol itself, but where it sits in the broader agentic AI stack and what problems it was designed to solve.

What Is the A2A Protocol?

The A2A Protocol is an open specification for agent-to-agent communication. It defines a standard way for AI agents to advertise their capabilities, receive structured tasks, and return outputs, all without requiring custom integration code between each agent pair.

Before A2A, enterprise teams building multi-agent systems faced a fragmentation problem: agents from different vendors had no shared standard for handing off work.

• A Salesforce agent could not delegate a sub-task to a ServiceNow agent without custom glue code.
• A Google Vertex agent could not coordinate with an AWS Bedrock agent without a hand-rolled bridge.
• Every new agent pair required a new bespoke connector.

Google announced A2A on April 9, 2025, at Google Cloud Next. The specification was released as open source under the Apache 2.0 license and donated to the Linux Foundation in June 2025 for vendor-neutral governance.

The protocol is built on web-native standards, including HTTP, JSON-RPC 2.0, and Server-Sent Events (SSE), which means it does not introduce a new protocol layer on top of existing infrastructure.

How A2A Protocol Works: Step by Step

Step 1: Agent Discovery

Before two agents can work together, one needs to know the other exists and what it can do.

Each A2A-compatible agent publishes an Agent Card, a JSON metadata document hosted at a standardized path (/.well-known/agent-card.json). The Agent Card describes the agent's identity, capabilities, supported input/output modalities, service endpoint URL, and authentication requirements.

This is conceptually similar to a service descriptor in microservice architectures. A client agent reads the Agent Card to determine whether a remote agent is suitable for a given task, without needing to probe it directly.

Agent Cards must be protected using standard authentication mechanisms (such as mTLS or registry authentication) to prevent unauthorized access or capability spoofing.

Step 2: Task Delegation

Once a suitable remote agent is identified, the client agent sends a structured task request.

A Task is the fundamental unit of work in A2A. Each task has a unique ID, a defined lifecycle, and a structured payload that can include text, file references, or structured data.

Task delegation happens through JSON-RPC calls over HTTP/S. The request includes:

• An action identifier
• Input schema and parameters
• Any authentication context required for sensitive operations

The remote agent receives this and either returns a response immediately (for simple requests) or instantiates the task into its lifecycle management system.

Step 3: Task Execution and Status Updates

Once a task is accepted, it moves through a defined set of states:

submitted → working → input-required → completed / failed / canceled / rejected

For short tasks, the client polls for status. For long-running tasks, A2A uses Server-Sent Events (SSE) to push incremental updates in real time, avoiding the network strain of constant polling.

If the remote agent needs additional input mid-task (for example, a clarification or a credential), the task enters input-required state and pauses until the client responds. This supports genuine multi-turn interactions within a single task context.

Agents can also exchange Messages throughout execution. These are contextual communications attributed to either "user" or "agent" role, used to maintain alignment during complex tasks.

Step 4: Output Delivery

When a task completes, the remote agent returns an Artifact.

An Artifact is a structured output composed of one or more Parts, which can be text, file references, or structured data. The client agent receives the Artifact, which it can then use as input for the next step in a larger workflow, surface to a user, or pass to another agent.

At no point does the client agent need access to the remote agent's internal reasoning, tool access, or memory. The interface is defined entirely by what the Agent Card declares and what the Task lifecycle delivers.

A2A Protocol vs MCP: When to Use Each

A2A and MCP are not competing standards. They solve different problems and are designed to work together.

MCP defines how an individual agent connects to external resources: a database, an API, a file system. It is the vertical layer that gives an agent its tools and context.

A2A defines how agents coordinate with each other across vendor and framework boundaries. It is the horizontal layer that lets specialized agents delegate, collaborate, and return results without knowing each other's internals.

• Use MCP when a single agent needs to access tools or data sources to complete a user task.
• Use A2A when the task requires multiple specialized agents to coordinate, particularly across organizational or vendor boundaries.

In practice, most production multi-agent systems use both. A2A routes a task to the right specialist agent; MCP gives that agent the tools it needs to execute.

A concrete example: an HR agent receives a request to schedule an interview. It delegates the scheduling sub-task via A2A to a Calendar Agent. The Calendar Agent, in turn, uses MCP locally to call its calendar tool and query available slots.

A2A Protocol Adoption: Partners and Ecosystem

A2A launched in April 2025 with 50+ partners and reached 150+ supporting organizations by April 2026, including AWS, Cisco, IBM, Microsoft, Salesforce, SAP, and ServiceNow. It is now governed by the Linux Foundation as a vendor-neutral open standard.

SDK availability

The SDK ecosystem has expanded from a single Python implementation to five production-ready languages: Python, JavaScript, Java, Go, and .NET.

Industry verticals in active deployment

Supply chain, financial services, insurance, and IT operations are among the sectors currently running A2A in production.

Current Limitations and Constraints of A2A

1. Expanded security surface

Because agents receive instructions from other agents, a single compromised agent can propagate malicious instructions across the entire network. Identified risks include:

• Agent Card context poisoning: malicious content embedded in an Agent Card that corrupts downstream agents
• Prompt injection delivered through inter-agent messages

2. Authentication gaps in the base specification

A 2025 research paper identified weaknesses in the original A2A spec: insufficient token lifetime control, overbroad access scopes, missing consent flows, and lack of strong customer authentication. These gaps are most pronounced in workflows handling sensitive data such as payment credentials or identity documents.

Proposed mitigations include ephemeral scoped tokens and direct user-to-service data channels.

3. No support for emergent or spontaneous coordination

A2A assumes pre-defined roles and explicit task routing. It does not provide a framework for agents to self-organize, reach distributed consensus, or coordinate dynamically in unstructured environments.

4. Not always the right tool

A 2026 assessment noted that many multi-agent demos from 2025 did not actually require A2A. The underlying issues were better addressed through improved prompting, better tool access, retry logic, and observability. A2A adds value at the coordination layer specifically in heterogeneous, cross-vendor environments.

The A2A roadmap includes planned work on interoperability testing, a registry specification, and security deployment best practices.

Sources and Further Reading

• Wikipedia – "Agent2Agent" https://en.wikipedia.org/wiki/Agent2Agent
• a2a-protocol.org – "A2A Protocol Official Specification" https://a2a-protocol.org/latest/specification/
• Google Developers Blog – "Announcing the Agent2Agent Protocol (A2A)" https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
• Google Developers Blog – "Google Cloud Donates A2A to Linux Foundation" https://developers.googleblog.com/en/google-cloud-donates-a2a-to-linux-foundation/
• arXiv (2505.12490) – "Improving Google A2A Protocol: Protecting Sensitive Data and Mitigating Unintended Harms" https://arxiv.org/abs/2505.12490
• arXiv (2602.11327) -- "Security Threat Modeling for Emerging AI-Agent Protocols" https://arxiv.org/pdf/2602.11327
• arXiv (2604.02369) – "Beyond Message Passing: A Semantic View of Agent Communication Protocols" https://arxiv.org/pdf/2604.02369