The Agentic Protocol Stack: How MCP, A2A, A2UI, and AG-UI Fit Together

Four new protocol acronyms in eighteen months, and most engineers still can't explain how they relate to each other. That's not a knowledge gap — it's a documentation failure.

I've had this exact conversation three times in the past month. Each time, a smart engineer asks: "Wait, if we're using A2A, do we still need MCP?" The answer is yes, always yes — and the fact that the question keeps coming up tells you something about how poorly this space is being explained.

MCP, A2A, A2UI, and AG-UI are not competing standards. They don't solve the same problem. They don't even operate at the same layer of the architecture. What looks like a crowded, confusing standards landscape is actually the beginning of a layered interoperability stack — the TCP/IP moment for agentic systems.

This article draws the map. No hype, no winner-takes-all narrative — just the architecture.

TL;DR — The Four-Line Summary

Short on time? Here's the whole thing in a table:

Protocol	Connects	What it solves
MCP	Agent ↔ Tools	Standard way for agents to access tools, files, and data
A2A	Agent ↔ Agent	Agents discover and delegate to other agents across frameworks
A2UI	Agent → UI Host	Agents declare UI structure; host renders it safely
AG-UI	Agent → Frontend	Streams agent activity to your UI in real time

None of them replace REST APIs. All four can — and often should — run in the same system simultaneously.

graph LR
    User([User])
    FE[Frontend App]
    AR[Agent Runtime]
    Tools[Tools and Data]
    Agents[External Agents]
    User --- FE
    FE <-->|AG-UI| AR
    FE <-->|A2UI| AR
    AR <-->|MCP| Tools
    AR <-->|A2A| Agents
    style FE fill:#dbeafe,color:#1e3a8a
    style AR fill:#ede9fe,color:#4c1d95
    style Tools fill:#d1fae5,color:#064e3b
    style Agents fill:#fef3c7,color:#78350f

The rest of this article explains each layer in depth — why it exists, what goes wrong without it, and where the gaps still are.

The Problem: Protocol Fatigue Is Real

In 2023, building an AI application meant choosing a model, writing prompts, and wiring up a REST API. The surface area was manageable. Most teams could hold the whole system in their heads.

By mid-2026, production AI systems involve tool registries, multi-agent coordination, streaming event buses, and declarative UI generation. Teams navigating this landscape are asking reasonable questions:

Does A2A replace MCP? They're both called "agent protocols."
What's the difference between AG-UI and A2UI? Both mention user interfaces.
Do any of these replace REST APIs?
Which one should we actually adopt right now?

The confusion is understandable. These protocols came out of different organisations, at different times, solving genuinely different problems. Nobody sat down and designed the stack top-to-bottom. It's emerging bottom-up, which means the coherent picture has to be assembled from pieces.

Here's that picture.

The Core Four: What Each Protocol Actually Does

MCP (Model Context Protocol) — The "USB-C" of AI Tooling

What it is: MCP was developed by Anthropic and open-sourced in late 2024. It standardises how AI models discover and invoke tools, access data sources, and integrate with local or enterprise resources. The architecture is client-server: an MCP host (your AI application) connects to MCP servers (tool providers) over a standardised interface using JSON-RPC via stdio, SSE, or HTTP.

The analogy: USB-C. Before it, every peripheral needed its own cable. After it, any compliant device connects to any compliant host. MCP does the same for AI tools — any compliant tool provider connects to any compliant AI application, no custom glue code required for every pairing.

In practice: Claude Desktop reading a local filesystem. Cursor querying an internal knowledge base. An enterprise AI assistant pulling from your CRM, code repositories, and ticketing systems — all through the same protocol, none of it requiring a bespoke connector. Build one Postgres MCP server and it works everywhere.

Where people trip up: MCP is about connecting an agent to a tool. The tool responds when called; it doesn't have goals or agency. That distinction matters, because the next protocol — A2A — is for a completely different kind of relationship.

MCP is the most mature of the four here. The spec is stable, TypeScript and Python SDKs are solid, and the server ecosystem has grown substantially. If you're building AI tool integration today, this is where you start.

