I spent three weeks trying to make a billing agent ask a refund agent a question. Not a tool call—an actual question. The billing agent needed to know whether a refund was appropriate, and the refund agent needed to reason about policy, check account history, and possibly refuse. I wired it up as a function call anyway. The billing agent waited fourteen seconds for a "tool" that was actually trying to think.
That was the day I stopped treating agents like functions.
The Tool-Call Trap
The mistake is almost inevitable. You build your first agents, you wire them together with tool calls, and it works. The tool returns a value. The caller proceeds. Simple, synchronous, easy to debug.
Then one of your "tools" grows a brain. It needs to ask clarifying questions. It needs to run for six minutes. It needs to decide the request is out of scope and say no. But your architecture treats it as a passive function, so every one of those behaviors looks like a failure—a timeout, a malformed response, an unhandled edge case.
I kept tuning prompts. The model wasn't the problem. The architecture was. I had confused the vertical with the horizontal.
What Tool Calls Can't Do
The Model Context Protocol (MCP) solved a genuinely hard problem. Before it, connecting five agents to ten tools meant up to fifty bespoke integrations, each one a maintenance liability. MCP collapses that into one interface. By mid-2025, the community had built thousands of active MCP servers, and OpenAI, Microsoft, and Google DeepMind all adopted it. MCP won the tool-calling layer, and it deserved to.
But MCP has no concept of a peer agent with its own goals, its own model, and its own authority to act. An MCP server that wraps kubectl does not think, negotiate, or push back. It exposes capabilities and waits. The agent stays in charge; the things it touches are passive.
When my billing agent needed the refund agent to decide something—not fetch a value, not execute a command, but reason through policy and arrive at a judgment—that was never an MCP-shaped problem. It was a horizontal problem. And horizontal problems need a different protocol.
The A2A Protocol: HTTP for Agents
The Agent2Agent (A2A) protocol is an open standard launched by Google in April 2025 and now governed by the Linux Foundation's Agentic AI Foundation. Where MCP is the vertical integration layer connecting agents to internal tools and databases, A2A acts as the horizontal protocol enabling peer-to-peer collaboration. The A2A specification puts the distinction in one sentence: MCP standardizes how an agent uses a tool or resource; A2A standardizes how one agent delegates work to another.
Think of A2A as HTTP for AI agents. Just as HTTP enables any web browser to communicate with any web server regardless of their underlying technologies, A2A enables a LangGraph agent to delegate work to a CrewAI agent, which can then call a Google ADK agent, without requiring custom integration code for each pairing.
The architectural shift matters because it changes what the calling agent expects. When you call an API, it simply returns data or fails. When an agent calls an A2A peer, it initiates a collaboration. The receiving agent can understand intent, refine the plan, push back on incomplete requests, and ask clarifying questions if something is off. That's not a tool call. That's a handoff between peers.
Under the Hood: Agent Cards and Task Lifecycle
A2A standardizes four objects: an Agent Card, a Task, a Message, and an Artifact.
The Agent Card is a JSON manifest served at a well-known URI, describing who an agent is, what it can do, where to reach it, and how to authenticate. This is the discovery mechanism. Your agent doesn't need to know about the refund agent at build time. It queries the registry, reads the card, and decides whether to delegate.
The Task is the unit of work, with an ID, a context ID, a state, a history, and artifacts. Tasks are stateful and progress through a defined lifecycle: submitted, working, input-required, completed, failed, canceled, rejected. The input-required state is the one that matters most in practice—it's the protocol's way of letting a receiving agent ask a clarifying question without collapsing the whole interaction.
The design constraint behind all of this is worth stating plainly: A2A assumes the agent on the other end is opaque. You do not get its tools, its memory, its model, or its internal plan. You get a card, a task ID, and the states it passes through. That opacity is a feature, not a limitation. It's what allows enterprise agents to collaborate without exposing proprietary logic or sensitive data.
From Google to Linux Foundation: Neutral Governance
The protocol's lineage matters for anyone deciding whether to bet on it. Google published A2A in April 2025 and donated it to the Linux Foundation that June, with AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow as founding organizations. By August 2025, IBM's Agent Communication Protocol merged into A2A rather than competing with it.
In August 2026, A2A was accepted as a Growth Stage project at the Agentic AI Foundation. By operating under the Linux Foundation-directed AAIF alongside sibling projects like MCP, goose, and AGENTS.md, A2A is protected from single-vendor constraints. The Linux Foundation supplies the legal and operational structure but does not control technical decisions—a governance model intended to prevent A2A from being tied to Google's product roadmap.
That neutrality is why engineering teams can plan a three-to-five-year deployment around it. Founding members now include every major cloud provider and enterprise SaaS platform that matters.
What Production Taught the Teams That Shipped It
Eon built a multi-agent assistant called Buzz, where about twenty specialists live in the same service and a function call is enough of a boundary. Then three specialists had to leave the process. The triage agent held production credentials Buzz had no business holding. The Eon agent owned the semantic layer and shipped on a different release train. And tenant admins wanted to plug in agents their own teams built, on frameworks Eon doesn't run, whose source they would never see.
A bespoke HTTP contract for each would have worked for the first two cases. The third made that impossible. You can't import a stranger's agent—you can only call it, and to call it you need a contract neither side wrote for the other. That's what A2A exists to solve. The team's conclusion: "Would we choose it again? Yes. An agent's capabilities reach us as data we read at runtime, so a tenant can add an agent to Buzz without us shipping code".
pcell.si has been running an A2A-based multi-agent system since May 2026, with 135 active agents, 12 content-generation bots, and over 200 automated patrol cycles of autonomous operation.
Cisco's CAIPE uses multi-agent orchestration with tool calling via both MCP and A2A. Response times dropped from hours to seconds, and MTTR reduced by up to 80%.
The A2A protocol now runs in production across supply chains, financial services, and mobile platforms, with native support built directly into Google Cloud, AWS Bedrock AgentCore Runtime, and Microsoft Azure AI Foundry. More than 150 organizations support the standard, and major frameworks—LangGraph, CrewAI, Pydantic AI, AG2, IBM BeeAI—have all adopted it.
When to Use A2A (and When MCP Is Enough)
The decision framework that has held up in production:
Use MCP when an agent needs to reach down into the world. Fast, structured, request-response operations. Bounded competences that don't need their own reasoning loop. A database query, a file read, an API call. The agent stays in charge; the thing it touches stays passive.
Use A2A when independent agents need to delegate work across a boundary you don't fully control. When the remote endpoint is genuinely an autonomous agent capable of reasoning, not just a passive tool. When the task might run for minutes or hours, and the receiving agent might ask clarifying questions or refuse.
Use both when your system has both vertical and horizontal needs, which most production systems do. An A2A agent calls MCP to fetch context. An MCP-hosted tool triggers an A2A delegation. The layers compose.
The mistake I made wasn't choosing the wrong protocol. It was not recognizing that I was solving two different problems with one mental model. When my billing agent needed to read account status from a database, that was a tool call. When it needed the refund agent to evaluate whether a refund was appropriate—to reason, check policy, and decide—that was a task delegation.
I had been treating the refund agent as a function. It was a colleague.
The Trade-Off You're Accepting
A2A gives you interoperability and delegation. It costs you some determinism and adds latency.
Every A2A hop is a network round-trip. Every task lifecycle adds state management overhead. The protocol explicitly assumes the remote agent is opaque, which means you can't inspect its reasoning or debug its internals. That opacity is what makes cross-organization collaboration possible, but it also means that when something goes wrong, you're debugging at the boundary, not inside the other agent's brain.
And A2A isn't free of failure modes. A 2026 post-mortem documented a four-agent LangChain pipeline communicating via A2A that entered a handoff loop and burned through $47,000 in tokens before anyone noticed. The fix, like the fix for any peer-to-peer system, is cycle detection and hop budgets.
But here's what I've learned: the teams shipping multi-agent systems to production aren't choosing between MCP and A2A. They're drawing the boundary carefully, treating MCP as the tool-access layer and A2A as the coordination layer, and using each where it actually fits.
So here's my question: When your agent needs something from another agent, does your architecture make it wait like a tool call—or does it hand off the task and move on?
I'd love to hear where you've landed. Pure MCP, A2A where it counts, or a hybrid you had to discover the hard way—and what finally made you draw the line?
Top comments (3)
The fourteen-second timeout you hit with synchronous tools is usually where everyone realizes an agent turn cannot be treated as a network socket. Once you move from vertical tool calls to horizontal peer delegation, the immediate friction becomes transaction boundaries. If the refund agent commits an external ledger entry but the billing agent crashes or runs out of context budget before updating the customer ticket, you suddenly need distributed rollback mechanics or durable outboxes instead of simple message passing.
How does an A2A client resume a task after the receiving agent restarts, especially after receiving
workingbut before the next event?Some comments may only be visible to logged-in visitors. Sign in to view all comments.