AG-UI Protocol and Generative UI in 2026: the open standard that finally connected AI agents to real frontends

For two years the agent ecosystem solved every layer of the stack except the one users actually see. The Model Context Protocol gave agents a clean way to reach data and tools. Agent2Agent gave agents a clean way to reach each other. Skills gave them a clean way to carry procedural knowledge. The frontend stayed where it was in 2023: a chat box, a message list, and whatever bespoke glue each team wrote to push streaming tokens, tool calls, and state changes into a React tree. AG-UI is the protocol that closed that gap. CopilotKit announced it on May 12, 2025, and by mid-2026 it sits in production at Deutsche Telekom, Docusign, Cisco, and S&P Global, ships first-party integrations across LangGraph, CrewAI, Mastra, AG2, LlamaIndex, Agno, Pydantic AI, Microsoft Agent Framework, Google ADK, AWS Strands, and the Claude Agent SDK, and forms the user-facing leg of what the industry now calls the agent protocol triad.

Why MCP and A2A were not enough

The agent protocol story in 2024 and 2025 was a story about backends. MCP solved the data and tool problem: any MCP-compatible host can plug into any MCP server and reach the underlying integration with a typed contract. A2A solved the agent coordination problem: one agent can hand work to another across framework and vendor boundaries through a published agent card and a typed task model. Both protocols sit behind the API line. The user never touches them directly.

The line in front of the user was still a free-for-all. Every team that put an agent in production wrote its own streaming layer: a custom Server-Sent Events format here, a bespoke WebSocket frame there, a hand-rolled state reconciliation hook in React, a slightly different tool call rendering for each agent framework, and a different approval flow for every human-in-the-loop interrupt. The backend was portable across MCP and A2A. The frontend was locked to whichever agent framework the team picked first. Switching from LangGraph to CrewAI meant rewriting the UI layer. Adding a second agent meant duplicating it.

AG-UI starts from the same observation that produced MCP and A2A: the interface between an agent and the thing it talks to should be a typed, versioned, vendor-neutral protocol, not a per-project integration. The thing the agent talks to in this case is the frontend, and the events it emits are the messages, the tool calls, the state patches, and the lifecycle signals the UI needs to render an agent run. The protocol is small enough to read in an afternoon, runs over plain HTTP with Server-Sent Events, and is implemented by a Python SDK, a TypeScript SDK, and at least one client integration in every major agent framework.

The agent protocol triad: MCP, A2A, AG-UI

The mental model that has stuck is the triad. Each protocol owns one of the three boundaries an agent has to cross to be useful in production, and the protocols compose because they do not overlap.

MCP (agent to tools and data). The agent reaches outward to a database, a SaaS API, a file system, or a search index through an MCP server. Typed tool contracts, structured resources, and a uniform authorization model live on this layer.
A2A (agent to agent). One agent delegates a sub-task to another agent through a published agent card and a typed task envelope. Vendor neutral, framework neutral, and now governed by the Linux Foundation through the Agent2Agent project.
AG-UI (agent to user). The agent streams typed events to whatever frontend the user is actually looking at: a React app, an Angular dashboard, a Slack channel, a mobile app. The frontend renders messages, tool calls, generative UI components, and state updates as they arrive.

A serious 2026 agent uses all three. A code review agent might pull file contents over MCP, hand the security review to a specialist subagent over A2A, and stream the review steps and inline diffs into a CopilotKit chat panel over AG-UI. The three protocols never collide because none of them tries to do another’s job. The moment a team starts inventing tool calls inside an AG-UI event payload or stuffing UI state into an MCP resource, the abstraction has slipped and the right move is to put the work back on the right protocol.

AG-UI by the numbers

Announced on May 12, 2025 by CopilotKit as an open, lightweight, event-based protocol.
17 event types in the current spec, organised into five families: lifecycle, text messages, tool calls, state management, and special events.
14,000+ GitHub stars on the ag-ui-protocol repository by mid-2026, one of the fastest growing protocol projects of the cycle, with tens of millions of weekly interactions across the broader CopilotKit family of repositories.
2 million weekly interactions through CopilotKit’s AG-UI implementations alone, doubling inside two weeks during the 2026 launch cycle.
First-party integrations in LangGraph, CrewAI, Mastra, AG2, LlamaIndex, Agno, Pydantic AI, Microsoft Agent Framework, Google ADK, AWS Strands, and the Claude Agent SDK. AWS Bedrock Agents and the OpenAI Agents SDK are in progress.
$27M Series A raised by CopilotKit in May 2026 to make AG-UI the default frontend layer for in-app agents, with Deutsche Telekom, Docusign, Cisco, and S&P Global cited as production customers.