graph LR
    Host[AI Application\nMCP Host]
    Host <-->|MCP| S1[MCP Server\nFilesystem]
    Host <-->|MCP| S2[MCP Server\nDatabase]
    Host <-->|MCP| S3[MCP Server\nEnterprise API]
    S1 --- FS[(Local Files)]
    S2 --- DB[(Postgres)]
    S3 --- API[REST API]
    style Host fill:#dbeafe,color:#1e3a8a
    style S1 fill:#d1fae5,color:#064e3b
    style S2 fill:#d1fae5,color:#064e3b
    style S3 fill:#d1fae5,color:#064e3b
    style FS fill:#f3f4f6,color:#374151
    style DB fill:#f3f4f6,color:#374151
    style API fill:#f3f4f6,color:#374151

A2A (Agent-to-Agent) — The B2B Network for AI

What it is: A2A was published by Google, with involvement from several cloud and enterprise partners. It enables autonomous agents — built on different frameworks, running on different infrastructure — to discover each other, delegate tasks, and coordinate on long-running work. Agents publish an "Agent Card": a machine-readable capability profile. Communication is via JSON-RPC over HTTP, with SSE for streaming status updates.

The analogy: An automated business supply chain. A manufacturer doesn't ring each supplier manually — they publish requirements, discover registered partners, and exchange work orders through standard formats. A2A does this for agents: capability advertisement, task delegation, and status tracking across organisational and framework boundaries.

In practice: A travel-planning agent discovers an airline booking agent through its published Agent Card. It delegates ticket search and purchase as a long-running task. The booking agent sends structured status updates as it works through fare lookups and payment. No shared codebase. No human coordinator in the middle.

Why this isn't just "a fancier API call": Both sides are autonomous. Both have internal state, goals, and their own constraints. A2A is designed for genuine agent-to-agent coordination across trust boundaries — not just "call this function, get a response back."

A2A is gaining real attention across cloud and enterprise communities. Several major platforms have announced A2A-compatible agents. Broad production adoption is still early as of mid-2026, but the direction is clear enough to start evaluating now.

sequenceDiagram
    participant OA as Your Agent
    participant AC as Agent Card Registry
    participant BA as Booking Agent
    OA->>AC: who handles flight bookings?
    AC-->>OA: BookingAgent (runs on any framework)
    OA->>BA: delegate: book LHR to BOM, 21 June
    BA-->>OA: working on it...
    BA-->>OA: done — booking confirmed, PNR XYZ123

A2UI (Agent-to-User Interface) — The Declarative Menu

What it is: A2UI tackles a specific problem: how do agents communicate about user interfaces without transmitting executable code? Rather than an agent generating and injecting arbitrary HTML or JavaScript, an A2UI-style agent declares structured UI intent — "I need the user to pick a date range" or "present these three options for approval" — and the host application renders it using its own components.

The analogy: A restaurant menu. It describes what's available, in a standard format. The kitchen, staff, and design language handle preparation and delivery. The menu doesn't contain recipes. It separates what is available from how it's made.

In practice: An agent handling an expense approval workflow declares a structured form spec. The host application renders it as a native UI with the organisation's design system, accessibility setup, and permission model intact. The agent describes the intent; the application handles the rendering.

The honest caveat: A2UI as a formal protocol spec is the most nascent of the four. The concepts are sound — I've seen teams independently arrive at exactly this pattern once they get burned by agents injecting arbitrary frontend code — and several frameworks are converging here. But a single authoritative standard is still forming. Teams implementing this today are generally working from their own schema conventions.

graph TD
    AR[Agent Runtime]
    Spec[UI Intent Declaration\nschema and options]
    Host[Host Application]
    UI[Native UI Component]
    AR -->|describes what is needed| Spec
    Spec -->|interpreted by| Host
    Host -->|renders with own design system| UI
    style AR fill:#ede9fe,color:#4c1d95
    style Spec fill:#fef3c7,color:#78350f
    style Host fill:#dbeafe,color:#1e3a8a
    style UI fill:#d1fae5,color:#064e3b

AG-UI (Agent-User Interaction) — The Live Event Stream

