MCP, A2A, and the Protocol Layer for Enterprise Agents

MCP, A2A, and the protocol layer for enterprise agents

I've started using a shorthand test when I'm talking to someone about agentic AI. I ask them to explain the difference between MCP and A2A. If they blur the two together, or wave vaguely at "agent protocols," they haven't built anything yet. That's fine -- most people haven't. But the distinction matters if you're actually running these systems.

MCP (Model Context Protocol, originally Anthropic's, now donated to the Linux Foundation) is agent-to-tool. It standardises how an agent calls external capabilities: query a database, hit an API, pull a document from a vector store. A2A (Agent-to-Agent, from Google) is agent-to-agent. It defines how agents find each other, negotiate tasks, and hand off work. These are different problems. Mixing them up is like confusing HTTP with service mesh -- one moves data between a client and a server, the other coordinates services talking to each other.

Why this matters if you run engineering teams

Before MCP, every agent-to-tool integration was bespoke. You wanted your LangGraph agent to query Postgres via pgvector? Custom tool function. Also call Jira's API? Another custom function, different argument schema, different auth, different error handling. Multiply that across a dozen tools and you have a maintenance problem that scales linearly with ambition.

MCP fixes this. Standard protocol for tool discovery and invocation. The agent speaks MCP, the tool server speaks MCP, they work it out. By February 2026, MCP SDKs had crossed 97 million monthly downloads (per The Register's January 2026 protocols piece). That number isn't driven by hype. It's driven by teams who got tired of writing glue code.

A2A is earlier in its lifecycle but solving an equally real problem. When you have multiple agents -- a planner, a coder, a reviewer -- they need a way to hand off work that isn't "shove the whole context into the next prompt." A2A gives agents a way to advertise capabilities, accept or reject tasks, and stream progress back. A contract layer between autonomous systems.

What this looks like running in production

I build on LangGraph with Pydantic for structured outputs and LoRA-tuned models for domain work. Here's how MCP and A2A map onto that.

MCP handles tools. We run MCP servers for database queries (Postgres with pgvector for semantic search), internal APIs, document retrieval, a handful of external services. The agent code doesn't know or care what sits behind each MCP server. When we added a new data source last month, it was a new MCP server and a config change. Zero agent code touched.

A2A is where it gets more interesting and less settled. We run multi agent workflows where a planning agent breaks a task apart, delegates to specialists, and reassembles. That coordination is mostly custom right now -- LangGraph state machines managing hand-offs. A2A would standardise those hand-offs. We're watching it. I'm not putting it in a production path yet. The spec is still moving. Google published it April 2025 and it's been through several revisions since.

The Thoughtworks Technology Radar (Volume 33, November 2025) put MCP in "Trial" -- use it on real projects -- and flagged A2A as one to assess. That lines up with what I've seen. MCP is ready. A2A is promising but I wouldn't bet a production system on it today.

Governance, which nobody talks about enough

This is the thing I keep thinking about. Protocols make audit trails structural. If every tool call goes through MCP, you can log every invocation: what the agent asked for, what came back, how long it took, whether it failed. In regulated industries that isn't optional. DORA requires it. The EU AI Act will require it. The FCA expects it for AI in financial services. You need to show your automated systems are traceable and controllable.

Same applies to A2A. If agent delegation follows a standard protocol, you can trace responsibility. Agent A asked Agent B to do X. Agent B accepted, tried, returned Y. That chain matters when something breaks. Something always breaks.

Without protocols, your audit trail is whatever you remembered to log in your custom code. I've seen a team discover, post-incident, that their agent had made 400 API calls in a loop because nobody instrumented the tool layer. MCP makes that instrumentation structural. You get it by default, not by discipline.

The Linux Foundation launched the Agentic AI Foundation to steward exactly this kind of infrastructure. MCP was one of the first protocols donated. That tells you the industry is treating this as shared plumbing, not a proprietary play.

What I'd actually do

Adopt MCP for tool access now. The SDKs are mature, the community is big, the risk is low. Even if your agent framework already has its own tool-calling abstraction, wrapping tools in MCP gives you portability and a standard logging surface. We did it incrementally -- one MCP server at a time, starting with the tool that broke most often.

Evaluate A2A but keep your options open. If you have multi agent workflows, prototype the A2A agent card pattern and see how it maps to your existing coordination logic. But keep your current orchestration as the primary path. I'd rather carry custom code for another six months than adopt a protocol that changes under me.

Design for both. Separate tool access from agent coordination cleanly in your architecture. Use MCP for tools. Leave a seam where A2A can slot in for agent-to-agent coordination later. Don't wire your planning agent to your specialists through shared memory -- assume they'll eventually talk through a protocol.

And instrument everything from day one. The best thing about protocols is they give you a natural place to hang metrics, logs, and traces. Don't wait for an incident to discover you can't see what your agents are doing at 3am.

The protocol layer for agents is forming right now. Most of the attention goes to the models. But the boring bit -- the contracts, the interfaces, the shared standards -- is what will determine whether enterprise agent deployments are actually governable, or just demos running in production with their fingers crossed.