Agent-to-Agent Protocol Explained: A2A in Production

150 organizations adopted the Agent-to-Agent (A2A) Protocol in its first year, and the four largest enterprise agent platforms still don’t support it as a first-class default. That gap tells you more about the state of multi-agent systems than any press release. The open standard for AI agent interoperability is real, it’s shipping in production, and it’s running into the same wall every infrastructure standard hits: the cost of coordination at scale.

Here’s what I’ve observed watching this space: rapid vendor-neutral standardization obscures the actual bottleneck. Production multi-agent deployments aren’t stuck because there’s no protocol. They’re stuck because a protocol alone doesn’t solve quadratic connection overhead, missing payment rails, or the trust gap between what agents can do and what enterprises will let them do. I call this the coordination tax — the hidden cost that grows faster than your agent count and erases the specialization gains you were promised.

Let’s break down what A2A actually does, where it helps, and where you’ll need to build beyond it.

What the A2A Protocol Actually Does

The Agent-to-Agent (A2A) Protocol is an open standard introduced by Google in April 2025 for secure, scalable communication between independent AI agents, later donated to the Linux Foundation and now governed by a Technical Steering Committee. It solves a specific problem: agents built on different frameworks — LangChain, CrewAI, AutoGen, Google ADK — had no common way to talk to each other. Each framework invented its own internal communication model, and cross-framework orchestration meant writing custom glue code that didn’t scale.

A2A treats each agent as a networked service with a standard interface, similar to how web servers communicate via HTTP. The protocol is built on HTTP, JSON-RPC, and Server-Sent Events (SSE) — standards every engineering team already knows. It doesn’t require agents to share memory, tools, or internal context. Each agent communicates through structured task objects, advertising its capabilities through a discoverable identity document that other agents find at runtime.

The design principle is opaque execution. Two agents don’t share internal reasoning traces or proprietary prompt templates. They expose a public contract — an identity card advertising capabilities, a JSON-RPC surface for invoking those capabilities, and a task object that tracks progress. Either side can be a closed system. That property is what makes A2A usable across organizational boundaries: a LangGraph agent at a SaaS vendor can delegate a subtask to a CrewAI agent inside a bank, and neither team has to surrender their internals.

Agent Cards, Tasks, and the Protocol’s Core Concepts

A2A rests on four core concepts that define how agents discover, delegate, and deliver work. These are the building blocks you’ll work with regardless of which SDK or cloud platform you use.

Agent Cards — Machine-readable JSON documents published at /.well-known/agent-card.json that describe an agent’s name, capabilities, authentication schemes, endpoint, and skills. They follow the RFC 8615 well-known URI convention, so any agent can discover any other agent by fetching a URL. Think of them as business cards that agents hand out at runtime. For a deeper dive on how discovery works, our Agent Cards explainer covers the trust and verification considerations.
Tasks — The central work unit, with a lifecycle that moves through defined states: SUBMITTED, WORKING, INPUT_REQUIRED, COMPLETED, FAILED. Unlike a simple API call that returns immediately, a task can be long-running, require mid-stream input from the requesting agent, and stream progress updates back.
Messages — Structured envelopes carrying the actual content exchanged between agents during a task. Messages support multiple modalities — text, structured data, files — and flow bidirectionally.
Artifacts — The deliverables produced by a completed task. An artifact is the tangible output: a generated report, a processed document, a computed result.

These core A2A concepts — Agent Cards, Tasks with lifecycle, Messages, and Artifacts — map cleanly to how you’d structure any collaborative work: find the right specialist, assign the job, exchange information, and receive the deliverable.

A2A vs MCP: Complementary Layers, Not Competing Standards

The most common confusion in this space is whether A2A replaces the Model Context Protocol (MCP). It doesn’t. They operate at different layers and solve different problems.

MCP, originally from Anthropic and now also under the Linux Foundation, standardizes how an agent connects to tools and data — databases, APIs, file systems, SaaS services. It’s a client-server protocol where the server exposes tools and the agent decides when to use them. A2A standardizes how agents discover and collaborate with each other. It’s peer-to-peer, built on the idea that agents are autonomous collaborators rather than passive function libraries.

In practice, production teams stack the two. MCP handles agent-to-tool access. A2A manages cross-agent coordination. A refund-processing agent might use MCP to connect to a payment API and inventory system, then use A2A to delegate a compliance check to a specialized compliance agent running on a different platform. This layered approach avoids the architectural pitfalls of treating the protocols as competing options.

Dimension	A2A	MCP
Purpose	Agent-to-agent communication	Agent-to-tool/data communication
Interaction Model	Peer-to-peer with task lifecycle	Client-server with synchronous calls
Discovery	Agent Card (JSON) at `.well-known/agent-card.json`	Static endpoint configuration
Protocol	JSON-RPC + SSE + HTTP	JSON-RPC over stdio or HTTP
When to use	Coordinating agents across boundaries	Giving an agent access to tools

You need both in a production multi-agent system. MCP gives each agent its tools. A2A lets those agents work together.

The Coordination Tax: Why 150+ Adoptions Mask a Scaling Problem

A2A adoption grew from 50+ launch partners to 150+ organizations in its first year, with deep integration into Azure AI Foundry, AWS Bedrock AgentCore, and Google Cloud. The v1.0 specification, published in March 2026, added Signed Agent Cards for cryptographic identity, multi-tenancy support, modern OAuth flows (device code, PKCE), and a tasks/list method with filtering and pagination. The Technical Steering Committee spans eight companies: AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow.

Here’s the catch: adoption numbers measure intent, not production efficiency. The real bottleneck isn’t whether agents can talk to each other — it’s how much it costs to manage those connections at scale.

