A2A (Agent-to-Agent Protocol)

Pattern

A reusable solution you can apply to your work.

A standard protocol for agents to discover each other’s capabilities, exchange messages, and collaborate on tasks across vendor and framework boundaries.

Understand This First

MCP (Model Context Protocol) – MCP standardizes agent-to-tool communication; A2A standardizes agent-to-agent communication.
Protocol – A2A is a specific protocol; understanding the general concept helps.
Agent Teams – A2A provides the interoperability layer that makes cross-vendor agent teams possible.

At the agentic level, MCP solved a critical problem: how an agent talks to tools. But tools are passive. They wait to be called, execute, and return a result. Agents are different. They carry their own goals, their own context, their own reasoning. When two agents need to work together, the conversation isn’t a function call. It’s a negotiation.

A2A (Agent-to-Agent Protocol) is an open protocol, originally created by Google, that standardizes how agents discover each other, exchange messages, and coordinate on tasks. If MCP is the USB port that connects an agent to peripherals, A2A is the network protocol that lets agents talk to each other. Google donated A2A to the Linux Foundation in 2025, where it launched as the Agent2Agent Protocol Project at Open Source Summit North America that June. Over 150 organizations have joined the initiative, including Salesforce, SAP, ServiceNow, and Atlassian, and three major cloud platforms now run A2A in production: Microsoft Azure AI Foundry and Copilot Studio, AWS Bedrock AgentCore Runtime, and Google Cloud. The protocol reached version 1.0 on March 12, 2026, with reference SDKs across Python, Go, Java, JavaScript, and .NET, all maintained under the a2aproject GitHub organization. A community Rust SDK exists separately.

The protocol matters most when agents come from different vendors or frameworks. Your coding agent needs a security-scanning agent built by a different team, running a different model, deployed on a different platform. Without a standard way to communicate, you’re back to writing custom glue code for every combination.

Problem

How do two agents from different vendors collaborate on a task when neither knows the other’s internal architecture, model, or framework?

Within a single harness, agent coordination is a solved problem. Subagent delegation and Agent Teams handle it because the harness controls both sides of the conversation. But the moment you cross a vendor boundary, that control disappears. Your Claude-based agent can’t peek inside a Gemini-based agent’s context. It doesn’t know what the other agent can do, what format it expects, or how to check whether a delegated task is still running.

Forces

Vendor diversity is growing. Organizations use agents from multiple providers, each with different capabilities.
Agents aren’t tools. A tool call is synchronous and stateless. Agent collaboration can span minutes, hours, or days, and it requires status tracking and ongoing message exchange.
Capability discovery is hard. Before an agent can delegate work, it needs to know what the other agent is good at, in a machine-readable format.
Security compounds across boundaries. Every agent-to-agent connection introduces new trust boundary questions.
Long-running tasks need state. A task delegated to another agent might take time. The requesting agent needs a way to check progress, receive updates, and handle failure.

Solution

A2A defines a standard conversation between a requesting agent (the client) and a responding agent (the server). The protocol runs over HTTP, with JSON-RPC and gRPC as peer bindings so the same logical agent can be reached over either. Task delivery works in three modes: short-poll for simple cases, streaming (typically over Server-Sent Events) for long-running work, and webhooks when the client prefers callbacks. Teams pick whatever fits the deployment they already have.

The protocol has three core mechanisms:

Agent Cards for discovery. Every A2A-compatible agent publishes an Agent Card: a JSON document describing what it can do, what inputs it accepts, and how to reach it. Think of it as a machine-readable resume. A coding agent looking for a security scanner can read Agent Cards to find one that handles vulnerability analysis, check that it accepts the right input format, and initiate a conversation. Agent Cards live at a well-known URL (/.well-known/agent.json), so discovery is as simple as fetching a file. In v1.0, Agent Cards can be cryptographically signed, which lets a receiving agent verify that the card was actually issued by the domain it claims to represent. A single endpoint can also host multiple agents through a multi-tenancy layer, which is what made A2A practical for SaaS platforms that serve many customers from shared infrastructure.

Tasks as the unit of work. When an agent delegates work, it creates a Task. The task has a lifecycle: it starts as submitted, moves to working, and ends as completed, failed, or canceled. The requesting agent can poll the task for status or subscribe to a stream of updates. This lifecycle handles the reality that agent work isn’t instant. A code review might take thirty seconds. A full security audit might take twenty minutes.

Message exchange within tasks. Agents communicate through Messages attached to tasks. Each message contains Parts (text, files, structured data, or other media). The requesting agent sends a message describing what it needs. The responding agent sends messages back with results, questions, or progress updates. This back-and-forth can continue for as many rounds as the task requires.