The 17 events and the five families

Every AG-UI run is a stream of typed JSON events flowing from the agent backend to the frontend over SSE or, when the deployment needs a bidirectional channel, WebSockets. The 17 event types fall into five families, and almost every production UI uses every family at least once per request.

Lifecycle: RUN_STARTED, RUN_FINISHED, RUN_ERROR. The frontend uses them to flip the busy indicator, capture the run identifier, and surface failure modes without guessing from the absence of further messages.
Text messages: TEXT_MESSAGE_START, TEXT_MESSAGE_CONTENT, TEXT_MESSAGE_END. The streaming text path, designed so the UI can begin rendering the moment the first token arrives and finalise message metadata at the end.
Tool calls: TOOL_CALL_START, TOOL_CALL_ARGS, TOOL_CALL_END, and TOOL_CALL_RESULT. Arguments stream as they are generated, which means a form can pre-fill before the model finishes deciding what to do. Results come back as a separate typed event so the UI can render them as components rather than raw text.
State management: STATE_SNAPSHOT and STATE_DELTA. The agent and the UI share a structured state object. Snapshots set the baseline, deltas patch it. The UI refreshes only the parts that changed, which keeps the page calm even when the agent is making rapid updates.
Special events: INTERRUPT for human-in-the-loop pauses, CUSTOM for application-specific events, and lifecycle helpers like STEP_STARTED and STEP_FINISHED for multi-step workflows. The interrupt event is the spine of every approval gate, edit dialogue, and structured input prompt in a production AG-UI app.

The events are the contract. Every adopter framework emits the same events with the same shapes; every adopter client renders them with the same semantics. The framework can do whatever it wants under the hood, as long as the wire format matches.

A minimal AG-UI event stream

The cleanest way to see the protocol is to look at the wire. The snippet below shows a single agent run that greets the user, calls a tool, patches shared state, and finishes. Every newline-delimited block is one SSE event carrying a typed AG-UI payload.

AG-UI event stream (SSE)

json

event: message
data: {"type": "RUN_STARTED", "runId": "run_8c1f", "threadId": "th_42"}

event: message
data: {"type": "TEXT_MESSAGE_START", "messageId": "m_1", "role": "assistant"}

event: message
data: {"type": "TEXT_MESSAGE_CONTENT", "messageId": "m_1", "delta": "Looking up the latest invoice"}

event: message
data: {"type": "TEXT_MESSAGE_END", "messageId": "m_1"}

event: message
data: {"type": "TOOL_CALL_START", "toolCallId": "tc_a", "toolName": "get_invoice"}

event: message
data: {"type": "TOOL_CALL_ARGS", "toolCallId": "tc_a", "delta": "{\"supplierId\":\"ACME-001\"}"}

event: message
data: {"type": "TOOL_CALL_END", "toolCallId": "tc_a"}

event: message
data: {"type": "TOOL_CALL_RESULT", "toolCallId": "tc_a", "result": {"total": 14250, "currency": "EUR"}}

event: message
data: {"type": "STATE_DELTA", "patches": [{"op": "replace", "path": "/lastInvoice", "value": {"id": "INV-2026-04-118", "total": 14250}}]}

event: message
data: {"type": "RUN_FINISHED", "runId": "run_8c1f"}

Two things in this stream are worth pulling out. The STATE_DELTA patch uses RFC 6902 JSON Patch operations, which means the same delta format works for any UI framework on the receiving side. The tool call arguments arrive as a streaming string delta, not a finished JSON blob, which is what lets a form pre-fill as the model writes the arguments rather than waiting for the final tool call to land.

Generative UI: rendering tool calls as components

AG-UI is the wire format. Generative UI is the pattern that runs on top of it. Instead of streaming text into a chat bubble, the agent calls a tool whose entire purpose is to render a typed component, and the frontend wires that tool to a React component, an Angular widget, or a Flutter view. The model decides which component to show and what data to pass in; the frontend handles the rendering and the interactivity.

The shift this represents is bigger than the UI patch. For the first two years of LLM products, the user experience was tied to a single primitive: the message. Tables, charts, forms, maps, kanban boards, and approval dialogues all had to be coerced into markdown the model could write. Generative UI breaks that ceiling. The agent can render a chart by calling render_chart, ask for confirmation by calling confirm_action, kick off a flow by calling open_form. The chat bubble becomes one component among many.

components/AgentSurface.tsx

tsx

