I spent three weeks trying to fix a latency problem that didn't exist. Our multi-agent customer support system was slow unacceptably slow, with p99 latencies hitting 14 seconds by the third hop. I blamed the models. I blamed the prompts. I blamed the framework, the network, the token counts.
Then a colleague looked at the architecture diagram, pointed at a box, and asked the question that ended the investigation: "Why is your billing agent calling your refund agent like it's a tool?"
I'd built a system where one agent needed to hand off a task to another agent that had its own reasoning, its own tools, and its own authority to act. But I'd wired it up as a tool call—a synchronous, request-response operation where the "tool" was actually an autonomous system. The billing agent was waiting for the refund agent the way you'd wait for a database query, while the refund agent was trying to reason, ask clarifying questions, and decide whether the request was even valid.
I had confused the vertical with the horizontal. And I was paying for it in every single interaction.
The Distinction That Changes Everything
The confusion is understandable. Both MCP and A2A arrived in the same eighteen-month window, both carry the word "protocol," and both promise interoperability for AI agents. Most teams still treat them as competing standards, or worse, as interchangeable.
They are neither. They sit at different layers of the stack, and a serious agent deployment runs both.
MCP is vertical. It standardizes how a single agent reaches down into the world: calling tools, reading data, invoking APIs. The agent stays in charge, and the things it touches are passive. An MCP server that wraps kubectl does not think, negotiate, or push back. It exposes capabilities and waits. MCP optimizes for fast, structured, request-and-response tool calls.
A2A is horizontal. It standardizes how one agent asks another agent to do work on its behalf. The far side is not a passive tool but an autonomous system with its own model, its own tools, and its own judgment. It can accept the task, ask a clarifying question, run for six hours, or refuse. A2A optimizes for long-running, stateful negotiation between systems that do not trust each other and do not share memory.
MCP gives your agent hands. A2A gives it colleagues.
The Mistake That Costs You
When you treat an agent like a tool, you inherit every assumption of tool-calling. You assume the call will complete quickly. You assume the response will be a structured value. You assume the callee has no state, no goals, and no authority to say no.
None of that is true for an agent.
My billing agent would call the refund agent and wait. The refund agent would try to reason through the request, discover it needed account status, and either fail or return a partial result. The billing agent would either hang, retry, or proceed with bad data. The trace showed a tool call that took 14 seconds. It should have been an A2A task delegation where the billing agent hands off work and moves on, and the refund agent gets back to it when it's done.
The architecture was wrong, and no amount of prompt tuning could fix a structural mismatch.
Why MCP Can't Make Two Agents Talk
MCP solves a genuinely important 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 the protocol. MCP passed roughly 97 million monthly SDK downloads, with public registries indexing close to twenty thousand servers. MCP has won the tool-calling layer.
But MCP has no concept of a peer agent with its own goals, its own model, and its own authority to act. If your procurement agent needs your finance agent to approve a payment, MCP has nothing to say about that conversation. The finance agent is not a tool to be called; it is an actor with its own reasoning and its own right to refuse.
That is a horizontal problem, and it needs a different protocol.
What A2A Actually Provides
A2A handles the horizontal case: agents discovering each other, exchanging messages, and coordinating tasks across organizational and platform boundaries.
Each agent publishes an "Agent Card" describing what it can do, and other agents query that card to decide what work to delegate. The protocol defines task lifecycle states, support for synchronous and asynchronous interaction, and a structure for agents that don't share memory or trust each other.
By April 2026, more than 150 organizations supported A2A, with active production deployments across supply chains, financial services, and mobile platforms. Major cloud providers—including Google Cloud, AWS Bedrock AgentCore, and Microsoft Azure AI Foundry—have built native A2A support directly into their infrastructure. Enterprise SaaS platforms like ServiceNow, Salesforce, Atlassian, and SAP use A2A to connect workflows across their products.
The Real-World Systems Running Both
Cisco's CAIPE (Community AI Platform Engineering) uses multi-agent orchestration with tool calling via both MCP and A2A. Their agents chain across Argo CD, Kubernetes, and Komodor to synthesize actionable answers. The result: response times dropped from hours to seconds, and MTTR reduced by up to 80%.
Elastic's LLM newsroom demonstrates the hybrid pattern in production code. A Reporter Agent delegates research tasks to a Researcher Agent via A2A, and delegates archive searches to an Archive Agent via A2A. The Archive Agent then uses MCP to access Elasticsearch tools. A2A enables agent collaboration; MCP provides tool access. They run together in the same system, each doing what it's best at.
AWS Bedrock AgentCore Runtime now supports both MCP and A2A natively. Agents built using different frameworks—Strands Agents, OpenAI Agents SDK, LangGraph, Google ADK, or Claude Agents SDK—can share context, capabilities, and reasoning in a common, verifiable format. The complete A2A request lifecycle, from agent card discovery to task delegation, is supported out of the box.
Microsoft's Agent Framework team ran a controlled comparison: a ski resort advisor built with A2A specialists versus the same application using distributed skills over MCP. The A2A path used six to seven model calls per request. The skills path used three. Mean elapsed time dropped from 15.48 seconds to 6.35 seconds—roughly 60% faster. The trade-off showed up in token count: the skills path consumed about 22% more tokens because the parent agent's context grew as it loaded specialist instructions. The conclusion: A2A handles collaboration between autonomous agents; MCP handles bounded competences that don't need their own reasoning loop.
The Problem MCP Hasn't Solved Yet
MCP has a scaling problem, and it's structural.
Every tool definition you load into an agent's context window consumes tokens. When you connect to a handful of MCP servers, that's manageable. When you connect to dozens, loading every tool definition upfront can consume the majority of the context window before the model has even read the user's message.
The numbers are brutal. Cloudflare found that tool descriptions alone would consume roughly 244,000 tokens before the agent processes a single user message. Claude Code's /context shows MCP tools alone consuming 97,000 tokens—about 48% of Claude Sonnet 4.5's window. A single MCP server like GitHub can add 15-20k tokens just for tool schemas.
This is the "tool explosion" problem, and it's the reason teams are moving away from naive MCP adoption. Perplexity's CTO said they're moving away from MCP internally. Cloudflare replaced MCP's tool-calling mechanism with code generation and cut token usage by 244x.
But the answer isn't abandoning MCP. It's using it correctly.
The MCP specification itself now recommends progressive discovery: instead of loading every tool definition upfront, the host provides a lightweight search_tools meta-tool, and the model loads full definitions only as needed. The comparison is stark: loading all tools upfront consumes ~150,000 tokens on definitions alone; progressive discovery uses ~2,000 tokens by loading only what the task requires.
Microsoft's Agent Skills extension, standardized in September 2026, takes this further. Skills are addressed via a skill:// URI scheme with progressive disclosure: advertise at roughly 100 tokens per skill, load under 5,000 tokens, read resources and run scripts on demand. The parent agent's context window stays lean.
The DADL paper from April 2026 quantifies the reduction precisely: on a catalog of 1,833 tool definitions across 20 services, Code Mode reduced the LLM context cost of tool advertisement from approximately 142,000 tokens to approximately 1,000—a 142x reduction.
The Decision Framework
The research is clear about when to use what:
Use MCP when an agent needs to discover and call tools at runtime. Use it for fast, structured, request-response operations. Use it for bounded competences—procedures with typed operations that don't need their own reasoning loop.
Use A2A when independent agents need to delegate work across a boundary you don't fully control. Use it when the remote endpoint is genuinely an autonomous agent capable of reasoning, not just a passive tool. Use it for long-running tasks with their own lifecycle, where the callee 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 Atlan decision guide puts it well: MCP, A2A, and ANP are a complementary stack for three jobs. MCP standardizes how an agent reaches a tool or data source. A2A standardizes how one agent delegates structured work to another. ANP standardizes how agents from different organizations authenticate without a shared broker. You rarely pick one instead of another. You adopt each as its job appears.
What I'd Tell My Past Self
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. MCP. Fast, synchronous, structured response.
When my billing agent needed the refund agent to evaluate whether a refund was appropriate—to reason, check policy, and decide—that was a task delegation. A2A. Potentially long-running, with its own lifecycle and its own authority to say no.
I had been treating the refund agent as a function. It was a colleague.
The fix wasn't rewriting the system. It was reclassifying the boundaries. Tool calls stayed synchronous. Agent delegations became asynchronous task handoffs with their own state and lifecycle. Latency dropped because the billing agent stopped waiting for a reasoning process to complete before it could do anything else.
The teams that are getting this right aren't choosing sides. 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 (0)