Skip to main content
Back to blog
AI2026·07·277 min read

The Standard After MCP: Why Agents Now Need to Talk to Each Other

The Model Context Protocol answered one question well: how does a single agent reach the tools and data it needs? It said nothing about the question that shows up the moment you deploy a second agent — how do agents find, trust, and delegate work to each other? A2A, the Agent2Agent protocol, is the emerging answer, and it is the standard people mean when they talk about what comes after MCP.

MCP solved the vertical problem

MCP is the "USB-C port for AI applications" — a uniform way for a model to call tools, read files, query databases, and pull in context. It is deservedly everywhere now, because before it every integration between an agent and a data source was bespoke glue. MCP made that glue standard. If your problem is "give this one agent access to these systems," MCP is the answer and you do not need anything else.

But MCP is a vertical protocol: it points downward, from an agent to its tools. It has nothing to say about the horizontal direction — one autonomous agent handing a task to another autonomous agent that it did not build, does not host, and cannot see inside. As soon as your architecture has more than one agent, and especially once those agents come from different teams or different vendors, you hit a gap MCP was never designed to fill.

What A2A actually is

A2A (Agent2Agent) is an open protocol introduced by Google in 2025 and since donated to the Linux Foundation, with a broad set of vendors backing it. Its job is to let independent, opaque agents collaborate over a standard wire format without exposing their internal tools, prompts, or memory to each other. One agent acts as a client, another as a remote agent, and they exchange work through a small, well-defined vocabulary.

The building blocks are deliberately simple. An Agent Card is a JSON document — typically served at a well-known URL — that advertises an agent's identity, skills, endpoint, and authentication requirements, so other agents can discover what it can do before calling it. A Task is the unit of work, with an explicit lifecycle (submitted, working, input-required, completed, failed) so long-running jobs are first-class rather than a timeout waiting to happen. Messages carry Parts (text, files, structured data), and finished work comes back as Artifacts. It runs over ordinary HTTP with JSON-RPC, supports streaming for incremental results and push notifications for work that outlives a single request, and treats enterprise authentication as a requirement rather than an afterthought.

MCP and A2A are not competitors

This is the point most of the "MCP is dead" takes get wrong. The two protocols operate on different axes and compose cleanly. MCP connects an agent down to its tools; A2A connects an agent sideways to its peers. A useful mental model: MCP is how an agent picks up a wrench, and A2A is how it hires a plumber whose wrenches it will never see.

In a real system you use both. A travel-planning agent might use MCP to read a user's calendar and query a pricing API, then use A2A to delegate "book and pay for this itinerary" to a specialized booking agent operated by someone else entirely. The booking agent runs its own tools over its own MCP connections; the planner never sees them. That opacity is a feature — it is what lets agents from different organizations cooperate without collapsing into one giant, tightly coupled application.

Why this matters if you are building now

The alternative to a shared agent-to-agent standard is the same mess MCP already rescued us from, one level up: every pair of agents needs a custom integration, and the cost grows with the square of how many agents you run. A standard collapses that back to linear. It also unlocks capability discovery — an agent can read another's Agent Card and decide at runtime whether it is the right one for a task — instead of every collaboration being wired by hand in advance.

There is a security dimension too, and it is the one we spend the most time on with customers. The moment an agent can delegate to agents outside your trust boundary, "which agent am I actually talking to, and what am I authorized to ask it" becomes a live question. A2A puts identity and auth in the protocol, but a protocol only gives you the hooks — you still have to decide which remote agents you trust, scope what you will delegate, and log every cross-agent task the way you would log any other privileged action.

Where we would place our bets

A2A is the front-runner, but the space is still moving. IBM's Agent Communication Protocol has largely converged toward it, Cisco-led AGNTCY is tackling agent identity and discovery at internet scale, and protocols like AG-UI address the separate agent-to-user-interface layer. Betting the whole architecture on any single spec today would be premature.

Our advice to teams is unglamorous and durable: build tool access on MCP now, because that standard has already won its layer. Keep your agent boundaries clean and your agents genuinely opaque — no shared memory, no reaching into each other's internals — so that whichever agent-to-agent standard wins, adopting it is a thin adapter rather than a rewrite. And treat every cross-agent call as a privileged, audited action from day one. That is how you get the upside of an interoperable agent ecosystem without betting your production system on a protocol war that has not finished yet. It is the same work we do with customers running managed-agent fleets today — and it is the natural next chapter after locking down a single agent.

Keep reading

Related articles

AI8 min read

Getting Started with RAG: A Practical Guide

Learn how to build a Retrieval-Augmented Generation system from scratch using modern LLM tools.

Read more
Security9 min read

Securing OpenClaw and NemoClaw: An Audit Playbook for Managed Agents

How we help customers lock down their OpenClaw instances, run security and safety checks against NemoClaw and other managed agents, and audit the whole fleet.

Read more
Development6 min read

TanStack Start vs Next.js: When to Choose What

A comparison of two popular React meta-frameworks and when each makes sense for your project.

Read more