MCP isn't enough: who lets your agents talk to each other?

There is a tidy story people tell about agent infrastructure in 2026: Anthropic released the Model Context Protocol in late 2024, the industry rallied around it, and now agents have a universal way to use tools. Connection problem solved.

The story is half true. MCP did standardize how an agent reaches its tools, and the convergence around it has been real. But “tools” is doing a lot of quiet work in that sentence. A database is a tool. A search index is a tool. A Stripe API is a tool. What is not a tool — what does not fit the shape MCP describes — is another agent. And the moment your architecture has more than one agent in it, that distinction stops being academic.

This post is about the gap MCP leaves open on purpose, and the two protocols built to close it — A2A and ACP.

What MCP is, precisely

MCP is a client-server protocol spoken over JSON-RPC. Your agent is the host. It runs one or more MCP clients, and each connects to an MCP server that exposes some capability: tools the model can call, resources it can read, prompts it can reuse. When the model needs to query a database, the host sends a JSON-RPC request to that server, the server runs the query, and the result comes back as structured content.

The relationship is asymmetric, and meant to be. The server is dumb in the useful sense: it does not plan, decide, or maintain a goal. It exposes capabilities and waits to be called. All the intelligence — deciding what to call and when — lives in the host. MCP is a way for one brain to reach many hands.

That asymmetry is the whole reason MCP can stay thin. There is exactly one locus of control, and no negotiation, because servers have no intentions to negotiate over. Hold onto that, because it is precisely what breaks next.

The scenario where it breaks

Picture a customer-support agent your team built. It handles a conversation end to end: reads the ticket, looks up order history through an MCP server on your order database, checks shipping status through another MCP server, drafts replies. For everything it owns, MCP is exactly right. Order lookup is a tool. Shipping status is a tool. The support agent is the single brain reaching its hands.

Now a customer asks for a refund.

Refunds do not belong to support. They belong to a finance agent — a separate system, built by a different team, possibly on a different stack, governed by compliance rules your support team is not allowed to read. It runs fraud heuristics, checks the refund against policy, and may approve, escalate for human review, or reject. It might take two seconds or a day. And critically, it is an agent, not an endpoint: it makes decisions, carries the goal of processing this refund to completion, and owns state your support agent has no business touching.

You could wrap the finance agent in an MCP server and expose process_refund as a tool. People do this, it sort of works, and it is the wrong shape — for three reasons.

First, MCP tool calls are request-response over a single call. The model calls, blocks, gets a result. But a refund is not a function that returns in one shot. It is a task with a lifecycle — submitted, under review, escalated, completed or rejected — possibly with status updates along the way. Forcing a day-long, interactive process into one synchronous call means either the call hangs or you bolt a polling protocol onto MCP that it was never designed to carry.

Second, MCP has no notion of the callee being an autonomous peer. A tool does not ask you questions. But a finance agent might legitimately come back with “this exceeds the auto-approve threshold — do you have a manager authorization code?” In the MCP model the server has no standing to initiate that. You would be forcing a two-way conversation through a one-way pipe.

Third — the one that bites in real organizations — wrapping the agent as a tool quietly asserts ownership it does not have. MCP servers are things you configure into your host, which orchestrates them. But the finance agent is not yours to orchestrate. It is a sovereign system with its own policies, SLA, and audit trail. Flattening a relationship between two equals into a master-servant one shows up later as security questions, versioning headaches, and “who is responsible when this fails” arguments.

What you have is not a brain reaching a hand. It is two brains that must cooperate while staying strangers. Different problem, different protocol.

A2A: discovery, delegation, and staying opaque

Google introduced the Agent2Agent protocol (A2A) in April 2025 and donated it to the Linux Foundation shortly after, with more than fifty enterprise partners signed on at launch. Its entire job is the problem above: letting one agent hand a task to another agent it does not own.

A2A is built around three moves.

The first is discovery through an Agent Card. An A2A-capable agent publishes a small JSON document — its Agent Card — describing its identity, the skills it offers, the input and output formats it accepts, and the authentication it requires. The finance agent’s card might advertise a process_refund skill, declare a schema for refund requests, and state that callers must present an OAuth token. The support agent reads this card the way you read an API’s docs before integrating — except it is machine-readable and consumed by another agent at runtime, not by a developer at design time. The card is the contract, and the only thing the caller gets to see.

