# MCP + A2A: You're Building Two Integration Layers Whether You Realise It or Not

> Source: <https://dev.to/icentric/mcp-a2a-youre-building-two-integration-layers-whether-you-realise-it-or-not-1578>
> Published: 2026-06-29 09:05:26+00:00

If you're building agentic systems in 2025, chances are you've already got two integration layers in your stack:

They're not competing. They're complementary. But without a clear interoperability story, you're setting yourself up for the kind of integration spaghetti that kept enterprise architects busy (and miserable) in the ESB era.

MCP is Anthropic's answer to a simple problem: how do you give an LLM structured, reliable access to external resources without writing bespoke glue code for every data source?

Instead of hardcoding database queries or API calls into your prompts, you expose them as **MCP servers**. Your AI client connects via a standard protocol, discovers available tools, and invokes them with typed parameters.

**Example use case:**

``` python
# MCP server exposes a tool
@mcp_tool
def query_customer_orders(customer_id: str) -> list[Order]:
    return db.execute("SELECT * FROM orders WHERE customer_id = ?", customer_id)
```

Your LLM can now call `query_customer_orders`

as a function — no prompt engineering, no brittle scraping, no hoping the model "figures it out".

MCP is **vertical integration**: connecting one agent to the resources it needs to do its job.

A2A is horizontal. It's about agents talking to *other agents*.

Imagine you've got:

When a customer asks "Where's my refund?", the support agent needs to talk to billing. That's A2A.

A2A protocols define:

Unlike MCP, A2A is still fragmented. There's no single standard. You might be using:

Each works. None interoperate cleanly.

If you worked in enterprise integration in the 2000s, this smells like **ESB déjà vu**.

The Enterprise Service Bus promised to solve the n-squared integration problem: instead of every system talking directly to every other system, route everything through a central bus.

It worked — until it didn't. ESBs became:

The [two-layer stack](https://www.icentricagency.com/insights/mcp-a2a-the-two-layer-stack-wiring-the-internet-of-agents-1) emerging now — MCP below, A2A above — risks the same fate if we're not careful.

MCP is brilliant for standardising resource access. Don't abuse it by cramming business logic into MCP tools. Keep them thin, composable, and stateless.

Don't mix pub/sub and RPC in the same workflow unless you have a damn good reason. Consistency beats flexibility when debugging multi-agent failures at 2am.

Whatever A2A framework you choose today will probably be legacy in 18 months. Wrap it. Abstract it. Make it swappable.

**Example:**

``` php
class AgentInvoker(Protocol):
    def invoke(self, agent_id: str, task: dict) -> dict:
        ...

class KafkaAgentInvoker(AgentInvoker):
    # Implementation today

class GrpcAgentInvoker(AgentInvoker):
    # Swap in tomorrow
```

MCP failures look different to A2A failures:

Your observability stack needs to distinguish them.

There's no silver bullet yet. MCP is maturing fast, but A2A is still the Wild West. If you're building production agentic systems — especially in regulated industries or at scale — treat this as an **architecture risk**, not just a tooling choice.

You don't need to freeze development. But you *do* need to:

The teams that get this right won't be the ones with the cleverest agents. They'll be the ones who can rewire them without a full rewrite.

If you're evaluating MCP, A2A, or any other part of the agentic stack and want a second opinion, teams specialising in [AI automation and software development](https://www.icentricagency.com) can help you de-risk the architecture before you're too deep to reverse course.

But honestly? Just don't build another ESB. We've been there. It wasn't fun.