MCP + A2A: The Two-Layer Stack Wiring the Internet of Agents

Something significant is crystallising in enterprise AI architecture, and it is happening faster than most UK development teams have had time to notice. Two protocols — Anthropic's Model Context Protocol (MCP) and Google's Agent-to-Agent protocol (A2A) — are emerging as the foundational plumbing of what many are calling the 'Internet of Agents': a world in which autonomous software agents don't just answer questions but negotiate, delegate, and collaborate across organisational and system boundaries. The engineering story is not about choosing one over the other. It is about understanding that they solve entirely different problems, and that serious multi-agent architectures will require both.

The window for UK organisations to shape how they implement this stack is narrowing. De facto patterns are forming rapidly, and they are forming primarily around US-centric tooling, cloud infrastructure, and governance assumptions. Teams that wait for the dust to settle will inherit an architecture designed for someone else's constraints.

The Clean Division of Responsibility

The conceptual clarity here is actually elegant once you see it. MCP handles the vertical pipe: it standardises how an individual agent connects downward to tools, APIs, data sources, and external services. Think of it as the plug-and-socket standard that lets any MCP-compatible agent consume any MCP-compatible resource without bespoke integration work. An agent querying a CRM, executing a database lookup, or invoking a REST API does all of that through MCP. The protocol defines how context is passed, how tools are described, and how results flow back up to the agent's reasoning layer.

A2A, by contrast, handles the horizontal handshake. It defines how one autonomous agent speaks to another — how it advertises its capabilities, how it receives task delegations, how it signals progress or failure, and how it negotiates scope. Where MCP is about an agent and its instruments, A2A is about agents and their peers. A workforce automation system might use MCP to let each specialist agent call the tools it needs, while using A2A to let a coordinating orchestrator agent assign work, monitor outcomes, and re-route tasks when one agent hits a capability boundary. These are genuinely distinct concerns, and conflating them leads to architectures that are brittle by design.

Why the Timing Matters for UK Engineering Teams

Google's A2A specification gained significant traction in the first half of this year, with major cloud vendors and AI framework maintainers moving to support it. Alongside Anthropic's MCP — which had already achieved broad adoption across developer tooling — the two protocols together represent a convergence point that the industry has been edging towards for some time. The danger for organisations that are not paying close attention is that architectural decisions made in the next few months will be difficult and expensive to undo.

UK teams face a specific set of complications that their US counterparts do not. Data residency obligations under UK GDPR, sector-specific regulatory frameworks in financial services and healthcare, and the practical reality of hybrid cloud environments mean that the default implementation patterns emerging from Silicon Valley labs will not map cleanly onto British enterprise infrastructure. An A2A deployment that assumes all agent communication flows through a US-hosted orchestration layer is not merely a performance inconvenience — it may be a compliance problem. Teams that architect for both protocols now, with UK regulatory context baked in, will be far better positioned than those who retrofit compliance onto a borrowed pattern later.

Practical Architecture Considerations

When designing a multi-agent system against this two-layer stack, the key discipline is resisting the temptation to solve A2A problems with MCP and vice versa. A common early mistake is using MCP tool calls to simulate agent-to-agent communication — essentially tunnelling A2A semantics through a vertical pipe that was not designed for them. This produces systems that work in demos but fail under load, because the context management assumptions in MCP are not suited to the stateful, asynchronous nature of real agent collaboration. Similarly, using A2A for what is fundamentally a tool invocation — because it feels more 'agentic' — adds unnecessary overhead and obscures the system's actual dependency graph.

Practically, the right approach is to define agent boundaries explicitly before writing any protocol-level code. Each agent should have a clear capability surface that it exposes via A2A and a clear set of tool dependencies that it satisfies via MCP. Capability discovery — the mechanism by which agents find and evaluate potential collaborators — deserves particular attention, because it is the layer most likely to encode organisational assumptions that become hard to change. UK teams should also think carefully about observability: logging, tracing, and audit trails across both protocol layers are not optional extras but architectural requirements, especially in regulated industries.

The Governance and Interoperability Picture

Neither MCP nor A2A is currently governed by a neutral standards body, which creates a genuine risk for enterprise adopters. Both specifications are steered by commercial entities with their own platform interests, and the version histories of both protocols already show how quickly the specifications can shift. For UK organisations, particularly those in the public sector or critical national infrastructure, this is a procurement and risk management question as much as a technical one. Vendor lock-in at the protocol layer is qualitatively different from lock-in at the application layer — it is harder to see, harder to quantify, and significantly harder to escape.

The more constructive framing, however, is that both protocols are open enough that a well-architected system can treat them as interchangeable layers rather than permanent commitments. Building abstraction layers around your MCP tool registry and your A2A agent directory — rather than coupling application logic directly to protocol primitives — gives you the flexibility to migrate or fork if the specifications diverge in ways that do not serve your needs. This is not theoretical caution; it is basic engineering hygiene for any dependency that sits beneath your core business logic.

The organisations that will build the most resilient multi-agent systems are not those that move fastest, but those that move with the clearest architectural intent. Understanding that MCP and A2A occupy different layers — and that both layers matter — is the starting point. From there, the work is familiar: define your agent boundaries, choose your observability strategy, stress-test your assumptions against your regulatory context, and build abstraction where the specifications touch your core systems.

If your team is beginning to design multi-agent workflows and has not yet mapped your architecture against both protocol layers, now is the right moment to do that work. The patterns calcifying around this stack will shape enterprise AI infrastructure for years. UK organisations that engage with them deliberately, rather than inheriting them by default, will have a meaningful advantage — both technically and commercially. iCentric works with UK development teams on exactly these architectural decisions; if this is a conversation worth having, we would be glad to have it.