// A React frontend wired to an AG-UI backend through CopilotKit.
// The agent calls "render_invoice_card" as a tool; the UI maps the
// tool name to a React component and renders it inline in the chat.

import { CopilotChat } from "@copilotkit/react-ui";
import { useCopilotAction } from "@copilotkit/react-core";
import { InvoiceCard } from "@/components/InvoiceCard";

type InvoiceArgs = {
  supplierId: string;
  total: number;
  currency: string;
  invoiceNumber: string;
};

export function AgentSurface() {
  // Register a tool. The agent (running anywhere AG-UI is supported)
  // calls "render_invoice_card" through a TOOL_CALL_START event. The
  // hook renders the React component inline while the args stream in.
  useCopilotAction<InvoiceArgs>({
    name: "render_invoice_card",
    description: "Render an interactive invoice card inline in the chat.",
    parameters: [
      { name: "supplierId", type: "string" },
      { name: "total", type: "number" },
      { name: "currency", type: "string" },
      { name: "invoiceNumber", type: "string" },
    ],
    render: ({ status, args }) => (
      <InvoiceCard
        status={status} // "executing" while args stream in, "complete" at end
        invoice={args}
      />
    ),
  });

  return <CopilotChat />;
}

The hook does three things at once. It registers a tool on the AG-UI side so the agent knows the capability exists. It binds the tool name to a React component so the UI knows what to render. And it surfaces the streaming status to the component, which means a card can show a skeleton state while the arguments are still arriving and switch to the finished state when the TOOL_CALL_END event lands. The exact same component renders whether the agent is running on LangGraph, CrewAI, Mastra, or any of the other adopter frameworks.

Shared state: the agent and the UI on the same wire

The state events are the part of the protocol that most teams underuse on day one and become reliant on by month two. A shared state object lives between the agent backend and the frontend; both sides can read it, and either side can patch it. The agent emits STATE_SNAPSHOT at run start with the baseline and STATE_DELTA events with JSON Patch operations whenever any field changes. The frontend renders directly from that state object, which means every UI is implicitly reactive to whatever the agent decides to change.

The pattern that wins in production is to treat the shared state as the source of truth and the chat thread as the audit trail. A pipeline review agent might keep the live forecast, the per-rep variance, and the action list inside the shared state object. The agent updates them as it works; the dashboard renders them instantly; the chat thread becomes the explanation of why each field changed. The team that built the same feature in 2024 had a chat panel and a separate API the chat panel polled. The 2026 version has one stream.

Human-in-the-loop: the INTERRUPT event

Real agents need to pause. They need to confirm a destructive action, ask the user to pick between two plausible options, or hand a form back to the user to fill out. AG-UI handles all of that with a single event type: INTERRUPT. The agent emits the interrupt, the UI pauses the run, surfaces whatever component the interrupt asked for, collects the response, and resumes the run with the user input. The pattern lines up cleanly with LangGraph’s native interrupt primitive and with the equivalent constructs in CrewAI, AG2, and the Claude Agent SDK.

agent/run.ts

typescript

// A LangGraph agent that pauses for explicit user approval before it
// runs a refund. The interrupt flows out as an AG-UI INTERRUPT event;
// the CopilotKit useHumanInTheLoop hook in the React UI surfaces it as
// an approval card and resumes the graph with the user's choice.

import { StateGraph, interrupt } from "@langchain/langgraph";

const graph = new StateGraph(/* ... */)
  .addNode("plan_refund", async (state) => {
    return { plannedRefund: await proposeRefund(state.order) };
  })
  .addNode("await_approval", async (state) => {
    // The interrupt becomes an AG-UI INTERRUPT event on the wire.
    const decision = await interrupt({
      type: "approve_refund",
      summary: state.plannedRefund.summary,
      amountCents: state.plannedRefund.amountCents,
      requiresReason: state.plannedRefund.amountCents > 50_00,
    });

    if (decision.action !== "approve") {
      return { refundStatus: "rejected", reason: decision.reason };
    }
    return { refundStatus: "approved" };
  })
  .addNode("execute_refund", async (state) => {
    if (state.refundStatus !== "approved") return {};
    return { receipt: await executeRefund(state.plannedRefund) };
  });

export const runtime = graph.compile();

The pause is the contract. The agent does not retry, does not poll, does not paper over the gap with a synthetic decision. It emits the interrupt and waits. The UI shows whatever card the interrupt payload asked for, the user clicks approve or reject, the response flows back through the AG-UI client, and the graph resumes with the decision in scope. The same pattern handles forms, choice between options, and structured edits.

Where Vercel AI SDK fits

