The AI agent landscape is no longer just about which LLM to call or how to orchestrate tool use. In 2026, the fiercest battleground has shifted to a deceptively hard problem: how should agents render user interfaces? Three fundamentally different approaches have emerged — Google's A2UI declarative protocol, CopilotKit's AG-UI event transport, and Vercel's AI SDK RSC generative UI. This article provides a rigorous, architecture-level comparison to help you choose the right foundation for your agentic workflow.

TL;DR

A2UI, AG-UI, and Vercel AI SDK RSC solve different layers of the same problem. A2UI defines a declarative JSON format describing what to render — it is the payload. AG-UI defines an event-based transport protocol describing how messages flow between agent backends and frontends — it is the pipe. Vercel AI SDK RSC generates server-rendered React components on the fly — it is a framework-coupled approach. A2UI and AG-UI are complementary and can be combined. Vercel is converging toward A2UI support. For production multi-agent systems, A2UI + AG-UI is the most robust architecture.

Key Takeaways

  • A2UI is a format, AG-UI is a transport, Vercel AI SDK RSC is a framework — they operate at different layers of the stack and are not direct competitors.
  • A2UI wins cross-platform and security — its data-vs-code separation makes it the only approach safe for untrusted multi-agent scenarios.
  • AG-UI wins real-time communication — its event stream model handles text deltas, tool calls, and state synchronization with low latency.
  • Vercel AI SDK RSC wins simplicity for React — but is marked experimental and limited to Next.js server environments.
  • The ecosystem is converging — CopilotKit ships A2UI integration, Vercel released a json-renderer PoC, and Oracle's Agent Spec references declarative UI patterns.

The Agent UI Problem

Traditional software renders UI from application state. An agent-driven application introduces a fundamentally different paradigm: the agent itself decides what UI to show. A weather agent does not just return text — it produces a temperature chart. A booking agent does not describe available flights — it renders a selection card with actionable buttons.

This means agents need a way to express UI intent that is richer than plain text but safer than arbitrary code execution. Three approaches have emerged, each reflecting a different philosophy about where rendering decisions should live:

graph LR A["Agent produces UI intent"] --> B{"Three Approaches"} B --> C["A2UI: Declarative JSON"] B --> D["AG-UI: Event Stream"] B --> E["Vercel RSC: Server JSX"] C --> F["Client renders natively"] D --> G["Client interprets events"] E --> H["Client hydrates React tree"]

If you are new to the broader agent architecture landscape, our AI Agent Framework Comparison 2026 covers the backend orchestration layer that sits above these UI protocols.

Understanding the Three Approaches

A2UI: The Declarative JSON Format (The Payload)

A2UI (Agent-to-UI) is a specification — not a library — that defines a JSON format for describing UI components. An agent emits a JSON blueprint listing components, their properties, and their relationships. The client-side renderer maps these descriptions to native widgets on whatever platform it runs on.

json 
{
  "type": "a2ui",
  "components": [
    {
      "type": "card",
      "title": "Flight SFO → JFK",
      "children": [
        { "type": "text", "content": "Departure: 2026-04-25 08:30" },
        { "type": "button", "label": "Book Now", "action": "book_flight" }
      ]
    }
  ]
}

The critical design choice: A2UI separates data from code. The JSON contains no executable logic. The client decides how to render a card or button using its own component library. This makes A2UI safe across trust boundaries — a remote agent cannot inject code into your application.

AG-UI: The Event-Based Transport Protocol (The Pipe)

AG-UI (Agent-User Interaction Protocol), created by CopilotKit, defines how messages flow between an agent backend and a frontend. It is a transport protocol with a rich event taxonomy: text deltas, tool calls, state updates, and lifecycle events. Think of it as "SSE on steroids" — designed specifically for the streaming, bidirectional nature of agent interactions.

typescript 
// AG-UI event types
type AGUIEvent =
  | { type: "TEXT_MESSAGE_START"; messageId: string }
  | { type: "TEXT_MESSAGE_CONTENT"; delta: string }
  | { type: "TOOL_CALL_START"; toolCallId: string; name: string }
  | { type: "TOOL_CALL_ARGS"; delta: string }
  | { type: "STATE_DELTA"; delta: object }
  | { type: "RUN_STARTED" | "RUN_FINISHED" };

AG-UI does not prescribe what to render. It prescribes how to deliver render instructions. This is why it is complementary to A2UI — AG-UI can transport A2UI payloads as the content of tool call or custom events.

Vercel AI SDK RSC: Server-Rendered React Components (The Framework)

Vercel AI SDK RSC takes a radically different approach. Instead of describing UI declaratively, the LLM triggers tool use calls that execute server-side functions, and those functions return actual React Server Components. The RSC stream delivers serialized JSX to the client, which hydrates it into interactive components.

