When developers ask why their multi-agent system keeps breaking, the answer is usually the same: MCP tells agents how to reach tools. It does not tell agents how to reach each other. Every team that has tried to build a system where one agent delegates to another, coordinates across organizational boundaries, or orchestrates specialized agents built on different frameworks runs into this gap. The Model Context Protocol was not designed to solve it. The Agent2Agent (A2A) protocol was.
A2A reached version 1.0 in early 2026, approximately one year after Google first proposed it. The jump from draft specification to v1.0 matters more than version numbers usually do. It introduced Signed Agent Cards, the cryptographic mechanism that closes the primary attack vector against multi-agent systems: a fake agent presenting itself as a trusted one. Without signed cards, any attacker who can intercept an agent discovery request can redirect agents to malicious endpoints by spoofing a legitimate Agent Card. With signed cards, the receiving agent verifies the card’s cryptographic signature against the domain’s published public key before establishing communication.
As of April 2026, A2A is governed by the Linux Foundation, has 150+ participating organizations, 22,000 GitHub stars, and production deployments inside Azure AI Foundry and Amazon Bedrock AgentCore. IBM’s ACP, the only credible competing specification, voluntarily merged into A2A in August 2025. For developers building multi-agent systems today, A2A is the interoperability layer.
The MCP and A2A Distinction That Every Agent Builder Needs to Understand
The confusion between MCP and A2A comes from a surface-level similarity. Both are protocols for connecting AI systems to things outside themselves. Both use structured message formats over HTTP. Both have become major infrastructure standards in 2025 and 2026. The distinction is in what each connects and what properties that connection requires.
MCP connects an agent to tools: databases, APIs, filesystems, external services. A tool in MCP is a primitive with defined input and output schemas and deterministic behavior. The agent calls the tool, the tool executes and returns a result. The agent does not need to negotiate with the tool, maintain a long-running task relationship with it, or handle the tool going partially complete and needing to resume. MCP is synchronous and structured by design, because tools are synchronous and structured.
A2A connects agents to agents. An agent is not a tool. It has its own goals, its own reasoning process, its own set of tools, and the ability to take actions that unfold over time with intermediate states and partial results. When Agent A delegates a research task to Agent B, Agent B might spend 40 minutes browsing, synthesizing, and refining before returning a result. Agent A needs to know that Agent B accepted the task, track its progress, receive streaming updates, and handle the case where Agent B encounters an error partway through. None of this fits the MCP tool call model.
The A2A specification authors describe the relationship precisely: MCP provides agent-to-tool communication; A2A provides agent-to-agent communication. The official documentation uses a retail analogy. MCP connects an inventory agent to the database of stock levels. A2A connects the inventory agent to a procurement agent at a supplier to initiate an order. The database call is MCP. The inter-organizational agent conversation is A2A. Both protocols are in play simultaneously in a fully realized multi-agent system.
How A2A Works: Agent Cards, Tasks, Messages, and Artifacts
A2A has four core objects. Understanding them is understanding the protocol.
Agent Cards are JSON files published at a well-known URL path, /.well-known/agent-card.json, on any domain running an A2A agent. The Agent Card describes the agent’s name, version, endpoint URL, supported capabilities, authentication requirements, and skills. Skills are discrete capabilities the agent offers, expressed as structured descriptions rather than formal schemas. An agent discovering whether another agent can help with a task reads its card to understand what skills are available, then routes the request accordingly.
The v1.0 addition that changes the security picture is the AgentCardSignature object. When an A2A server signs its card, it generates a cryptographic signature over the canonical JSON of the card using a key associated with the domain. A client agent receiving the card can verify the signature against the public key published at the domain’s JWKS endpoint. If the signature verifies, the card is authentic. If it does not, the client knows the card has been tampered with or forged. Without this, any attacker with network access to an agent discovery request can serve a spoofed card directing the requesting agent to a malicious endpoint.
Tasks represent the unit of work. When Agent A sends a request to Agent B, a Task object is created with a unique ID and an initial state of submitted. The Task progresses through defined states: working while the agent is processing, input-required if the agent needs additional information to proceed, completed when the work is done, or failed if an error terminated the task. The Task has a lifecycle, not just a result. This is the mechanism that makes multi-step, long-running agent collaboration possible without custom state management code in every integration.
Messages are the communication channel between agents during a task. Either agent can send messages to provide context, ask clarifying questions, report progress, or relay instructions from a human user. Messages have a role field (agent or user) and consist of one or more Parts, which can carry text, files, or structured JSON data. This allows A2A to transmit rich, multimodal content through the same channel rather than requiring separate transfer mechanisms for different content types.
Artifacts are the deliverables a Task produces. When an agent completes research, generates code, or processes a dataset, the output is an Artifact attached to the Task. Artifacts can be streamed incrementally, so the requesting agent can begin processing results before the Task reaches the completed state.
The Task Lifecycle and Asynchronous Execution
A2A is explicitly designed for asynchronous task execution. Operations return immediately with a Task object, and processing continues in the background. This is architecturally different from the synchronous tool call model in MCP, where the caller blocks until the tool returns. The design choice reflects the reality of agent collaboration: a research agent might run for minutes or hours, and the requesting agent cannot block its own processing thread waiting for a result that may arrive in 45 minutes.
Clients have three mechanisms for receiving Task updates. Polling uses the GetTask operation to check the current state of a Task at intervals. Streaming uses Server-Sent Events to push status and artifact update events to the client as they occur, enabling real-time progress tracking without polling overhead. Push notifications use a configured webhook endpoint where the A2A server delivers updates via HTTP callbacks, which is the appropriate mechanism for long-running tasks where keeping an SSE connection open for hours is impractical.
The protocol also supports multi-turn interactions within a Task. If an agent needs clarification to proceed, it sets the Task state to input-required and sends a message requesting the necessary information. The requesting agent sends a follow-up message with the clarification, and the Task resumes. This is multi-turn agent collaboration at the protocol level, not implemented as application logic on top of a single-turn protocol.
The v1.0 Release: Four Changes That Define Production Readiness
The A2A specification went through several draft iterations after Google’s initial announcement in April 2025. The v1.0 release in early 2026 introduced four changes that collectively define what production-ready means for the protocol.
Signed Agent Cards, already discussed, is the security change that matters most. It closes the card forgery attack that would otherwise let any attacker with network access to agent discovery traffic redirect agents to malicious endpoints by serving spoofed cards. An unsigned card is a trust-on-first-use arrangement. A signed card is a cryptographically verifiable assertion of identity.
gRPC support added a second protocol binding alongside the primary JSON-RPC 2.0 over HTTP(S) binding. The gRPC binding uses Protocol Buffers for serialization, which reduces message size and parsing overhead compared to JSON for high-volume agent communication in enterprise environments. Both bindings are required to be functionally equivalent, meaning a client speaking JSON-RPC and a server speaking gRPC can interoperate through a translation layer.
Extended client-side support in the Python SDK added the infrastructure necessary for Python agent frameworks to implement A2A clients without writing protocol code directly. LangGraph, CrewAI, and Google’s Agent Development Kit have all added A2A client support that uses this SDK path.
The AP2 extension shipped as a formal specification alongside v1.0. AP2 (Agent Payments Protocol) adds typed payment mandates to A2A tasks, providing cryptographic proof of authorization for financial actions that agents initiate. This is the mechanism that enables regulated financial services deployments where agents initiating payments need a non-repudiatable audit trail.
IBM ACP Merging Into A2A: What It Means
In August 2025, IBM’s Agent Communication Protocol voluntarily merged into A2A under Linux Foundation AI and Data governance. ACP was the most credible alternative to A2A, backed by IBM’s BeeAI framework and designed with similar goals around agent interoperability. IBM’s decision to merge rather than maintain a competing standard was the signal that protocol consolidation was complete.
The practical implication for developers is that there is now a single interoperability target. Building A2A compliance means your agent can be discovered and called by agents built on Google ADK, LangGraph, CrewAI, Microsoft Semantic Kernel, IBM BeeAI, or any other framework with A2A support. The alternative, building for a proprietary inter-agent communication format, means your agent can only interact with agents built by teams using the same framework. In a multi-vendor enterprise environment, that is not multi-agent. It is multiple siloed single-agent systems.
Production Deployments: Azure AI Foundry and Amazon Bedrock AgentCore
A2A has production-grade deployments inside two of the three major cloud providers’ AI platforms. Azure AI Foundry supports A2A for agent discovery and communication within the Azure ecosystem. Amazon Bedrock AgentCore uses A2A as the inter-agent communication protocol for multi-agent workflows running in Bedrock environments. Google Cloud’s Agent Engine and Agentspace support A2A natively through ADK.
The production deployment pattern at these hyperscaler platforms establishes the baseline expectations for A2A in enterprise settings. Agents are registered with their Agent Cards and published to a discovery registry. Client agents query the registry for agents matching required skills, verify card signatures before establishing communication, initiate Tasks via the A2A endpoint, and receive results through streaming or push notification channels. The pattern is the same whether the agents are on the same cloud or on different clouds communicating across organizational boundaries.
What A2A Does Not Solve
A2A defines how agents communicate and discover each other. It does not define what agents should be permitted to do, how their behavior should be monitored, or what governance structures should apply when agents act in regulated contexts. Those questions are addressed by emerging work like Singapore’s IMDA governance framework and MetaComp’s Know Your Agent standard for financial services, which sits above the protocol layer.
A2A also does not address the security of the agents themselves. A Signed Agent Card verifies that a card was issued by the domain that claims to have issued it. It does not verify that the agent at that endpoint behaves as described or that it has not been compromised after publishing its card. The MCP-SafetyBench finding that no current LLM agent achieves both high defense success and high task success simultaneously applies to agents participating in A2A workflows as much as to MCP tool-using agents. A2A is interoperability infrastructure. It is not a security guarantee about the behavior of the agents using it.
The complement picture for developers building multi-agent systems in 2026 is now relatively clear: MCP for tool connections, A2A for agent-to-agent communication, WebMCP for browser-side agent-page actions, and application-layer governance for behavioral controls and audit requirements. The first two layers have stable specifications with production deployments. The governance layer is still being built. The OX Security data showing 86-89% of enterprise AI agent pilots failing to reach production points to governance gaps, not protocol gaps, as the primary barrier to scaling agent systems. A2A v1.0 solves the interoperability problem. What comes next is harder.