What it is: AG-UI is an emerging open protocol, primarily championed by the CopilotKit team, that standardises real-time event transport between backend agent runtimes and frontends. It defines a structured event vocabulary: token streaming, tool invocations, status transitions, human-in-the-loop pauses, and resumptions.

The analogy: A live broadcast with an interactive feed. Not a static page load — a continuous stream of events that the frontend processes and renders as they arrive. AG-UI is what turns an opaque backend process into an observable, interactive experience.

In practice: A customer support copilot where you can actually see what's happening:

Response tokens streaming in as the agent writes
"Searching knowledge base..." as a tool fires
Tool parameters and results shown inline
A pause state with an approval prompt when the agent needs authorisation
Resumed execution once the human approves

The key insight: you never stare at a spinner wondering if anything is happening. You watch the agent work, step by step — and you can intervene at any point. That's exactly what AG-UI makes possible, and here's what that looks like as a sequence of events:

Without this, agents are black boxes. Users stare at a spinner and hope for the best. Fine for a demo. Not fine for production.

Why it matters now: Transparency and human-in-the-loop aren't features you bolt on at the end — they're increasingly requirements in any enterprise context with actual governance. AG-UI provides the event stream that makes both possible without each team having to build it from scratch.

Like A2UI, AG-UI is earlier in its standardisation lifecycle than MCP. The spec is stabilising through community adoption rather than a formal standards process.

sequenceDiagram
    participant UI as What You See
    participant AR as Agent
    participant T as Tool
    Note over UI,AR: You send a message
    AR-->>UI: text appears word by word
    AR->>T: agent queries a tool
    AR-->>UI: Searching... indicator appears
    T-->>AR: tool returns data
    AR-->>UI: result shown inline
    AR-->>UI: Approve this action?
    UI->>AR: you click Approve
    AR-->>UI: response continues

Protocol Summary

Protocol	Primary Purpose	Communication Path	Real-World Analogy
MCP	Connect agents to tools and data	Agent ↔ Tool / Data Source	USB-C
A2A	Enable agents to coordinate with other agents	Agent ↔ Agent	Automated B2B supply chain
A2UI	Describe UI structure declaratively	Agent → UI Host	Restaurant menu
AG-UI	Stream agent activity to frontends in real time	Agent Runtime → Frontend	Live broadcast

How They Fit Together: A Layered Architecture

The reason these protocols appear to overlap is that they're described in isolation. Put them side by side in a stack and the picture becomes obvious:

+----------------------------------+
| User Experience Layer            |
| A2UI + AG-UI                     |
+----------------------------------+
| Agent Coordination Layer         |
| A2A                              |
+----------------------------------+
| Tool & Context Layer             |
| MCP                              |
+----------------------------------+
| Existing Infrastructure          |
| REST APIs, GraphQL, Databases    |
+----------------------------------+

Tool & Context Layer (MCP): This is where agents get their capability. Read a file, query a database, call an API. MCP doesn't care about multi-agent coordination or user interfaces. It answers one question: what can an agent actually see and do?

Agent Coordination Layer (A2A): When a task exceeds what a single agent can handle — whether by capability, authority, or domain — A2A handles the delegation. It operates between agents; MCP operates between agents and tools. Different relationships, different protocol.

User Experience Layer (A2UI + AG-UI): A2UI describes what the user needs to see or interact with. AG-UI handles how it arrives — the live, incremental event flow that makes agent behaviour observable rather than opaque. Complementary problems at the same layer.

Existing Infrastructure: Databases, REST APIs, GraphQL services — none of this disappears. MCP servers frequently wrap existing APIs. A2A agents often front existing services. The new protocols govern agent behaviour; they don't replace the infrastructure underneath.

Here's what a system with all four protocols in play looks like:

