AG-UI explained for frontend engineers

Your agent backend streams tokens. It calls tools. It pauses for approval. It updates shared state. The React app on the other side receives all of this through four different ad-hoc endpoints and a prayer.

That is the problem AG-UI — the Agent–User Interaction Protocol — was built to solve. It is not a UI widget kit. It is the event bus between agent runtime and frontend application.

Key idea

AG-UI standardizes how agent state, messages, tools, and UI intents flow to your app — not what widgets they become. For widget shape, pair it with A2UI or your own component contracts.

Why REST breaks for agentic UI

Pre-agentic frontends assumed short requests and complete responses. Agentic systems violate that in predictable ways, which the AG-UI docs enumerate:

• Agents are long-running and stream intermediate work across multi-turn sessions.
• They are nondeterministic and may change UI state in ways a static route cannot anticipate.
• They mix structured and unstructured I/O — text, files, tool calls, state patches.
• They compose — sub-agents, delegated tasks, nested cancellation.

AG-UI sits on HTTP or WebSockets as an abstraction layer — event-based, bi-directional, and designed so frontends do not reimplement the same wiring for every agent framework.

Where AG-UI sits in the stack

From the protocol landscape series:

flowchart LR
  FE["React / Vue frontend"] <-->|"AG-UI events"| AR["Agent runtime"]
  AR <-->|"MCP"| MCP["MCP servers"]
  AR <-->|"A2A"| RA["Remote agents"]
  AR -->|"A2UI messages"| FE

CopilotKit maintains AG-UI and documents the distinction from A2UI directly: A2UI is a generative UI specification; AG-UI is the agent↔user interaction protocol (AG-UI docs note).

Building blocks (what the protocol covers)

As of the current AG-UI specification, the protocol addresses:

This is materially broader than a chat SSE stream. The Vercel AI SDK data stream focuses on message parts from model calls. AG-UI models the full session between a user-facing app and an agentic backend.

Integrations (who speaks AG-UI today)

AG-UI originated in CopilotKit’s work with LangGraph and CrewAI. The supported integrations table now includes, among others:

• LangGraph, CrewAI, LlamaIndex, Mastra, Pydantic AI, Agno
• Google ADK, Microsoft Agent Framework, AWS Strands / Bedrock AgentCore
• Direct-to-LLM paths for simpler setups

For frontend engineers, the practical meaning is: you can standardize the client adapter even when backend teams swap agent frameworks — similar to how ODBC did not remove SQL dialects but stabilized the client boundary.

AG-UI + A2UI: the documented pairing

Google’s A2UI announcement and CopilotKit’s ecosystem messaging describe a deliberate split:

• AG-UI — pipes, state, session, events.
• A2UI — declarative component trees the agent proposes.

A host built on AG-UI can render native widgets from A2UI messages instead of sandboxed HTML. That matters for enterprise products that need brand-consistent, accessible components rather than iframe islands.

CopilotKit ships the A2UI Widget Builder and A2UI Theater to exercise this pipeline without custom agent code on day one.

When you need AG-UI (and when you do not)

Reach for AG-UI when:

• multiple agent frameworks must feed one product UI;
• you need shared state, interrupts, or frontend-executed tools as standard features;
• generative UI must interoperate with remote A2A agents;
• you are building a copilot surface, not a single chat endpoint.

Skip AG-UI (for now) when:

• one Next.js API route + useChat + Zod schemas covers your scope;
• your “agent” is a single streamText call with two tools;
• you ship inside an MCP host (Claude, ChatGPT) where MCP Apps defines the UI boundary.

Adopting AG-UI has a cost: event schemas, client SDK, observability. Pay it when agent complexity is already costing more in bespoke glue code.

Frontend architecture sketch

A minimal mental model for the client:

stateDiagram-v2
  [*] --> Idle
  Idle --> Streaming: user message
  Streaming --> ToolRender: tool-output event
  ToolRender --> Streaming: continue
  Streaming --> Interrupt: approval required
  Interrupt --> Streaming: user approves
  Streaming --> Idle: finish event

Implementation layers:

1. Transport adapter — connects to AG-UI backend (WebSocket or HTTP).
2. Event reducer — folds events into session state (messages, shared store, pending tools).
3. Renderer registry — maps tool outputs and A2UI surfaces to React/Vue components.
4. Action dispatcher — handles frontend tool calls and interrupt responses back to the agent.

Keep renderers in your component catalog. AG-UI should not become an excuse to let the model pick arbitrary HTML.

Product implication

AG-UI buys debuggability and consistency in agentic UX. When every interrupt and tool render is an event type, product analytics and QA have stable hooks. When everything is custom websocket JSON, “the copilot felt buggy” is as specific as the bug report gets.

For hiring and architecture reviews, AG-UI literacy signals you understand that chat UX is now a frontend architecture problem — not only a prompt engineering problem.

What to watch next

AG-UI moves bits and lifecycle. A2UI defines the declarative UI payload that often rides inside those events: A2UI explained for frontend engineers.

References:

• AG-UI Documentation
• AG-UI Dojo (demos)
• CopilotKit — AG-UI and A2UI
• Google — Introducing A2UI
• A2A Protocol