AG-UI is not the only generative UI surface in 2026. The Vercel AI SDK has shipped its own streaming UI primitives for two years: streamUI for React Server Component generation, useObject for typed streaming objects, and tool-based component rendering through the tools option on streamText. The SDK is opinionated about Next.js and React Server Components; the AG-UI protocol is framework-neutral and works equally well in Angular, Vue, Svelte, and mobile clients.

The split that has emerged is straightforward. Teams building a Next.js app with the Vercel AI SDK as their agent framework typically stay on the SDK’s native streaming. Teams running agents on LangGraph, CrewAI, Mastra, or another non-Vercel framework reach for AG-UI to bridge to the frontend. Some teams use both: the Vercel AI SDK on the model side and an AG-UI client on the UI side. The Vercel AI SDK’s RSC track was paused in late 2025; the framework-agnostic streaming path through plain SSE and the useChat family of hooks has become the recommended surface, and it interoperates cleanly with AG-UI events when teams choose to standardise on the open protocol.

Real-world production deployments

Deutsche Telekom. The enterprise internal copilots run on CopilotKit with AG-UI as the frontend transport. The agent surfaces in dozens of internal apps, each one bringing its own component library and rendering AG-UI tool calls as the components its users already know.
Docusign. AI-assisted contract review and clause analysis ship through an AG-UI surface that renders inline annotations, change-tracked diffs, and approval cards directly inside the document workspace. The chat thread is the audit log; the document is the UI.
Cisco. AG-UI sits in production as the frontend layer for network-operations agents, with interrupts handling change-window approvals and shared state driving real-time topology dashboards.
S&P Global. Research analyst assistants render charts, tables, and citation cards through generative UI tools, with the AG-UI shared state acting as the analyst’s scratchpad.
Oracle Agent Spec. Oracle’s Open Agent Specification adopted AG-UI as its frontend transport in May 2026, pairing the agent definition layer with the user-facing event stream inside the Oracle Cloud Infrastructure agent platform.
AWS Bedrock and FAST. AWS integrated AG-UI into its FAST examples and into Bedrock AgentCore, which gave teams running on Bedrock a framework-agnostic way to surface agents in their existing React, Angular, and mobile apps.

The thread across these deployments is the same: the team kept the frontend it already had and pulled the agent into it, rather than building a new chat product around the agent. That inversion - app first, agent second - is the design that AG-UI was built to enable, and the production count is the evidence that it does.

Security: prompt injection in a generative UI world

A protocol that lets a model render UI components has the same risk surface every other agent surface inherits in 2026: prompt injection. The Microsoft Agent Framework documentation on AG-UI is explicit about it. The messages list and the shared state are primary injection vectors, and a malicious client with direct AG-UI access can plant instructions inside either one that the model will pick up on the next turn. The mitigations are familiar from the broader agent security playbook but worth restating in the AG-UI context.

Least-privilege UI. Generative UI tools should only render from a fixed catalog of trusted components. The agent picks the component by name; the renderer maps the name to a static React, Angular, or Flutter implementation. Free-form HTML rendering inside the chat is the equivalent of giving the model a shell.
Typed state schemas. Treat the shared state object like an API request: validate it on every patch, reject deltas that do not match the schema, and never let arbitrary keys land. JSON Patch is a sharp tool; an unvalidated patch can replace any path the schema allows.
Sandboxed third-party UI. When the UI does need to render content from a third-party source - an MCP server emitting an MCP-UI component, an A2UI payload from a partner agent - the convention that has emerged is a sandboxed iframe with no ambient credentials. The component renders inside its own origin; the host page never trusts the rendered DOM.
Approval gates on dangerous actions. Any tool call that can destroy data or trigger a billable action should be routed through an INTERRUPT, not run silently. The interrupt is the spec’s answer to the lethal trifecta of untrusted input, sensitive tools, and exfiltration paths.

The bigger point is that AG-UI does not invent a new attack surface; it inherits the agent stack’s attack surface and surfaces the right hook - INTERRUPT - to put a human between the model and the sensitive action when it matters.

Where Google’s A2UI and MCP-UI fit

Two adjacent protocols landed in late 2025 and early 2026, and both compose cleanly with AG-UI rather than replacing it.

Google A2UI launched on December 22, 2025 as an open source agent-to-user interface specification. The agent emits a declarative JSON payload that describes a tree of components and a data model; the client maps each component name to its native widget. A2UI is deliberately not executable code, which makes it safer to render content that crosses trust boundaries. Gemini Enterprise added A2UI v0.8 support in May 2026, and the CopilotKit team shipped an A2UI-over-AG-UI sample that uses AG-UI as the streaming carrier and A2UI as the component description format. The two protocols sit at different levels: AG-UI carries the events on the wire, A2UI describes what one of those events should render.