graph TB
    User([User]) --> FE[Frontend Application]

    FE <-->|AG-UI| AR[Agent Runtime]
    FE <-->|A2UI| AR

    AR <-->|MCP| MCP1[MCP Server\nCode Repository]
    AR <-->|MCP| MCP2[MCP Server\nDatabase]
    AR <-->|MCP| MCP3[MCP Server\nCRM / Enterprise API]

    AR <-->|A2A| EA1[External Agent\nBooking Agent]
    AR <-->|A2A| EA2[External Agent\nPayment Agent]

    MCP2 --- DB[(Database)]
    MCP3 --- API[REST API / GraphQL]
    EA1 --- EA1DB[(Agent Infrastructure)]

    style FE fill:#dbeafe,color:#1e3a8a
    style AR fill:#ede9fe,color:#4c1d95
    style MCP1 fill:#d1fae5,color:#064e3b
    style MCP2 fill:#d1fae5,color:#064e3b
    style MCP3 fill:#d1fae5,color:#064e3b
    style EA1 fill:#fef3c7,color:#78350f
    style EA2 fill:#fef3c7,color:#78350f
    style DB fill:#f3f4f6,color:#374151
    style API fill:#f3f4f6,color:#374151
    style EA1DB fill:#f3f4f6,color:#374151

Each edge is a protocol boundary. The frontend doesn't touch the database. The agent runtime doesn't generate raw HTML. The booking agent doesn't share code with the orchestrating agent. The protocols manage the seams — and that separation is what makes the system maintainable, swappable, and safe to extend.

Three Common Misconceptions

Misconception #1: "A2A Replaces MCP"

No. They're solving different problems at different layers, full stop.

MCP is Agent ↔ Tool. The agent wants to do something — read a file, query a database — and the tool responds. It's a subordinate relationship. The tool has no goals of its own.

A2A is Agent ↔ Agent. Both sides are autonomous. Both have state, goals, and internal complexity. An A2A interaction can span hours, involve capability negotiation, and include delegated task ownership with real consequences.

A database doesn't have goals. A booking agent does. These require genuinely different protocols. Could you wrap an MCP tool in an A2A-compliant agent? Technically yes. Should you? Not unless the tool genuinely needs autonomous behaviour — which adds coordination overhead for no reason.

Misconception #2: "AG-UI and A2UI Are the Same Thing"

They're not, and conflating them leads to real design problems downstream.

A2UI defines structure — what should the user see? A form, a date picker, an approval dialog. Declarative intent, not rendering code.

AG-UI defines transport — how does the agent's live activity reach the frontend? Streamed tokens, tool events, status transitions, pause/resume states. The event bus.

You can have A2UI without AG-UI: agents declare UI structure delivered via standard request-response. You can have AG-UI without A2UI: streaming token output with no declarative UI generation. In practice, they complement each other — AG-UI carries A2UI payloads as part of its event stream when agents need to surface interaction points to users.

Misconception #3: "These Protocols Eliminate REST APIs"

They don't — and this one frustrates me because it derails otherwise productive architecture conversations.

MCP servers frequently wrap REST endpoints. A2A agents often front conventional services. AG-UI typically runs alongside standard HTTP endpoints. None of these protocols care whether the underlying service is REST, GraphQL, gRPC, or raw SQL.

They standardise agent behaviour: how agents acquire tools, coordinate with each other, describe UI intent, and stream activity. Your PostgreSQL database doesn't implement MCP. Your payment API doesn't implement A2A. The existing infrastructure layer remains; it gets wrapped and orchestrated, not replaced.

Reality Check: Where Things Actually Stand

Adoption by Protocol

MCP is the clear leader on maturity. Stable spec, solid SDKs, and a real ecosystem of servers emerging. It's embedded in Claude Desktop, Cursor, and a growing list of developer tools. If you're evaluating AI tool integration today, start here — the infrastructure is actually there.

A2A has serious momentum from Google's backing and real enterprise interest. I've seen it come up in more architecture discussions over the past six months than any other protocol on this list. Production deployments are still early, but evaluation is absolutely the right move for any team planning multi-agent systems.

AG-UI addresses a gap that teams are currently solving with custom implementations — and custom implementations per team create exactly the pressure that drives standardisation. The CopilotKit ecosystem has done real work here. Worth watching closely and worth prototyping with now.

A2UI is the most nascent. The concept is solid and teams keep independently arriving at the same pattern, which is encouraging. But a single authoritative spec isn't there yet. If you're implementing today, expect to define your own schema conventions and revisit them as the space settles.

