The MCP spec that shipped on July 28, 2026 crossed something off the list: a production multi-agent stack no longer needs sticky sessions, shared session stores, or custom bespoke glue between an agent and its tools. The practical effect on a production deployment is immediate - a remote MCP server that previously needed sticky sessions and a shared session store can now run behind a plain round-robin load balancer. That is genuinely good news. It also clarifies what the remaining hard problem actually is.
The remaining hard problem is not the plumbing. It is trust.
What MCP and A2A actually do (and where the line is)
Where MCP addresses an agent's interaction with its environment - data and tools - A2A targets a different challenge: enabling communication and coordination among the agents themselves. The cleanest way to hold this in your head: A2A is designed as a complement to MCP, not a replacement - if MCP is the "wrench" for tool access, A2A is the "mechanics' dialogue."
In a real multi-agent system, the architecture layers them: MCP standardises the agent-tool (vertical) interface; A2A standardises the agent-agent (horizontal) interface, and the common deployment pattern is an orchestrator agent that delegates subtasks via A2A while invoking tools via MCP.
Multi-agent systems are harder to debug, more expensive to run, and slower to respond
- so the "use both" answer only makes sense when there's a genuine reason for agent autonomy and specialization. Use MCP for tool access and evaluate A2A for coordination if agents span different trust domains or teams. For tightly-coupled intra-service workflows, your framework's native orchestration may be sufficient - you don't need A2A to delegate work between services in the same deployment.
Here is a concrete version of the split:
| Layer | Protocol | Problem solved | State model |
|---|---|---|---|
| Agent → tool | MCP 2026-07-28 | Standardised tool/data access | Stateless (as of July 28) |
| Agent → agent | A2A v1.0.1 | Capability discovery, task delegation | Task lifecycle with states |
| Agent → commerce | ACP / UCP | Payment, fulfilment semantics | Out of scope for both above |
A complete enterprise agent stack in 2026 uses MCP for tool access, A2A for agent coordination, and ACP or UCP for commerce transactions depending on the environment. That layering is not in dispute. The debate that actually matters starts one layer up.
The governance gap both protocols leave open
Agent interoperability protocols - MCP, A2A, ACP, and others - have rapidly matured to enable identity, capability discovery, tool access, and message exchange between autonomous agents. However, as enterprises deploy heterogeneous agent fleets that must make collective decisions under governance constraints, a question arises: can these protocols support governed agent communities, or only task-oriented coordination?
A June 2026 paper from arXiv (2606.31498) ran a gap analysis across all five major protocols against a six-dimension governance taxonomy. The resulting gap matrix reveals that voting and dissent preservation are universally absent across all five protocols. Deliberation fares no better. Current protocols can transport governance messages as opaque payloads via A2A task messages or MCP tool calls, but cannot interpret, validate, or enforce their governance semantics - and that difference matters, because protocol-native governance enables interoperable tooling, standard audit formats, and composable governance rules without per-application reimplementation.
The trust gap is sharper than the governance gap, and it shows up faster in production. A 2025 paper analyzing trust models across A2A and related protocols identifies six trust mechanisms. The gap between "Claim" and "Proof" remains the most pressing near-term concern: signed Agent Cards prove that a card was issued by the domain owner; they do not prove that the agent is behaving within the claimed scope during execution. Bridging this gap requires runtime attestation mechanisms that do not yet exist in the standard.
To put that practically: your orchestrator agent discovers a specialist agent via its Agent Card, confirms the card is cryptographically signed, and delegates a task. The card says the specialist handles "read-only data enrichment." Nothing in A2A v1.0.1 prevents that agent from writing - or from passing your data to a third endpoint. The protocol delivered the task. The governance is still on you.
Beagle in action#ops-agents, 2:47pmThe steelman case for "the protocols are enough"
It is worth being fair to the other side. The governance gaps are real, but they are also known and on the roadmap. A2A v1.0.1, released in May 2026, introduced an extension mechanism supporting "new data, requirements, RPC methods, and state machines." The extension path exists precisely so governance primitives can be added without rewriting the core. MCP's new extensions framework gives developers a formal path to add capabilities like interactive UIs and long-running work without changing the core protocol
- the same mechanism could carry audit or consent semantics.
The institutional alignment also matters more than it looks. Both MCP and A2A are now under the Linux Foundation's Agentic AI Foundation, launched in December 2025 with six co-founders: OpenAI, Anthropic, Google, Microsoft, AWS, and Block. When the people writing the specs are also the people running the largest agent deployments, roadmap items tend to land. The most important structural shift in early 2026 is not a new protocol - it is governance convergence.
The steelman, in full: the protocols were never designed to carry governance semantics in v1. They were designed to get task routing right first. Governance is being added in the right order: nail the plumbing, then constrain it.
That argument is reasonable. It does not change the operational reality for teams deploying today.
What to actually build on right now
For teams building production multi-agent systems today, the pragmatic path is to adopt A2A for agent-to-agent communication - it has the broadest tooling, the most enterprise integration support, and the most active governance - while treating the security gaps as engineering constraints to be managed at the application layer until the specification catches up.
Concretely, that means three things before you expand your agent count:
- Log at the task boundary, not just the model level. A2A task IDs give you the handle; wire them into whatever observability stack you run so you can replay what any agent did, not just what a model returned.
- Scope Agent Cards tightly and verify them. An unsigned card from a third-party agent is a trust assumption that is easy to overlook and consequential to get wrong. Signed cards are on the recommended path for production. Treat unsigned ones from external sources the way you'd treat an unsigned OAuth token.
- Do not use A2A for intra-service delegation you control end to end. If you need tight coupling between agent components with shared memory and context, A2A's opacity model will work against you - consider an agent framework's native multi-agent patterns instead.
The MCP and A2A question is mostly answered. The question neither protocol answers - who is accountable when an autonomous agent acts outside its intended scope - is the one worth putting engineering hours into now.
MCP and A2A multi-agent protocols: common questions
What is the difference between MCP and A2A?
MCP standardises how an agent connects to tools and data sources - it is the vertical interface between an agent and its environment. A2A standardises how one agent communicates with and delegates work to another agent - the horizontal interface. A production multi-agent system uses both: MCP for tool access underneath, A2A for orchestration across agents.
Do I need both MCP and A2A to build a multi-agent system?
Not always. If your agents run in the same deployment and share context tightly, your orchestration framework's native patterns (LangGraph, OpenAI Agents handoffs) may be sufficient. Add A2A when agents span different trust domains, teams, or vendor stacks - that is when the standardised discovery and task lifecycle earn their overhead.
What changed in the MCP 2026-07-28 spec?
MCP 2026-07-28 is one of the most significant spec releases to date: it moves from a bidirectional stateful protocol to a request/response model, so servers can now deploy on serverless and edge infrastructure. The initialize handshake and session ID header are removed. All four Tier-1 SDKs shipped support on publication day.
Can A2A be trusted for cross-organisation agent delegation?
With caveats. A2A's hardest problems are not syntax or specification problems - they are trust problems that emerge when you actually deploy autonomous agents across organisational or system boundaries. Signed Agent Cards handle identity at handshake time; runtime attestation - proof that an agent behaved within its declared scope during execution - is not yet in the standard.
Who governs MCP and A2A?
MCP is the universal interface for model-to-tool communication and A2A is the standard for agent collaboration. Both are open-source, both are JSON-RPC, and both are governed under the Linux Foundation via the Agentic AI Foundation (AAIF), co-founded by OpenAI, Anthropic, Google, Microsoft, AWS, and Block in December 2025.