For authentication, A2A supports multiple schemes including OAuth 2.0 and API keys, reusing whatever identity infrastructure your organization already has.

Tip

If your agents all live within a single harness, you don’t need A2A. Use your harness’s native coordination: subagents, agent teams, shared task lists. A2A earns its keep when agents cross vendor, framework, or organizational boundaries.

How It Plays Out

A development team uses a Claude-based coding agent for day-to-day work. Their security team maintains a separate agent, built on a different model, that specializes in vulnerability scanning and compliance checks. Before A2A, the developers had to manually export code changes, feed them to the security agent through a custom script, parse the results, and relay findings back to the coding agent. With A2A, the coding agent reads the security agent’s Agent Card, discovers it accepts code diffs and returns structured vulnerability reports, and delegates a security review as a Task. The security agent works asynchronously, streaming findings as it goes. The coding agent picks up each finding and starts fixing issues before the full scan completes.

A platform team at a larger company builds an internal agent marketplace. Each team publishes their specialized agents (database optimization, API design review, documentation generation) with Agent Cards. When a developer’s coding agent hits a performance problem it can’t diagnose, it searches the marketplace for an agent with database-tuning capabilities, reads the Agent Card to confirm compatibility, and delegates the analysis. The developer doesn’t need to know which team built the database agent or what model it runs. The protocol handles the introduction.

Consequences

A2A turns the growing population of specialized agents into a composable ecosystem. Instead of building one agent that does everything (poorly), teams can build focused agents that do one thing well and collaborate through a standard protocol. The same network effects that made the web powerful apply here: each new A2A-compatible agent becomes available to every other A2A-compatible agent.

The protocol also establishes a clean separation between agent internals and agent interfaces. An agent can change its model, its framework, or its entire architecture without breaking integrations, as long as its Agent Card stays accurate and it honors the protocol.

The costs are familiar to anyone who has worked with distributed systems. Every protocol layer adds latency and failure modes. Agent Card discovery can fail. Tasks can time out. Messages can arrive out of order in edge cases. Authentication across organizational boundaries means managing credentials and trust relationships that didn’t exist before.

There’s a security dimension worth attention. When you let agents talk to agents, you extend trust chains. A compromised agent that publishes a misleading Agent Card could trick other agents into sending it sensitive data. Signed Agent Cards close the easiest version of this attack (a card that falsely claims to represent a trusted domain), but they don’t stop a legitimately identified agent from overstating its own capabilities. The same prompt injection risks that apply to MCP tool descriptions apply to Agent Card capability claims. Treat every external agent as an untrusted party until you have reason to do otherwise.

A2A is not the only protocol in this space. The Agent Communication Protocol (ACP) from IBM targets enterprise messaging patterns, and the Agent Gateway Protocol (AGP) from Cisco focuses on secure gateways between agent networks. With its 1.0 release and 150+ member organizations, A2A has the broadest adoption and institutional backing, but the space is young enough that consolidation hasn’t finished. One signal that A2A is becoming a substrate others build on: the Agent Payments Protocol (AP2), backed by 60+ organizations across payments and financial services, ships as a formal A2A extension rather than as a competing protocol.

Sources

Google introduced A2A in April 2025 as an open protocol for agent interoperability, positioning it as the agent-to-agent complement to MCP’s agent-to-tool standardization.

The Linux Foundation accepted A2A governance in 2025 as the Agent2Agent Protocol Project, with over 150 member organizations including Salesforce, SAP, ServiceNow, Atlassian, and multiple cloud providers, giving the protocol institutional backing comparable to MCP’s. (A2A is hosted directly by the Linux Foundation, not under the separately formed Agentic AI Foundation that anchors MCP, goose, and AGENTS.md.)

The A2A 1.0 specification, released March 12, 2026, marked the first stable release, introducing signed Agent Cards for discovery-time identity verification, multi-tenancy so one endpoint can host many agents, gRPC alongside JSON-RPC as peer bindings, and three task-delivery modes (polling, streaming, webhooks). Reference SDKs span Python, Go, Java, JavaScript, and .NET, all maintained under the a2aproject GitHub organization. A community Rust SDK exists separately at tomtom215/a2a-rust.

The HackerNoon protocol comparison “MCP vs. A2A vs. ACP” (2025) provided a clear taxonomy of the three emerging agent interoperability protocols and their distinct design philosophies: MCP for tools, A2A for peer agents, and ACP for enterprise messaging patterns.

Keyboard shortcuts