The Parts Nobody Has Figured Out Yet

Session Persistence

Long-running workflows expose a gap none of the current specs fully address: what happens when the network drops, the agent runtime restarts, or a user comes back to a workflow twelve hours later?

A2A has concepts for long-running tasks and event subscriptions, but recovery semantics across agent restarts are implementation-defined. AG-UI streams events but doesn't specify reconnection and replay behaviour. Teams building for production are bolting their own persistence layer on top — typically durable queues or event stores. It works, but it's per-team plumbing that should eventually be protocol-native.

Enterprise Security and Governance

OAuth 2.1 and OIDC give you a solid foundation, and both MCP and A2A reference them for authentication. But cross-organisational agent trust — when your agent delegates to a partner organisation's agent — is genuinely unsolved at the protocol level.

Who authorises what? How does federated identity work when you don't control the other org's identity provider? What does the trust model look like for a delegated action with financial consequences? The honest answer is: the industry is still working on it, and anyone who tells you otherwise is selling something.

Auditability and Compliance

Regulated industries need a full audit trail: which agent did what, with what parameters, authorised by whom, at what time. Individual protocols give you pieces — MCP tool invocations are logged, AG-UI events are observable — but there's no standardised audit format spanning the whole stack.

If you're in financial services, healthcare, or any sector with serious compliance requirements, you'll be assembling this trail from disparate sources. Plan for it explicitly. Don't assume the protocols handle it — they don't, not yet.

What This Means for Architects

If this stack continues to mature — and I think it will — the architectural implications are significant.

Reduced vendor lock-in. An agent runtime that speaks MCP can swap tool providers without code changes. An orchestrator that speaks A2A can replace a specialised agent without re-architecting the workflow. Standardised interfaces make components substitutable in ways that custom integrations never are.

Clear ownership boundaries. Frontend teams own the AG-UI integration. Platform teams own the MCP server fleet. AI product teams own agent runtimes and A2A coordination. These boundaries are enforced by protocol, not by organisational norms that erode under deadline pressure. I've seen teams do real damage by ignoring where the protocol boundary should have been.

Swappable models. Because the protocols don't prescribe which LLM backs an agent, you can swap models without touching the agent's protocol surface. Given how fast the model landscape is moving, this flexibility matters more than people realise right now.

Sustainable multi-agent architecture. The alternative to standardised protocols is bespoke integration — custom communication logic for every agent pair. That works for two agents. It breaks at ten. The protocol approach scales because coordination cost is amortised across every adopter, not charged per integration. Same economic argument that drove HTTP adoption; same outcome, eventually.

Genuine governance. AI systems at enterprise scale need operational clarity: what is running, what is it doing, who authorised it, what did it access. The observability that AG-UI enables and the auditability you can build on top of this stack is what separates a governable system from a capable-but-unaccountable one. In 2026, that distinction increasingly matters — and increasingly, it's what enterprise buyers are asking about.

Conclusion: Talk Is Cheap — Let's Build It

Architecture diagrams are useful. Standards discussions are useful. But code is the real test of whether any of this is actually practical.

This article is the first in a hands-on implementation series. The next posts build real proof-of-concept systems — not toy examples — demonstrating each protocol in practice:

MCP — Building an MCP server that exposes a real data source, integrated with a Claude-powered client
A2A — Publishing an Agent Card, delegating a long-running task, and handling status propagation between independently deployed agents
A2UI — Prototyping declarative UI intent from an agent runtime, with host-side rendering
AG-UI — Wiring real-time agent event streaming to a frontend, including human-in-the-loop approval flows

Each will be complete enough to run locally, opinionated about implementation choices, and honest about where things get messy.

For decades, the industry built standards that connected browsers to servers, servers to databases, services to services — HTTP, SQL, REST, gRPC. Each one reduced the cost of integration and expanded what was possible to build.

Now we're doing the same for agents: standardising how they connect to tools, coordinate with each other, and surface their work to users.

The protocols are young. The gaps are real. But the direction is becoming clear — and the engineers who understand the full stack, not just individual protocols in isolation, are the ones who'll build the systems that matter next.