Agent-to-Agent (A2A) Protocols: How Autonomous Agents Will Actually Talk to Each Other

Table of Contents

• What an A2A protocol actually does
• A2A vs. MCP: tools versus peers
• The competing protocols and who backs them
• Anatomy of an A2A interaction
• Why interoperability is a business problem, not just a wire format
• The hard parts nobody markets
• What GaaS operators should do right now
• Insights Most People Overlook
• References

What an A2A protocol actually does

Strip away the marketing and an agent-to-agent protocol solves a narrow but stubborn problem: how does one autonomous agent, built by one team on one framework, hand work to another agent it has never met before, without a human writing glue code in the middle?

That sentence hides four separate jobs. First, discovery: how does Agent A even find out that Agent B exists and what it can do? Second, capability description: how does B advertise "I can reconcile invoices" in a way A can parse and trust? Third, task delegation and negotiation: A sends a request, B might accept, counter, ask clarifying questions, or stream partial results back over minutes or hours. Fourth, identity and trust: A needs to know it's really talking to B and not an impostor, and B needs to know whether A is authorized to ask.

Google's A2A specification, which the company contributed to the Linux Foundation in mid-2025, handles the first three with a few concrete artifacts. Each agent publishes an Agent Card, a JSON document, conventionally at /.well-known/agent.json, that lists its skills, endpoints, supported modalities, and auth requirements. Other agents fetch that card to decide whether and how to engage. Tasks then flow as structured messages with lifecycle states (submitted, working, input-required, completed, failed), and long-running work streams back over Server-Sent Events. If you've built REST APIs, none of this looks alien, and that familiarity is deliberate. The bet is that adoption follows the path of least surprise.

A2A vs. MCP: tools versus peers

The single most common confusion in this space is conflating A2A with the Model Context Protocol (MCP). They are complementary, not competing, and understanding the split is the fastest way to sound like you know what you're talking about.

MCP, introduced by Anthropic and now widely adopted, connects an agent to tools and data, a database, a Slack workspace, a file system, a payments API. The relationship is vertical and hierarchical: the agent is the brain, the MCP server exposes capabilities the brain can call. The tool doesn't reason; it executes. (Our companion piece on the MCP standard explained for operators goes deep on this layer.)

A2A connects an agent to other agents, peers that have their own reasoning loops, their own context, and their own opinions. The relationship is horizontal. When a travel-planning agent delegates "find me flights" to a specialized airfare agent, it isn't calling a function; it's handing off an open-ended task to something that might come back with questions. Google has been explicit that the two protocols stack: an agent uses MCP to reach its tools and A2A to reach its colleagues. Anthropic's own documentation on building effective agents frames this orchestrator-worker pattern well, even before you put a cross-vendor protocol between the workers.

The practical tell: if the thing on the other end has a system prompt, you probably want A2A. If it's a deterministic endpoint, MCP is the cleaner fit.

The competing protocols and who backs them

Here's where the tidy story falls apart. There is no single A2A standard, there's a cluster of overlapping proposals jockeying for default status, and the politics matter as much as the specs.

Google's A2A is the highest-profile entrant, launched in April 2025 with 50-plus partners and then donated to the Linux Foundation to signal it's not a Google land-grab. It has the most momentum and the cleanest alignment with MCP.

IBM's Agent Communication Protocol (ACP), developed under the BeeAI project, took a different design stance, leaning on standard HTTP semantics and being less prescriptive about message envelopes. IBM later moved ACP under the Linux Foundation's AGNTCY collective (backed by Cisco, LangChain, and others), which muddies the "Google vs. IBM" framing because pieces are now converging under shared governance.

Microsoft has signaled support for A2A in Azure AI Foundry and Copilot Studio while continuing to push its own agent framework conventions. And a long tail of framework-native approaches, LangGraph's handoffs, CrewAI's crews, AutoGen's conversational agents, solve agent-to-agent coordination inside a single framework without any cross-vendor wire protocol at all.

That last point is the one operators underestimate. Most "multi-agent" systems in production today never cross a trust boundary. They're several agents in one codebase, coordinated by a supervisor-agent architecture, passing state in memory. A2A only earns its keep the moment agents from different owners need to interoperate, and that moment is rarer in 2026 than the hype implies. Gartner's commentary on the agentic AI cycle, including its widely-cited prediction that over 40% of agentic AI projects will be canceled by 2027, is a useful cold shower here: cross-org agent meshes are a future state, not a present default.

Anatomy of an A2A interaction

Walking through a concrete exchange makes the abstractions land. Say a procurement agent at one company needs a freight quote from a logistics provider's agent.

1. Discovery. The procurement agent fetches the logistics agent's Agent Card from its well-known URL. The card says: I handle freight quoting, I speak A2A version X, I require OAuth2 bearer tokens, and I support streaming responses.
2. Authentication. The procurement agent presents credentials. This is where most real-world friction lives, more on that below.
3. Task submission. It sends a task: "Quote LTL freight, Chicago to Dallas, 1,200 lbs, deliver by Friday." The message is structured but the payload can carry natural language, files, or structured data.
4. Negotiation. The logistics agent responds input-required: "Is this a residential or commercial delivery address?" The procurement agent answers. This back-and-forth is the thing plain function-calling can't do gracefully.
5. Streaming and completion. The agent works, streams a status, then returns a completed task with the quote as a structured artifact.