Without a central gateway, a deployment of 20 agents requires up to 190 point-to-point connections. That’s the quadratic integration overhead that A2A alone doesn’t eliminate. The protocol standardizes the wire format, but it doesn’t route, enforce access control, or manage credentials across your agent fleet. You still need a gateway layer.

This is what I call the coordination tax. Every new agent you add doesn’t just connect to one more agent — it potentially connects to every existing agent. The engineering cycles you spend wiring up connectivity are cycles you’re not spending on agent capabilities. Access control fragments across individual connections. Security policies become inconsistent. The result is slower time-to-market for new agent workflows and operational overhead that scales quadratically with each new agent.

The fix isn’t another protocol feature. It’s infrastructure. AWS’s serverless A2A gateway pattern — a single entry point handling routing, discovery, and fine-grained permissions — is the architectural response. You place one gateway in front of all your agents, regardless of where they run, and manage access centrally. For more on how MCP and A2A combine in production multi-agent systems, the operational infrastructure for identity, observability, and cost governance is where most enterprises hit the wall.

The Vendor Silo Problem: Open Standard, Closed Platforms

The four dominant proprietary agent platforms — Microsoft Copilot Agent, Salesforce Agentforce, SAP Joule, and ServiceNow Now Assist — maintain their own extensibility surfaces and do not adopt A2A, MCP, or Llama Stack as first-class defaults. They sit on the A2A steering committee, but their platforms don’t expose A2A as the primary way agents communicate.

This creates a tension that adoption numbers obscure. The open standard is winning the interoperability narrative, but most enterprise agents still communicate inside vendor silos. If you’re running Copilot Studio, your agents talk to other Copilot agents through Microsoft’s extensibility layer. If you’re on Agentforce, they talk through Salesforce’s. The open protocol exists alongside these platforms, not within them.

What this means for you: if your agent architecture spans multiple enterprise platforms, A2A is your bridge between silos, not a replacement for them. You’ll likely run A2A at the boundaries — connecting a Salesforce agent to an internal custom agent, or linking an AWS-hosted agent to one on Google Cloud. Inside each platform, you’ll use the platform’s native extensibility. The protocol tax of maintaining both the platform’s extensibility model and the open standard is real, and it’s a cost you need to budget for.

The locked asset isn’t the agent code. It’s the tool inventory the agents call. If you invest in MCP servers that expose your internal tools, those are portable across any MCP-compatible client. If you invest in platform-specific extensibility, you’re betting on that platform’s continued dominance.

Trust, Payments, and the Autonomous Agent Economy

The A2A specification handles discovery, delegation, and task lifecycle. It doesn’t handle payment. That gap matters because the emerging use case for multi-agent systems isn’t just collaboration — it’s commerce. Agents hiring other agents for specialized work, paying per-task, and settling transactions without human intervention.

Two developments are addressing this. The x402 protocol, built by Coinbase and now maintained by the x402 Foundation, lets agents pay for HTTP requests in USDC stablecoin the moment they hit a paywall — no account, no API key, no card on file. AWS shipped Bedrock AgentCore Payments with x402 as the payment layer in May 2026, and Cloudflare baked it into their Agents SDK. Separately, A2A Commerce has been formalized as a fifth paradigm of electronic commerce, defining how autonomous agents transact on behalf of human principals.

But here’s the trust barrier: only 27% of companies trust fully autonomous agents. That number tells you the protocol and payment infrastructure are ahead of organizational readiness. Tamper-proof metering — verifiable records of what agents did, what they paid, and what they received — is the missing layer between the technical capability and enterprise adoption. Without it, the autonomous agent economy stays in preview.

The A2A security landscape has its own gaps. If you’re building toward autonomous agent commerce, you’re building payment rails, metering, and security controls that the protocol doesn’t provide out of the box.

A Decision Framework for A2A Adoption

Your approach to A2A should depend on your team’s size, your existing platform commitments, and your tolerance for operational complexity. Here’s how I’d think about it.

When A2A is the right call:

You’re running agents on multiple platforms (Azure + GCP, or a mix of custom and vendor-hosted) that need to coordinate on shared workflows.
You have agents built on different frameworks (LangGraph, CrewAI, ADK) that need to delegate work to each other.
You’re building an agent marketplace or platform where third-party agents need to discover and interact with your agents.
Your agent architecture spans organizational boundaries — different teams, different companies, different trust domains.

When A2A adds cost without proportional value:

You’re running a single-agent system that just needs tool access. MCP is the right choice; A2A adds overhead without benefit.
All your agents run on a single platform (Copilot Studio, Agentforce) and communicate through that platform’s native extensibility. Adding A2A alongside the platform’s own protocol creates a maintenance burden without unlocking new capabilities.
Your team is small and your agent count is low. The coordination tax of standing up a gateway, managing Agent Cards, and handling cross-agent auth may exceed the integration cost you’re trying to avoid.

What to build before scaling agent counts:

A central A2A gateway for routing, discovery, and access control — not point-to-point connections.
Payment rails (x402 or equivalent) if any agent-to-agent interaction involves paid services.
Tamper-proof metering for every agent transaction, regardless of whether payment is involved.
Token lifecycle management that addresses the spec’s deliberate security gaps.

The Open Question

The A2A protocol is a genuine engineering achievement — a vendor-neutral standard that reached production in twelve months with backing from every major cloud provider. But the pattern I keep seeing is that protocol adoption and production efficiency are different problems. The 150-organization milestone tells you the industry agrees on the wire format. It doesn’t tell you that multi-agent systems are easy to operate.

Here’s the question worth sitting with: if your agent mesh requires a gateway, payment rails, metering, and security controls that the protocol doesn’t provide, what percentage of your multi-agent infrastructure is actually A2A? The protocol is the thin layer that makes inter-agent communication possible. Everything that makes it safe, observable, and economically viable — that’s on you to build.