The agent ecosystem is running an “A2A vs. MCP” debate as if you have to pick a side, or as if “A2A on top of MCP” is now a law of nature. Both framings hide the real architectural choice. These are two different layers, they answer two different questions, and only one of them is a constant.
We’re seeing an uptick in this debate now that the MCP steering group just shipped the 2026-07-28 MCP release, prompting people to wonder if anything there changes the layering argument. Mostly no, but two pieces of the release make the debate sharper (auth hardening and the stateless core) and one piece (Tasks) narrows the case for reaching for A2A even further.
We’ll get to those specifics, but regardless of any protocol talk, here’s what I want you to remember.
For almost every agent you will ship this year, the tool layer is the same, and it is MCP. Agent-to-agent coordination is not a given. It is a decision you make for a specific minority of systems. Most teams reach for a coordination protocol well before they have a problem that needs one. So the honest version of the debate is not “which protocol wins.” MCP is the constant. A2A is the conditional, and the tool layer has to stay a strictly separate layer no matter what you put above it.
Coordination versus execution
The cleanest way to hold these apart is to notice they sit at different layers of the same system.
MCP, the Model Context Protocol, is the execution layer. It standardizes how an agent discovers and calls a tool, so tools are not hardcoded into every prompt and app. When MCP does its job, something happens in the world: a record is written, an API is hit, a refund is issued. MCP is the tools on the workbench.
A2A, the Agent2Agent protocol, is the coordination layer. It standardizes how autonomous agents find each other, delegate tasks, and pass context. A2A does not execute anything against an external service. It decides who does the work. A2A is how the crew divides the job.
That single picture explains the asymmetry. Every worker needs tools. Not every job needs a crew. Which is why the tool layer shows up on nearly every system, and the coordination layer shows up only when there is genuinely more than one agent that has to agree on who does what.
The July 28 release does not touch that asymmetry. It deepens the tool layer’s capabilities (stateless scaling, UI, async tasks, hardened auth) without giving MCP any new coordination semantics. MCP still doesn’t decide who does the work. It just got better at being the workbench.
Where the ecosystem actually is
It helps to be precise about how far each layer has traveled, because the maturity gap is real and it should shape your choices.
MCP has effectively won the agent-to-tool layer. It is supported by Anthropic, OpenAI, Google, and Microsoft, it is native in the clients developers already use like Claude Code and Cursor, and its SDKs are pulling tens of millions of downloads a month against a base of more than ten thousand enterprise servers. When people say the connectivity problem is solved, this is what they mean. MCP is the hero of this season, and we say that as one of its biggest supporters — supporters who helped write this spec.
A2A is the credible, vendor-neutral answer for the coordination layer, and there is a lot of conversation around it. Google announced it in April 2025, donated it to the Linux Foundation that June, and the project shipped v1.0 under Linux Foundation governance in April 2026, with more than 150 member organizations and support from Google, Microsoft, and AWS. Mindshare is not the same as adoption, though. In real enterprise deployments A2A still trails MCP by a wide margin, and it is improving slowly rather than surging. The discussion is loud. The production footprint is early.
The consensus read is a two-layer stack: MCP for vertical agent-to-tool connectivity, A2A for horizontal agent-to-agent coordination, complementary rather than competing. We agree with that read. We would just add the part practitioners feel and the diagrams leave out: in real usage the mix is lopsided. MCP is on almost everything we see. A2A shows up in specific cohorts, and it is worth naming exactly which ones.
| MCP (tool layer) | A2A (coordination layer) | |
|---|---|---|
| Question it answers | How does an agent use a capability? | How do agents delegate to each other? |
| Other end of the connection | A tool or resource | Another agent |
| Present in your system | Almost always | Only for multi-agent topologies |
| Maturity | Adopted default, longer track record | v1.0 and real mindshare, enterprise adoption still early but improving |
| Custodian | Model Context Protocol project | Linux Foundation |
A use-case matrix: what each cohort actually needs
We’re beyond a binary “A2A or MCP” choice. The question is, “which layers does this system need?” Here is how it breaks down across the cohorts we actually see, and where the new release shifts the calculus.
| Cohort | Coordinator | Need MCP? | Need A2A? | Why | Anything new? |
|---|---|---|---|---|---|
| 1. Prebuilt-harness, user-facing agents (Claude Code, Cursor, ChatGPT, Claude Desktop) | The harness plus the human | Yes | No | The harness is the coordinator and a person is in the loop. There is no second agent to talk to. | MCP Apps means these harnesses can now render server-side UI directly through MCP, closing off one more reason a team might have reached outside the protocol for richer interaction. |
| 2. Custom single agent, your own harness | Your orchestration code | Yes | Rarely | You own the loop. Add A2A only when you must federate with agents you do not own. | The stateless core means your own harness can scale its MCP calls across any server instance without session affinity. |
| 3. Background or triggered agents (event-driven, no human) | A trigger plus your code | Yes | Usually no | A webhook or schedule plus an MCP tool call does the job for a single actor. | This is the cohort the Tasks extension speaks to directly. MCP just absorbed one more reason people reached for something heavier. |
| 4. Multi-agent across teams or organizations, at scale | A2A | Yes | Yes | Many agents owned by different teams. A2A standardizes discovery and delegation and makes agent-definition management tractable. Tools still come from MCP. | The stateless core is a direct win for running an MCP runtime underneath an A2A coordination layer at organizational scale. |
Cohort 1 is most of the market, and it needs no A2A at all. If your users live in a prebuilt harness, the harness already does the coordinating and a human is steering. What the agent lacks is not a way to talk to other agents. It is a governed way to call Gmail, Slack, GitHub, or Salesforce as that specific user. That is a tool-layer problem, start to finish.
Cohort 2 owns its own loop, so coordination is just code. When you build the harness, the orchestration is functions calling functions inside one trust boundary. Introducing an agent-to-agent protocol here adds a wire format and a discovery mechanism to a problem you are already solving with a for-loop. Reach for A2A when you need to hand work to an agent that another team or vendor operates, not before.
Cohort 3 is where teams most often over-build. A background agent triggered by an event feels like it wants a framework; usually it wants a trigger and a tool. A schedule or webhook firing an MCP tool call is simpler than a coordination protocol for one participant. Cognition, the team behind Devin, put it bluntly: “running multiple agents in collaboration only results in fragile systems.” The Tasks extension reinforces this. Async lifecycle management is now table stakes inside MCP itself.
Cohort 4 is where A2A earns its place. Once you have many agents owned by different teams, you have a real coordination problem: how does one agent discover another’s capabilities and delegate without every pair hand-rolling an integration. A2A solves this. AgentCards give you a standard way to publish and discover agent definitions, making that tractable at scale. Note what doesn’t change: those agents still get their tools from MCP, which now scales statelessly underneath them. A2A manages the crew; MCP is still the workbench, and it just got easier to scale.
The invariant: keep the tool layer strictly separate
Read down the matrix and one column never changes. MCP is present in every cohort. A2A is present in one.
That is not a coincidence, and it is the single most useful thing an architect can take from this. Keep the tool layer strictly separate, and standardize it on MCP, so that your coordination decisions never leak into your execution. The payoff is reversibility. A team that starts in cohort 2 and grows into cohort 4 should be able to add A2A above a tool layer that does not change at all. If instead you entangle coordination and execution, you buy yourself a rewrite of your tools every time your topology shifts.
This is the low-regret move. The coordination layer is the part of your architecture most likely to change as the ecosystem matures. The tool layer is the part you want to be boring, stable, and shared. Draw the line between them on purpose.
Identity is the unfinished business, in two places
Every layer diagram in this space is confident about the boxes and vague about identity, and that’s where the real work lives, in two distinct forms.
The first is user identity at the tool boundary. Whatever sits above, an agent eventually calls a tool on behalf of a human, either directly in cohort 1, or at the end of a two- or three-hop A2A delegation chain in cohort 4.
Either way, whose identity and permissions apply to that call? It’s an old problem. The end-to-end argument, Saltzer/Reed/Clark 1984, says some properties can only be guaranteed at the endpoints. Identity and authorization are exactly those properties.
The July 28 release hardens this hop more concretely than before: six SEPs now mandate MCP servers as OAuth 2.1 resource servers, aligned with how OAuth and OIDC are actually deployed. Real progress, but it still doesn’t carry a user’s scoped authority across multiple agents to the tool that finally acts. Teams fill that gap with a shared service credential and broad standing scopes, which is how you get a confused deputy: an agent, nudged by an injected instruction, triggers a downstream call with far more authority than the user ever had.
The second is agent identity, A2A’s genuinely open problem. User identity asks who the human is; agent identity asks who the agent itself is. MCP mostly needs the first, and the July 28 release answers it well. A2A can’t avoid the second, its whole premise is agents authenticating to each other. And there’s no industry consensus here: A2A v1.0 added signed AgentCards, other efforts borrow from workload identity, verifiable credentials, or OAuth client identity, and most shipping products follow none of them. It is, honestly, a bit of a mess right now, and it is the thing most likely to bite anyone who builds cohort 4 today.
The trap is hard-wiring enforcement to one agent-identity scheme now and then you’re betting on a standard the industry hasn’t chosen. Or wait for consensus and you can’t ship. The way out is to stop coupling policy enforcement to any single identity standard, and enforce at the layer where the agent actually acts.
The real takeaway
“A2A vs. MCP” is not a versus. It is a layering decision with one constant and one variable.
The variable is coordination. Choose it for your cohort. If your users live in a prebuilt harness, you do not need A2A. If you own your own loop, you probably do not either, until you federate with agents you do not control. If you are orchestrating many agents across teams, A2A is the right tool, and it will make managing agent definitions at scale far saner. The constant is the tool layer. MCP is present either way, and it should stay a clean, separate layer so the choice above it stays cheap to change. The July 28 release makes that constant more capable — stateless at scale, richer through UI and async extensions, and more rigorously secured — without changing what it is a constant for.
Then solve identity at the boundary, in both of its forms, because the protocols will not do it for you and the standards are not settled. Maturity in this space is not adopting every new layer the week it ships. It is adding only the layers your cohort needs, keeping them cleanly separated, and putting a real runtime at the point where an agent finally acts on someone’s behalf.
Where Arcade.dev fits
Arcade is the runtime for the layer that never goes away. It hosts and secures your MCP tools, resolves what each client actually supports through the MCP gateway, and injects scoped credentials at execution, so a user’s identity holds whether the tool call comes straight from a prebuilt harness in cohort 1 or arrives at the end of an A2A delegation in cohort 4.
The enforcement hooks run in a fixed order (Access, Pre, Authorize, Execute, Post), so the policy you already run against people applies to an agent’s actions the same way. The model is identical whether you run Arcade managed, run it in your own environment, or run it air-gapped.
One detail matters for where all of this is heading. We built this runtime before MCP existed, so our governance was never coupled to a single protocol. Enforcement lives at the boundary where an agent acts, in code, not in a wire format. That has a quiet but useful consequence: we do not need the industry to finish agreeing on agent identity before you can apply policy. We also helped write the July 28 spec, which is exactly the kind of protocol-agnostic, still-hands-on-the-standard posture this argument depends on.
Whatever the client and agent ecosystem settles on, and whichever agent-identity scheme wins, the same authorization, scoping, and audit model can apply, over MCP today and over A2A or the next protocol after it. We are one of MCP’s biggest supporters and we bet on it as the tool-layer standard. We are also protocol-agnostic by construction, which is why the regulated teams already piloting A2A, including in financial services, can govern it the same way they govern everything else.
None of that blurs the two layers. Coordination and execution stay separate, on purpose. Arcade owns the execution boundary: the moment an agent stops talking and starts acting. That is why Arcade is authorization-first, across 100+ integrations, on OAuth 2.1 and SOC 2 Type 2, so the identity crossing the boundary is delegated auth and not a shared key in an environment variable.
Pick your coordination layer. Keep your tool layer separate. Let us handle what happens when the agent finally acts.
Get started with Arcade for free: docs.arcade.dev. Tool design patterns: arcade.dev/patterns.
From explainers to step-by-step instructions, Arcade is your guide to the largest revision to the MCP spec since launch. Click here for all of our coverage.