MCP-UI is the pattern where an MCP server returns interactive HTML inside a sandboxed iframe, letting third-party services bring their own component library into the agent surface. It is the right fit when the service wants to render its own branded experience and accepts the operational cost of shipping an iframe. The agent stack composes the three: MCP carries tool calls and data, MCP-UI carries third-party rendered components, A2UI carries first-party declarative components, and AG-UI carries everything from the agent to the user-facing application. The layers do not collide because each one answers a different question about how the user ultimately sees the agent’s output.

Advantages and limitations

What you buy. A vendor-neutral wire format for agent-to-user communication, typed events that map directly to UI primitives, streaming tool arguments that let interfaces pre-fill before tool calls land, shared state that removes the chat-plus-polling pattern, and a portable interrupt mechanism for human-in-the-loop work. The same frontend works across every major agent framework without rewrites.
What you pay. A new layer in the stack to learn, a discipline around treating shared state as an API and validating it, the operational cost of running SSE or WebSocket connections at the scale of real user traffic, and a willingness to keep the generative UI catalog small and trusted. Teams that try to render arbitrary HTML from model output will get hurt the same way they would without AG-UI; the protocol does not paper over UI security holes.
Where it does not fit. Pure chat products with no tool calls and no shared state, single-page demos, and any app where the agent already lives inside a framework whose native streaming surface is good enough. A Next.js project using the Vercel AI SDK end-to-end may not need AG-UI at all. The protocol pays for itself when the frontend, the agent framework, or the deployment target is not under one team’s control.
Spec stability versus implementation variance. The wire format is stable. The client SDKs across React, Angular, Vue, and Flutter are at different maturity levels, and the server adapters across LangGraph, CrewAI, Mastra, and the rest have small but real differences in how they map their native concepts to AG-UI events. The discipline that scales is to write conformance tests against the spec and treat client and server adapters as integration points, not drop-in replacements.

Trends shaping the next twelve months

App-first, chat-second. The 2024 frontier was the chat product. The 2026 frontier is the app that grows an agent layer. AG-UI is the plumbing for that shift, and the CopilotKit-on-AG-UI deployments at Deutsche Telekom, Docusign, and Cisco are the early evidence.
Declarative UI over executable UI. A2UI is the marker. The industry is moving away from letting the model produce HTML or JSX and toward letting it choose components from a typed catalog. The security story is the driver, the developer experience story is the bonus.
Standardised observability. The AG-UI event stream is a natural span boundary. Braintrust, LangSmith, OpenInference, and the OpenTelemetry GenAI conventions added first-class AG-UI span families in 2026, which means agent runs finally show up in tracing tools with the same fidelity HTTP requests have had for a decade.
Native multi-framework apps. The end state of the protocol triad is an app that renders agents from three different frameworks in the same UI: a LangGraph agent for one workflow, a CrewAI swarm for another, a single Claude Agent SDK loop for a third. AG-UI is the seam that makes that possible without re-skinning the chat panel three times.
Mobile and voice surfaces. The 2026 spec drafts add explicit mobile binding events and a voice channel for cases where the agent needs to drive a TTS pipeline alongside the visual UI. The same event types extend; the transport adapts.

When to pick AG-UI, when to skip it

The decision tree we run with clients is short. If the product is an existing app that needs to grow an agent layer, AG-UI is the default; the cost of rolling a bespoke streaming layer is higher than the cost of learning the protocol. If the product is a brand new Next.js chat surface running on the Vercel AI SDK with no plan to support other frameworks, the SDK’s native streaming is enough. If the team is integrating agents from multiple frameworks - LangGraph in one domain, CrewAI in another, the Claude Agent SDK in a third - AG-UI is no longer optional; it is the only layer that keeps the frontend single. If the agent runs entirely server-side with no user surface at all, skip AG-UI and stay on MCP and A2A.

Conclusion: the frontend finally gets a protocol

For a long time, the frontend was the place where every agent stack leaked. MCP and A2A made the backend portable; the UI stayed locked to whichever framework shipped first. AG-UI is the protocol that closed the loop. A small spec, a clean event stream, and an ecosystem of first-party adapters give teams a way to ship agents into the apps people already use without rebuilding the streaming layer for every project. The 2026 production deployments are the proof that the pattern works. The decision in 2026 is not whether to adopt the protocol; the decision is which surface area of the agent product belongs in chat, which belongs in generative UI, and which belongs in the shared state that lives between them.