The second is task delegation. Having read the card, the support agent acts as a client agent and sends the finance agent — the remote agent — a task: “process a refund of this amount for this order, here is the context.” This is not a call that must return immediately. It opens a task with a defined lifecycle: the task moves through states the client can observe — pending, in-progress, and ultimately completed or failed — and the remote agent reports progress as it goes. Because A2A runs over HTTP with Server-Sent Events and JSON-RPC, the remote agent can stream updates and ask the clarifying questions a tool never could. The day-long refund, the “I need a manager code” interjection, the escalation to a human — all of these fit, because the protocol models a task between peers, not a call into a subroutine.

The third makes the whole thing viable across organizational boundaries: agents stay opaque. A2A is explicit that a remote agent need not reveal its internals — not its memory, tools, prompts, or planning. The finance agent exposes its Agent Card and its task interface, nothing else. The support agent cannot see how the refund decision is made and does not need to. This opacity is the feature, not a limitation: it is what lets two teams, or two companies, integrate their agents without either exposing its implementation or compliance-sensitive logic. Strangers cooperate precisely because they are not required to become transparent to each other.

ACP, and why the two are merging

A2A is not the only answer here. IBM, through its BeeAI project, developed the Agent Communication Protocol (ACP) to solve the same coordination problem with different design instincts.

Where A2A leans on JSON-RPC, ACP is REST-first: agents are addressed over plain HTTP and interacted with like any RESTful service. Its messages are MIME-typed, so a message can carry text, JSON, an image, or arbitrary content with the type declared explicitly — which makes multimodal exchanges natural. It supports both synchronous and asynchronous interaction, so a quick request and a long-running job both have a home. And it is deliberately local-first and runtime-independent: agents can discover and talk to each other even offline or on a single machine, with no assumption about the framework or language behind any given agent.

If A2A’s flavor is “enterprise integration across organizations,” ACP’s is “REST-native, run-anywhere agent communication.” They overlap enormously, and the industry noticed. In August 2025 the projects announced they are merging under the Linux Foundation, with ACP’s design ideas folding into the A2A line rather than the ecosystem splintering into two competing standards. For someone choosing today, that convergence is the signal: the horizontal layer is consolidating, and A2A is where.

The mental model that makes this stick

If you remember one thing, make it the geometry.

MCP is vertical. It runs down from an agent to its tools and resources. It answers the question “how does this agent act on the world?” One brain, many hands, a clean asymmetry, a thin protocol.

A2A and ACP are horizontal. They run across, between agents that are peers. They answer the question “how do these agents cooperate without merging into one system or exposing their guts to each other?” Two brains, a shared task, deliberate opacity on both sides.

This is why “MCP versus A2A” is a category error, and why both Google and Anthropic call the two complementary. They are no more competitors than HTTP and SQL are. A mature multi-agent deployment uses both at once: the support agent talks A2A sideways to the finance agent, and each talks MCP downward to its own private tools. The finance agent’s fraud check and ledger writes are its tools, over MCP, invisible to support. The support agent’s order and shipping lookups are its tools, over MCP, invisible to finance. A2A carries the refund between them and never needs to know what either side’s tools are.

What to actually do with this

The practical takeaway is a question you can ask of any integration in front of you: am I reaching a hand, or am I talking to another brain?

If the thing on the other end is a capability with no goals of its own — a database, an API, a search index, a calculator — it is a tool, and MCP is the right and finished answer. Wrap it as an MCP server and move on.

If the thing on the other end makes decisions, carries a goal to completion, owns state you should not touch, and is operated by someone who is not you — it is an agent, and you want A2A. Reaching for MCP there is the mistake the tidy story sets people up to make: it treats the agent-to-agent frontier as if the agent-to-tool victory already covered it. It does not. The tool problem is solved. The agent problem is the one the industry is consolidating around right now — on a different axis, under a different protocol — and it is worth getting the layer right before you have ten agents from five vendors all pretending to be each other’s tools.