Notice that steps 3 and 4 look nothing like a typical API call and everything like delegating to a contractor. That's the design intent, and also why reliability is harder than it looks, because either side can stall, hallucinate a requirement, or loop. The tool-calling reliability problems that plague single agents compound when two reasoning loops talk to each other.

Why interoperability is a business problem, not just a wire format

For a GaaS company, the protocol decision is downstream of a market-access decision. If your agent speaks A2A and the major agent marketplaces and enterprise orchestration platforms speak A2A, your agent is callable by a much larger buyer base without bespoke integration work. That's distribution. The protocol is a plug, and you want to fit the most common socket.

This is the same dynamic that played out with payment rails, OAuth, and webhooks. The winning standard is rarely the most elegant one, it's the one with the gravity of adoption. McKinsey's analysis of the agentic AI opportunity argues the real value unlock comes from agents working across functions and systems rather than as isolated point solutions, which is precisely the cross-boundary scenario that interoperability standards exist to serve.

There's also a pricing wrinkle the protocol enables. Per-outcome and per-task billing, the economic model at the heart of GaaS, gets much easier to operationalize when tasks have well-defined lifecycle states. A protocol that marks a task completed versus failed gives you a billable event boundary. Vague chat-style integrations don't. So the protocol you adopt quietly shapes what you can charge for and how you meter it.

The hard parts nobody markets

The demos are clean. Production is not. A few realities that the launch blog posts skip:

Identity is the unsolved core. Bearer tokens and Agent Cards handle the happy path, but delegated authority, Agent A acting on behalf of a specific human user when it calls Agent B, is genuinely hard. Who is liable when a delegated agent overspends? How do you scope and revoke an agent's authority mid-task? The identity-and-auth infrastructure for agents is years behind the messaging layer, and it's the part that will actually gate enterprise adoption.

Trust doesn't come from the protocol. A2A tells you an agent claims to reconcile invoices. It says nothing about whether it does so correctly, safely, or without leaking your data to its model provider. Capability discovery is not capability verification. Reputation, certification, and runtime monitoring all have to live above the protocol, and none of that is standardized.

Semantic mismatch survives syntactic agreement. Two agents can both speak perfect A2A and still misunderstand each other, because "deliver by Friday" means different things to different reasoning models. The wire format being interoperable doesn't make the meaning interoperable. This is the deep version of the problem, and no protocol solves it.

Failure modes multiply. When agent A calls B which calls C, a stall or hallucination three hops deep is brutal to debug. The observability stack for agent infrastructure has to trace across trust boundaries where you may not even control the other end.

What GaaS operators should do right now

My honest read, as of mid-2026: don't bet the company on a single protocol, but don't ignore the standards either.

Support A2A at your edges if you're selling an agent that enterprises will want to compose into larger workflows, it's the highest-momentum standard and Linux Foundation governance lowers the lock-in risk. Keep your internal coordination framework-native; you don't need a cross-vendor protocol to make three of your own agents cooperate, and forcing one in adds latency and failure surface for no benefit. Treat the Agent Card as a marketing asset as much as a technical one, it's literally how other systems discover what you sell.

Above all, build your identity, authorization, and observability layers as if the protocol will change, because it might. The wire format is the cheap, swappable part. The trust infrastructure underneath is the expensive, durable part, and it's where the real moat in agentic AI-as-a-service will turn out to be.

Insights Most People Overlook

• The protocol war is mostly theater for now. The vast majority of "multi-agent" production systems in 2026 are single-owner, single-codebase deployments that never cross a trust boundary. A2A's true addressable problem, interop between agents owned by different organizations, is real but still nascent. Adopt for future-proofing and distribution, not because your current architecture needs it.

• Whoever owns the discovery registry owns the leverage. The wire protocol will likely commoditize and converge. The durable power sits with whoever runs the directory of agents, the equivalent of an app store's search ranking. Watch who controls agent registries and reputation scoring; that's where the rent gets collected, a theme the interoperability standards governance question circles repeatedly.

• A2A quietly standardizes your billing event. Because tasks carry explicit lifecycle states, the protocol hands GaaS companies a clean completed/failed boundary to meter per-outcome pricing against. The protocol that wins won't just shape integration, it'll shape the unit economics of the entire category.

• Capability discovery without verification is a security liability, not a feature. An Agent Card is a self-declared claim. Treating discovered capabilities as trustworthy is the agentic equivalent of running code from a stranger because the filename looked official. The missing layer, independent capability verification, is a startup-sized opportunity hiding in plain sight.

• Semantic interoperability may never fully arrive, and that's fine. Two compliant agents can agree on every byte and still misunderstand intent. The pragmatic fix isn't a better protocol, it's the same thing that makes human contracting work: tight task scoping, confirmation steps, and human-in-the-loop checkpoints at the boundaries. Plan for ambiguity rather than pretending the spec eliminates it.

References

• Building Effective Agents, Anthropic Engineering
• Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027
• Seizing the Agentic AI Advantage, McKinsey QuantumBlack