A2A (Agent-to-Agent Protocol)

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.

Context

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’s Agentic AI Foundation in 2025, and over 150 organizations have joined the initiative, including Salesforce, SAP, ServiceNow, and Atlassian. The protocol reached version 1.0 in early 2026, with production-ready SDKs in Python, JavaScript, Java, Go, and .NET.

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 and JSON-RPC with Server-Sent Events for streaming, using familiar web infrastructure that most teams already know how to deploy.

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.

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.

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. 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.

Related Patterns

• Complements: MCP (Model Context Protocol) – MCP connects agents to tools; A2A connects agents to agents. Together they cover the two directions of agent interoperability.
• Enables: Agent Teams – A2A provides the cross-vendor coordination that agent teams need when teammates aren’t all in the same harness.
• Enables: Subagent – A2A allows subagent delegation across vendor boundaries.
• Refines: Protocol – A2A is a specific protocol for agent-to-agent interaction.
• Related: Trust Boundary – every A2A connection crosses a trust boundary that needs explicit management.
• Related: Prompt Injection – Agent Cards and messages are attack surfaces for injection.
• Uses: Parallelization – A2A enables parallelization across agents that don’t share a harness.

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’s Agentic AI Foundation accepted A2A governance in late 2025, with over 150 member organizations including Salesforce, SAP, ServiceNow, Atlassian, and multiple cloud providers, giving the protocol institutional backing comparable to MCP’s.

The A2A 1.0 specification (early 2026) marked the first stable release, introducing multi-protocol support, enterprise multi-tenancy, modernized security flows, and production-ready SDKs in five languages (Python, JavaScript, Java, Go, .NET).

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.