typescript 
// Vercel AI SDK RSC approach
const result = await streamUI({
  model: openai("gpt-4o"),
  messages,
  tools: {
    showFlightCard: {
      parameters: z.object({ flight: z.string(), departure: z.string() }),
      generate: async function* ({ flight, departure }) {
        yield <FlightCardSkeleton />;
        const details = await getFlightDetails(flight);
        return <FlightCard details={details} departure={departure} />;
      },
    },
  },
});

This is powerful — but coupled to React, Next.js, and a trusted server environment. The LLM does not generate arbitrary JSX; it selects from pre-defined tools. But the rendering pipeline requires server-side execution and RSC streaming.

Architecture Deep Dive

The three approaches differ fundamentally in where rendering decisions are made and how UI data flows from agent to screen.

graph TB subgraph "A2UI Architecture" A1["Agent / LLM"] -->|"Generates"| A2["JSON Blueprint"] A2 -->|"Any Transport"| A3["Client Renderer"] A3 -->|"Maps to"| A4["Native Widgets - React / SwiftUI / Flutter"] end subgraph "AG-UI Architecture" B1["Agent Backend"] -->|"Emits"| B2["Event Stream - text, tool, state, lifecycle"] B2 -->|"SSE / WebSocket"| B3["Frontend SDK"] B3 -->|"Interprets"| B4["Application UI"] end subgraph "Vercel RSC Architecture" C1["LLM"] -->|"Tool call"| C2["Server Action"] C2 -->|"Returns JSX"| C3["RSC Stream"] C3 -->|"Hydration"| C4["React Client"] end

A2UI: Transport-Agnostic Rendering

A2UI's architecture is deliberately layered. The agent produces a JSON document conforming to the A2UI spec. This JSON can travel over any transport — HTTP, WebSockets, AG-UI events, or even MCP tool responses. The client renderer is a platform-specific library that maps A2UI component types to native widgets.

This transport-agnostic design means A2UI works equally well in a React web app, an iOS native app built with SwiftUI, or an Android app using Jetpack Compose. The same agent output renders natively everywhere. For more on how A2UI achieves this, see our A2UI Protocol Deep Dive.

AG-UI: Structured Event Streaming

AG-UI defines a precise event lifecycle. A run begins with RUN_STARTED, progresses through TEXT_MESSAGE_* and TOOL_CALL_* events, includes STATE_DELTA for shared state synchronization, and ends with RUN_FINISHED. This structure gives frontends fine-grained control over progressive rendering, loading states, and error handling.

The protocol supports both server-to-client streaming and client-to-server messages (user interruptions, confirmations), making it genuinely bidirectional. This is critical for human-in-the-loop agentic workflows where users need to approve tool executions or provide mid-stream input.

Vercel RSC: Server-Side Component Generation

Vercel's approach leverages React Server Components to blur the line between data fetching and rendering. When the LLM calls a tool, the corresponding server function can access databases, APIs, and secrets before returning a fully-rendered component. The client receives a serialized React tree and hydrates it without needing the raw data.

This is elegant for single-server architectures. However, it creates tight coupling: the rendering logic must execute in a Node.js RSC environment, the client must be React, and the server must be trusted (since it executes arbitrary code in response to LLM tool calls).

Head-to-Head Comparison

