MCP, A2A and AG-UI: The Three Protocols That Matter

Agent architecture spent its first couple of years as bespoke glue. Every team wrote its own way of exposing tools to a model, its own scheme for one agent to call another, and its own protocol for getting intermediate output onto a screen. None of it was portable.

That has changed quickly, and there are now three open protocols covering the three connections an agent actually needs. They are complementary rather than competing, and it is worth knowing which is which before choosing anything.

MCP — the agent to its tools

The Model Context Protocol standardises how a model reaches a database, an internal API, a file store, a payment system. It is the vertical connection: agent down to capability.

Anthropic published it and then donated it, in December 2025, to the Agentic AI Foundation — a Linux Foundation directed fund set up with Block and OpenAI. That matters practically rather than politically: it is now community-governed with a formal proposal process, so building against it is no longer a bet on one vendor's roadmap.

The useful property is that an MCP server is written once and works with any client that speaks the protocol. If your organisation exposes its order system as an MCP server, every agent you build afterwards — and every agent your vendors build — connects to it the same way, with the same permissions model, rather than through a bespoke integration per project.

This is also the cleanest route for retrofitting agentic capability onto systems that already exist. Wrapping a running application's existing APIs as a skill layer is a far smaller undertaking than rebuilding it, and it leaves the live system undisturbed.

A2A — agents to each other

Agent2Agent covers the horizontal connection: one agent handing work to another without either exposing its internals. A planning agent delegates to a billing agent; the billing agent does not need to know what the planner is, and the planner does not need to know how billing works.

Google transferred it to the Linux Foundation in June 2025, and it reached version 1.0 in April 2026. It now has more than 150 participating organisations and is integrated into the AWS, Microsoft and Google cloud platforms, which in practice makes it the default for inter-agent communication in enterprise settings. The earlier ACP effort folded into it during 2025, so the fragmentation people worried about did not materialise.

Where this becomes relevant is at organisational boundaries. Agents built by different teams, on different frameworks, or by different suppliers, can interoperate without a shared codebase — which is the actual constraint in a large enterprise, where no single team owns everything the workflow touches.

AG-UI — the agent to the person

The third connection is the one most often hand-rolled: getting an agent's work onto a screen while it is still happening.

AG-UI is an open, event-based protocol for exactly that, developed out of CopilotKit's work with LangChain and CrewAI. It sits on HTTP and WebSockets and describes an event stream rather than a rendering target, so the same backend can drive a web app, a mobile client, a terminal or a chat platform.

The reason it exists is that request-response does not describe what an agent does. An agent runs for a long time, streams partial output, changes its mind, calls tools, needs to interrupt and ask a person something, and produces a mix of text, structured state and UI instructions. Modelling that as a series of REST calls produces the fragile, bespoke plumbing most teams have written at least once.

What the protocol standardises is the awkward part: streaming with cancellation and resumption, multimodal attachments, generative UI, shared state with conflict resolution, tool calls originating from either end, human-in-the-loop interrupts, and sub-agent composition. It has integrations across more than twenty frameworks, including first-party support from Microsoft Agent Framework, Google ADK and AWS Strands.

How they fit together

A useful shorthand: MCP is what an agent uses, A2A is who an agent talks to, AG-UI is how a person sees it.

They compose. A customer-facing agent might expose its progress over AG-UI, delegate a specialist sub-task over A2A, and reach your ERP over MCP — three protocols, three different problems, no overlap.

What this means if you are commissioning work

The practical consequence is that "how will this integrate" has a better answer than it did eighteen months ago, and it is worth asking explicitly.

An agent built against these protocols is portable. The tool layer survives a change of framework. The sub-agent boundary survives a change of supplier. The interface survives a change of front end. An agent built on bespoke glue is a rewrite each time any of those changes, and all of them change.

That is the question worth putting to anyone proposing an agent build: which of these three connections are you standardising, and which are you writing by hand — and if by hand, why.