Teams building AI products hit the same wall at different speeds. The model works. The demo streams tokens. Then someone asks: how do we turn this into a comparison table, an approval step, or a form that matches our design system?
The answer is rarely “better prompts.” It is a stack of contracts between the model, your backend, and your frontend. Some of those contracts are open protocols. Some are vendor APIs. Some are SDK conventions that have become de facto standards. Confusing them costs time.
Key idea
Building an interface on LLM responses is a layered problem. Output shape, transport, agent events, and UI payload are different concerns — and different open specs address different layers.
The problem: one pipe is not enough
The pre-agentic web had a simple contract: request in, JSON out, render. LLM products break that model in several ways at once.
- Responses are long-running and streamed, not returned in one shot.
- Output mixes unstructured text with structured data and tool calls.
- Agents may run remotely, across trust boundaries, where they cannot touch your DOM.
- The UI must stay on-brand, accessible, and safe — which rules out executing arbitrary model-generated code.
No single protocol solves all of this. What exists today is a landscape of specs that stack together.
The five layers
Here is a practical map for frontend engineers and product architects. Each layer answers a different question.
| Layer | Question it answers | Open specs / conventions |
|---|---|---|
| Output contract | What shape can the model return? | JSON Schema structured outputs (OpenAI), tool/function calling (OpenAI, Anthropic), Zod-validated objects (Vercel AI SDK) |
| Stream transport | How do partial results reach the client? | SSE data stream protocol (Vercel AI SDK), plain text streams, WebSockets (OpenAI Realtime) |
| Agent ↔ frontend | How does a long-running agent talk to your app? | AG-UI (Agent–User Interaction Protocol) |
| UI payload | What does the agent send to describe interface intent? | A2UI (declarative component trees), MCP Apps (ui:// resources), app-owned JSON schemas |
| Agent ↔ tools / agents | How does the agent reach data and other agents? | MCP (tools, resources), A2A (agent-to-agent tasks) |
flowchart LR L1["Output contract"] --> L2["Stream transport"] --> L3["Agent to frontend"] --> L4["UI payload"]
Read left to right: shape the output, stream it to the client, connect the agent runtime to your app, then render the UI payload. Tools and agents (MCP, A2A) plug into layer 3 — not directly into the UI tree. Real products mix layers. A single useChat hook may handle stream transport while your own Zod schema handles the output contract. AG-UI may carry A2UI payloads inside its event stream. MCP Apps may render inside a host that also speaks AG-UI.
Three agentic protocols (and what they are not)
The AG-UI documentation groups three open agentic protocols by layer. The naming is easy to confuse, so it is worth stating plainly:
| Protocol | Layer | Role for UI |
|---|---|---|
| AG-UI | Agent ↔ user | Event-based connection between agent runtime and frontend: streaming chat, shared state, tool rendering, interrupts, generative UI hooks. Maintained by CopilotKit with broad framework integrations. |
| MCP | Agent ↔ tools | Connects agents to external systems. Base MCP is not a UI protocol, but the MCP Apps extension adds interactive UI resources tools can return. |
| A2A | Agent ↔ agent | Google’s Agent2Agent protocol (donated to the Linux Foundation) for distributed agent collaboration. It carries messages — including A2UI payloads — across trust boundaries; it does not define how you render them. |
A2UI is not in that trio because it solves a different problem: the declarative UI payload an agent sends, not the transport. Google’s A2UI announcement positions it explicitly alongside AG-UI and MCP Apps rather than against them.
What is a protocol vs. a product convention?
Not everything in this space is an open spec. Teams should label layers honestly:
- Open protocols / specs: AG-UI, A2UI, MCP (+ MCP Apps), A2A, Vercel AI SDK stream protocol (documented, implementable in any language).
- Vendor API features: OpenAI structured outputs, Anthropic tool use, OpenAI Realtime API — stable contracts, but tied to a provider.
- App-owned contracts: Your Zod types, component catalogs, and internal event buses. Valid and often right for a single product; not interoperable by default.
- Platform SDKs: Flutter GenUI SDK (uses A2UI internally), OpenAI ChatKit, CopilotKit — accelerate delivery but couple you to an ecosystem.
The foundation series argued that structured output is only useful when the frontend honors the schema. Protocols extend that idea: the interface layer needs explicit contracts at every hop, not just at the model boundary.
How teams usually assemble a stack
There is no single winning combination. Common patterns:
Pattern A — Single-app copilot. Vercel AI SDK data stream + Zod structured outputs + your component catalog. No AG-UI unless you need shared agent state or multi-framework agent backends. Good for one product, one stack, one team.
Pattern B — Agentic host with rich events. AG-UI between LangGraph / ADK / CrewAI and a React frontend. Add A2UI when remote or third-party agents must propose UI without code execution. CopilotKit documents this pairing.
Pattern C — MCP-native client. ChatGPT, Claude, VS Code, or Goose as host. MCP Apps for tool-returned UI in sandboxed iframes. The host owns rendering and security; your server ships ui:// resources. See the MCP Apps quickstart.
Pattern D — Enterprise agent mesh. A2A between orchestrator and remote agents; A2UI as the cross-boundary UI format; native renderers (Lit, Angular, Flutter) on the client. Described in Google’s A2UI ecosystem post.
These are parallel choices — pick one stack shape per product, not every layer in one app.
Product implication
Protocol choice is a product architecture decision, not a dependency fashion choice.
- If the UI must match your design system and accessibility baseline, prefer declarative payloads (A2UI, structured outputs → your components) over opaque HTML (MCP Apps iframes) unless the iframe tradeoff is acceptable.
- If agents are long-running, cancellable, and tool-heavy, AG-UI buys you event semantics that raw SSE does not standardize.
- If your surface is an MCP host (IDE, assistant client), MCP Apps is the interoperable UI path — write once, render in Claude, ChatGPT, VS Code, Goose.
- If you only need typed cards inside your own app, a Zod schema + component map may be enough. Do not adopt three protocols to impress a architecture diagram.
What to watch next
This series walks the stack top to bottom in the LLM Interface Protocols series:
- Output contracts: structured outputs and tool calling — the model boundary.
- Streaming protocols: from tokens to UI messages — how partial state reaches the client.
- AG-UI explained for frontend engineers — agent ↔ frontend events.
- A2UI explained for frontend engineers — declarative generative UI.
- MCP Apps explained for frontend engineers — UI inside the tool layer.
Start with the layer where your product currently hurts. Most teams feel pain first at the output contract or stream transport layer long before they need A2A.