Something quietly significant is happening in enterprise architecture right now. Across UK technology teams, a two-layer pattern is emerging for agentic AI systems: the Model Context Protocol (MCP) handling deep, structured integration with tools and data sources, and Agent-to-Agent (A2A) communication layered on top to orchestrate how autonomous agents collaborate. On the surface, this looks like pragmatic engineering — pick the right abstraction for each layer and compose them. In practice, it is an architectural bet being made under considerable time pressure, without a settled interoperability standard binding the layers together. The consequences of getting this wrong are not hypothetical. They are the same consequences that plagued Enterprise Service Bus deployments two decades ago: tightly coupled, brittle coordination logic that becomes expensive to unpick.
For senior decision-makers and technical leads, the question is not whether MCP and A2A are individually valuable — they are. The question is whether the way they are being combined today will look sensible in three years, or whether it will represent a category of technical debt that is harder to resolve than the original integration problems it was meant to solve.
What MCP and A2A Actually Do — and Why They Are Not Substitutes
MCP, originally developed by Anthropic, is a standardised protocol for giving AI models structured access to external tools, APIs, and data sources. Think of it as a disciplined contract between a model and its environment: a CRM, a codebase, a proprietary internal API. It defines how context is passed, how tool calls are made, and how responses are returned. For organisations with complex internal systems, MCP offers something genuinely useful — a way to wire AI agents into existing infrastructure without bespoke glue code for every integration.
A2A, by contrast, operates at a higher level of abstraction. It is concerned with how agents communicate with and delegate to one another — how an orchestrating agent hands off a subtask to a specialised agent, how results are returned, how failures are surfaced. Google's A2A proposal, released earlier this year, formalised many of the patterns that teams had already been implementing ad hoc. The distinction matters: MCP is about an agent's relationship with tools; A2A is about the relationship between agents. They are complementary, not competing — but that complementarity is precisely what makes the integration point between them architecturally consequential.
The ESB Parallel — and Why It Should Give Architects Pause
In the early 2000s, the Enterprise Service Bus promised to solve the n-squared integration problem: instead of every system talking directly to every other system, all communication would route through a central, standards-based bus. The idea was sound. The execution, over time, became a cautionary tale. ESBs accumulated routing logic, transformation rules, and orchestration flows that were deeply coupled to the specific versions of the systems they connected. When those systems changed, the bus became the bottleneck. When vendors diverged on standards, the interoperability guarantees eroded. Teams ended up maintaining the integration layer as a parallel codebase — one that no single team owned clearly and that nobody wanted to refactor.
The emerging MCP-plus-A2A stack carries structural echoes of this pattern. Right now, the translation layer between MCP tool outputs and A2A agent messaging is typically handled by custom middleware or bespoke orchestration code written by the team building the system. There is no settled standard governing how MCP context is serialised, routed, or transformed when it crosses into an A2A interaction. Each team is making its own choices — and those choices are accumulating. If the protocol landscape stabilises and these layers converge on a shared contract, much of this custom code becomes redundant. If the protocols diverge, or if a third standard emerges, teams will find themselves maintaining a translation layer of considerable complexity, with no obvious path to simplification.
Where UK Agencies Are Making the Bet Right Now
In conversations with teams building production agentic systems in the UK, a consistent pattern is visible. MCP adoption is being driven from the bottom up, by engineers who need reliable, auditable access to internal tools — legal document repositories, engineering codebases, CRM and ERP systems. The protocol's structured approach to tool calling fits naturally into existing API governance frameworks, and its growing ecosystem of connectors reduces integration effort. For these teams, MCP is not a speculative investment; it is solving a live problem.
A2A adoption is coming from the top down, driven by the recognition that single-agent systems hit capability ceilings quickly. Complex workflows — customer onboarding, software delivery pipelines, compliance monitoring — require specialist agents working in coordination. The appeal of A2A is the promise of composability: build specialised agents once, orchestrate them as needed. The gap between these two adoption vectors is where the architectural risk concentrates. Teams are writing glue code today that will define the shape of their agent infrastructure for years. Few are treating that glue code with the same rigour they would apply to a core service interface — because it does not feel like core infrastructure yet. By the time it does, it will be.
What a More Defensible Architecture Looks Like
The absence of a settled interoperability standard is not a reason to pause all agentic development — that would be neither practical nor commercially sensible. It is, however, a reason to be deliberate about where you introduce coupling. Teams that fare best in periods of protocol uncertainty tend to apply the same discipline they would to any integration boundary: define explicit contracts at the MCP-to-A2A translation point, version those contracts, and treat the translation layer as a first-class component rather than scaffolding.
Concretely, this means documenting the schema that agent outputs must conform to before they cross into MCP tool calls, and the reverse. It means building observability into the seam between layers so that failures are attributable and traceable. And it means resisting the temptation to push business logic into the coordination layer — a mistake that plagued ESB deployments and that is already visible in some early agentic architectures. The teams that treat this integration point as infrastructure from the outset will be significantly better positioned to migrate when — not if — the protocol landscape shifts.
The internet of agents is being wired right now, and the decisions being made in the next twelve to eighteen months will shape enterprise AI infrastructure for the better part of a decade. MCP and A2A are both credible, valuable protocols — but stacking them without a clear integration contract is a form of optimism that the 2000s ESB experience does not fully support. For UK organisations building serious agentic capability, the practical imperative is to treat the seam between these two layers with the same architectural seriousness as any other critical integration boundary.
If you are currently designing or reviewing an agentic system architecture and the MCP-to-A2A translation layer is still informal, undocumented, or owned by nobody in particular, that is the right place to focus attention. Not because the protocols will necessarily diverge — they may well converge — but because the cost of explicit contracts now is low, and the cost of unpicking implicit coupling later is not.
Is MCP an open standard, or is it controlled by Anthropic?
MCP was originally developed and released by Anthropic, but it is published as an open specification and has attracted contributions and implementations from multiple vendors and open-source projects. That said, Anthropic retains significant influence over its direction, which is a governance consideration worth factoring into long-term architectural decisions.
Is Google's A2A proposal the only agent-to-agent communication standard being developed?
No. Several approaches to agent orchestration and inter-agent communication are in active development, including efforts from Microsoft, OpenAI, and various open-source communities. Google's A2A specification is one of the more formally documented proposals, but the landscape has not yet consolidated around a single standard, which is central to the architectural risk described in this article.
Can we use MCP without A2A, or vice versa, in a production agentic system?
Yes. MCP can be used independently for single-agent systems that need structured tool access, and many production deployments do exactly this. A2A patterns can also be implemented without MCP by using other tool integration approaches. The two-layer stack becomes relevant when you need both deep tool integration and multi-agent coordination simultaneously.
How is the MCP-plus-A2A stack different from traditional microservices orchestration?
Traditional microservices orchestration operates on deterministic, predefined workflows where each service does what it is told. Agentic systems introduce non-determinism: agents reason about what to do next, which means the coordination layer must handle emergent behaviour, partial failures, and mid-task replanning in ways that conventional orchestration frameworks were not designed for. This makes the integration boundaries between layers more consequential.
What does 'coordination debt' mean in the context of agentic systems?
Coordination debt refers to the accumulating cost of informal, undocumented, or tightly coupled logic that governs how agents communicate and hand off work to one another. Like technical debt in codebases, it is often invisible until a system needs to change — at which point the effort required to refactor the coordination logic can exceed the original build cost. It is analogous to the routing and transformation logic that became unmaintainable in ESB deployments.
How should we handle versioning when both MCP and A2A protocols are still evolving?
The most defensible approach is to version the contracts at the translation boundary between your MCP and A2A layers explicitly and independently of the underlying protocol versions. This means your internal interfaces can remain stable even if the external protocols update, provided you absorb protocol changes at the adapter layer. Treating the translation component as a versioned, independently deployable service makes this significantly easier.
Are there tools or frameworks that handle MCP-to-A2A integration without custom glue code?
As of now, purpose-built tooling for MCP-to-A2A integration is limited and largely experimental. Some orchestration frameworks such as LangGraph and CrewAI provide partial bridges, but they impose their own abstractions and constraints. Most production teams are currently writing custom integration logic, which is precisely the risk the article highlights — this custom code is not yet being treated with the rigour it warrants.
What governance considerations should UK organisations apply to agentic system architectures?
UK organisations should consider data residency and processing obligations under UK GDPR when agents access internal systems via MCP, particularly if cloud-hosted models are involved. Beyond compliance, governance should address auditability — can you trace which agent took which action via which tool call? — and accountability, meaning clear ownership of the coordination layer and its failure modes. These governance questions become harder to answer retrospectively once the architecture is in production.
How do we assess whether our current agentic architecture is accumulating coordination debt?
Key indicators include: orchestration logic embedded directly in agent prompts rather than in a dedicated coordination layer; no documented schema or contract at the point where agent outputs become tool inputs; inability to attribute a system failure to a specific agent or integration component; and coordination code owned informally across multiple teams. If three or more of these apply, coordination debt is likely already accumulating.
When might a single-protocol approach become viable, eliminating the need for a two-layer stack?
Protocol consolidation typically follows a period of competitive experimentation — similar to what occurred with messaging protocols and later with API standards. It is plausible that MCP and A2A converge, or that a third protocol emerges that addresses both tool integration and agent coordination within a single specification. Most analysts expect this to take at least two to three years, meaning teams building production systems today should design for protocol migration rather than assuming stability.
Get in touch today
Book a call at a time to suit you, or fill out our enquiry form or get in touch using the contact details below