A2A and MCP: What Is Actually Different

What A2A actually is

Strip away the protocol spec and A2A is a simple idea. Two AI agents, built by different teams, running on different infrastructure, need to talk to each other and get a real answer back, without either side handing the other direct access to its systems. That is the whole problem A2A exists to solve.

In this lab, the buyer’s agent does not get a database connection into the supplier’s ERP or an API key with broad access. It asks a question, what is the status of PO 4500012345, the way you would ask a person at another company, not the way you would query a table. The supplier’s agent decides what to do with that question, runs its own tools against its own data, and sends back a considered answer. Neither side has to trust the other’s internals. They only have to agree on the protocol.

Three things have to exist for that to work. The supplier publishes a card describing what it can do, a business card with a job description attached, not a wall of API documentation. The exchange is a real conversation, not a single request and response, because a competent counterpart sometimes needs to say it needs more information, or that it is not authorized to answer, instead of just failing. And it all runs over infrastructure any enterprise already trusts, plain HTTP, JSON, because nobody is re-architecting their network for this.

None of that is exotic. It is closer to how two companies agree to do business than it is to a technical breakthrough. That is exactly why it will spread faster than people expect.

A2A versus MCP: the distinction that actually matters

MCP and A2A get lumped together because they both showed up around the same time and both have the word agent somewhere in the pitch. They solve different problems.

MCP is about an agent reaching into its own toolbox: a filesystem, a database, a search index, a calendar. It is the standard way to wire those tools in, so you are not writing a bespoke integration for every tool and every model. The agent and the tool sit on the same side of the fence. You own both. You decide what the agent can touch.

A2A is categorically different. One autonomous system asks another autonomous system a question, and that second system has its own reasoning, its own data, and its own boundaries you do not get to see inside. That is not a tool call. A tool does not think about whether to answer you, or have a policy about what it is allowed to disclose. The supplier’s agent in this lab does. It decides, it reasons, it can refuse.

Here is the way I would put it to a room full of architects. MCP gives your agent a longer arm. A2A gives your agent a phone number to someone else’s agent. You use the first to make your own agent more capable. You use the second when the capability you need does not belong to you, and never will.

Most real enterprise workflows need both, for different hops. Your procurement agent uses MCP to read your own SAP data. It uses A2A to ask a supplier’s agent something your own systems have no way of knowing. Try to expose a supplier’s fulfillment system as an MCP tool instead, and one of two things happens. Either the supplier declines, because no supplier hands over that kind of access, or you build an integration that quietly assumes a level of trust that does not exist between two separate companies.

Why this is about to matter a lot more

I have written elsewhere about headless architecture, the idea that enterprise systems are being forced to expose themselves as clean APIs because agents have no use for a UI. A2A is the next layer of that same shift, and most organisations have not clocked it yet.

Every enterprise adopting agentic AI right now is building internal agents first. One team, one codebase, tools it controls, data it owns. That is the easy 80 percent, and it is exactly where MCP and local sub-agents belong. But the value enterprises actually care about does not stop at their own walls. It is in the supplier who ships the part, the bank that clears the payment, the insurer that processes the claim. The moment your agent needs an answer that only exists inside somebody else’s organisation, MCP has nothing to offer, because MCP assumes you already have access. A2A is built for exactly that boundary, the one place internal agent tooling structurally cannot reach.

That is not a niche case. It is the actual shape of most enterprise work. Supply chains, financial transactions, claims processes, logistics handoffs are inter-company by definition. An enterprise that gets internal agents working but has no answer for cross-company agent communication has automated the easy part and left the hard, valuable, differentiated work exactly where it was, a person on the phone, or an EDI integration nobody has touched since 2011.

The vendor angle is moving faster than most CIOs are tracking. SAP restricted agentic API consumption to its own endorsed pathways in April, and started enforcing it in June. Salesforce did close to the opposite that same month, opening its platform up explicitly for agent consumption. Whatever position any single vendor lands on, the direction is the same. Platform companies are being forced to decide how agents that do not belong to their own customer are allowed to talk to their systems, and A2A is the shape that decision keeps landing on, because it lets two organisations cooperate without either one giving up control of its own systems.

None of this needs to be theoretical for you. This lab is a small, honest version of it, synthetic data, two Cloud Run services, no real company on either end. But the mechanics are the real mechanics. If you are going to be the person asked how your agent talks to a partner’s agent, and if agentic AI keeps moving the way it has, someone will ask you that, this is what the answer looks like.