Dimension A2UI AG-UI Vercel AI SDK RSC
Approach Type Declarative UI format Event transport protocol Server-rendered framework
Core Question What to render How to deliver Where to render
Rendering Model Client-side mapping Application-defined Server-side generation
Cross-Platform ✅ Web, iOS, Android, Desktop ⚠️ Web-focused (SDK available) ❌ React/Next.js only
Multi-Agent ✅ Safe across trust boundaries ✅ Backend-agnostic ⚠️ Single-server assumed
Security Model Data-vs-code separation Trusted application code Trusted server execution
LLM Generation LLM outputs constrained JSON LLM outputs text/tool calls LLM triggers tool calls
Styling Control Client-side (full platform fidelity) Application-defined Server + client CSS
Transport Any (HTTP, WS, AG-UI, MCP) SSE / custom RSC stream (HTTP)
Spec Type Open specification Open protocol Proprietary SDK
Production Status Early but backed by Google Stable (CopilotKit ecosystem) ⚠️ Experimental (Vercel's own docs)
Best For Universal agent UI Real-time agent communication Next.js rapid prototyping

Security Analysis

Security is the dimension where these three approaches diverge most sharply. In a world where agents are increasingly autonomous and multi-agent systems are becoming standard, the question is: what can a malicious or compromised agent do to your UI?

A2UI: Data-vs-Code Separation

A2UI's security model is structural. The JSON payload contains component descriptions — data — but never executable code. A client renderer has a finite catalog of supported component types. If an agent emits { "type": "evil_script", "code": "..." }, the renderer simply ignores it.

This makes A2UI the only approach where you can safely render UI from an untrusted remote agent. In a multi-agent system orchestrated through A2A (Agent-to-Agent) communication, a sub-agent running on a third-party server can send A2UI payloads to the host application without any risk of code injection.

code 
Untrusted Agent → A2UI JSON → ✅ Safe: client ignores unknown types
Untrusted Agent → Vercel RSC → ❌ Not applicable: requires server trust
Untrusted Agent → AG-UI Events → ⚠️ Safe if app code validates events

Vercel AI SDK RSC: Trusted Server

Vercel RSC's security assumption is that the server is trusted. Tool functions execute server-side code, access secrets, and return rendered components. This is secure when you control the server — but it means you cannot render UI from an agent you do not fully trust.

AG-UI: Trusted Application Code

AG-UI's security depends on the application code that interprets events. The protocol itself is a transport — it does not enforce what happens when a TOOL_CALL event arrives. If the application blindly executes tool calls from untrusted agents, it is vulnerable. If it validates and sandboxes, it is safe.

Cross-Platform and Multi-Agent

Cross-platform support is where A2UI's architectural advantage becomes decisive. Consider a multi-agent travel planning system:

graph LR User["User"] --> Host["Host Agent"] Host --> FA["Flight Agent - Remote"] Host --> HA["Hotel Agent - Remote"] Host --> RA["Restaurant Agent - Local"] FA -->|"A2UI JSON"| Host HA -->|"A2UI JSON"| Host RA -->|"A2UI JSON"| Host Host -->|"Composed A2UI"| WR["Web Renderer - React"] Host -->|"Composed A2UI"| MR["Mobile Renderer - SwiftUI"] Host -->|"Composed A2UI"| DR["Desktop Renderer - Electron"]

Each remote agent produces A2UI JSON. The host agent composes these into a unified layout. Platform-specific renderers display native widgets — a card becomes a <Card> in React, a CardView in SwiftUI, and a Card composable in Jetpack Compose.

Try achieving this with Vercel RSC: you would need a Next.js server per agent and a React client everywhere. With AG-UI alone, you would need to define your own UI format. The combination of A2UI format + AG-UI transport + native renderers is the architecture the ecosystem is converging on.

For a comprehensive view of multi-agent architectures, see our Multi-Agent System Complete Guide.

The Complementarity Insight

The most important realization is that A2UI and AG-UI are not competitors. They solve different layers:

Layer Protocol Role
Format A2UI Defines the UI component tree (the payload)
Transport AG-UI Delivers events including UI payloads (the pipe)
Renderer Platform SDK Converts A2UI JSON to native widgets (the display)

CopilotKit recognized this immediately and shipped first-class A2UI integration. You can scaffold a project that combines both:

bash 
npx copilotkit@latest create my-app --framework a2ui

The combined architecture looks like this:

sequenceDiagram participant Agent as Agent Backend participant AGUI as AG-UI Transport participant Client as Client App participant Renderer as A2UI Renderer Agent->>AGUI: TOOL_CALL_START (render_ui) Agent->>AGUI: TOOL_CALL_ARGS (A2UI JSON payload) Agent->>AGUI: TOOL_CALL_END AGUI->>Client: Event stream Client->>Renderer: Parse A2UI JSON Renderer->>Client: Native component tree Note over Client: User interacts with rendered UI Client->>AGUI: User action event AGUI->>Agent: Action callback

In this architecture, the agent emits A2UI JSON as the arguments of a tool call. AG-UI transports the tool call event (with streaming deltas) to the frontend. The frontend extracts the A2UI payload and passes it to a platform-specific renderer. User interactions flow back through AG-UI events to the agent.

This is not theoretical — it is how CopilotKit's A2UI integration works in production today.

When to Choose What

Choose A2UI When:

  • You need cross-platform rendering (web + mobile + desktop)
  • You operate in a multi-agent environment with agents from different trust domains
  • Security is paramount — you cannot allow code execution from remote agents
  • You want a future-proof format as the ecosystem converges on a standard
  • You are building a platform that hosts third-party agents

Choose AG-UI When:

  • You need real-time bidirectional communication between agents and frontends
  • You are already using CopilotKit and want structured event handling
  • Your application requires shared state synchronization between agent and UI
  • You need human-in-the-loop controls (approve, reject, interrupt)
  • You want a transport layer that is backend-framework agnostic

Choose Vercel AI SDK (UI, not RSC) When:

  • You are building exclusively in Next.js/React
  • You have a single agent with a trusted server
  • You want the fastest time to demo with minimal boilerplate
  • Your UI needs are simple (chat + a few custom components)
  • You need production stability (AI SDK UI is stable; RSC is experimental)

Choose A2UI + AG-UI When:

  • You are building a production multi-agent system with rich UI
  • You need both cross-platform rendering and real-time streaming
  • You want the most architecturally sound separation of concerns
  • You are building for enterprise where security audits matter

To validate your agent's JSON output against the A2UI schema, tools like JSON Formatter can help you inspect and debug the payloads during development. For data flowing through AG-UI event streams, a JSON Diff tool is useful for comparing state deltas across events.

The Convergence Trend

The agent UI space is converging rapidly. Several signals point toward A2UI becoming the universal format standard:

Vercel's json-renderer PoC. Vercel released a proof-of-concept that renders A2UI component catalogs using Zod schemas for type-safe validation. This acknowledges that even within the React ecosystem, a declarative JSON format has value — especially for LLM-generated UI where structured output is more reliable than free-form JSX.

CopilotKit's A2UI Integration. CopilotKit did not treat A2UI as a competitor to AG-UI. Instead, they shipped a first-class integration, demonstrating the complementarity thesis in production code.

Oracle Agent Spec. Oracle's Agent Specification references declarative UI patterns compatible with A2UI, signaling enterprise adoption of the declarative approach.

AWS Bedrock AgentCore. Amazon's AgentCore infrastructure supports multiple agent protocols and is designed to be UI-format-agnostic — a natural fit for A2UI's transport-agnostic design.

Google's Backing. A2UI emerged from Google's DeepMind and Flutter teams, with cross-references in the A2A (Agent-to-Agent) protocol spec. Google's multi-platform heritage (Android, Web, Flutter, Fuchsia) makes a cross-platform UI format a strategic priority.

The trajectory is clear: A2UI as the format standard, AG-UI as one of several transport options, and platform-specific renderers handling the last mile. Vercel AI SDK will likely add native A2UI support rather than competing with a React-only approach.

For a deeper understanding of how MCP fits into this evolving ecosystem as the tool-and-context layer beneath these UI protocols, see our MCP Protocol Complete Guide.

FAQ

What is the difference between A2UI and AG-UI?

A2UI is a declarative UI format — it defines what to render using JSON component descriptions. AG-UI is an event-based transport protocol — it defines how to deliver messages between agent backends and frontends. They are complementary: AG-UI can carry A2UI payloads as tool call arguments. A2UI focuses on cross-platform native rendering and security through data-vs-code separation, while AG-UI focuses on real-time bidirectional communication with text streaming, tool calls, and state synchronization.

Should I use A2UI or Vercel AI SDK for generative UI?

Choose A2UI if you need cross-platform support (web, mobile, desktop), multi-agent scenarios, or security across trust boundaries. Choose Vercel AI SDK RSC if you are building exclusively in Next.js/React and want the simplest integration with server-rendered components. Note that Vercel marks AI SDK RSC as experimental and recommends AI SDK UI for production workloads. For most new projects in 2026, A2UI is the safer long-term bet.

Can A2UI and AG-UI be used together?

Yes, they are explicitly designed to be complementary. AG-UI serves as the transport layer (the pipe) while A2UI serves as the UI format (the payload). CopilotKit already offers a production-ready A2UI integration:

bash 
npx copilotkit@latest create my-app --framework a2ui

This scaffolds a project with AG-UI transport delivering A2UI payloads to a React renderer.

Which agent UI approach is best for production in 2026?

For cross-platform production deployments with multiple agents, A2UI with AG-UI transport is the most robust choice. For React-only apps with a single agent, Vercel AI SDK UI (the stable variant, not RSC) is production-ready and simpler to integrate. The ecosystem is converging toward A2UI as the universal format standard, so investing in A2UI today provides the best long-term flexibility.

Does Vercel AI SDK support A2UI?

Vercel has released a json-renderer proof of concept that supports A2UI catalogs via Zod schemas. This is not yet a first-class SDK feature, but it signals convergence — even Vercel recognizes the need for a declarative UI format alongside its server-rendered approach. Expect deeper integration in future AI SDK releases.

Summary

The agent UI problem has three layers — format, transport, and rendering — and the three leading approaches each address a different layer. A2UI defines the universal format. AG-UI defines the real-time transport. Vercel AI SDK RSC provides a React-specific rendering shortcut.

For teams building production multi-agent systems that must work across platforms and trust boundaries, A2UI + AG-UI is the architecture to adopt. For teams working exclusively in Next.js with a single trusted agent, Vercel AI SDK UI remains the path of least resistance — but watch for A2UI integration to arrive in the SDK soon.

The convergence is happening. The question is not which approach will win — it is how quickly the ecosystem unifies around the layered architecture that combines all three strengths. Choose your layer, and build accordingly.