DEV Community

Cover image for AG-UI & A2UI: Building Agent-Powered Interfaces Beyond Chat
Serif COLAKEL
Serif COLAKEL

Posted on

AG-UI & A2UI: Building Agent-Powered Interfaces Beyond Chat

#agents #ai #productivity #programming

How event-driven agent interactions and generative UI are changing the way we build AI-powered frontend applications.

1. Why Are Chat Interfaces No Longer Enough?

Most AI applications start with a familiar interface: a text input, a message history, and a streaming response.

This works well for question answering, summarization, and conversational experiences. However, agent-based applications introduce a different set of interaction requirements.

Consider an AI assistant that analyzes a user's investment portfolio, investigates market movements, or prepares a technical report.

A conventional chat interface might return a response containing:

  • A summary of the analysis
  • A list of recommendations
  • Several data points
  • A suggested next action

But what if the user needs more than a textual response?

What if the application needs to display:

  • Interactive charts
  • Dynamic forms
  • Data tables
  • Approval workflows
  • Progress indicators
  • Context-aware actions
  • Multi-step interfaces that evolve as the agent works

We could build every possible interface in advance and ask the model to select the appropriate components. This approach works for predictable workflows, but it becomes restrictive when the interaction itself is dynamic.

Another option is to allow the model to generate HTML, React components, or JavaScript directly. However, executing arbitrary model-generated code introduces significant security, maintainability, and governance challenges.

This is where two interesting technologies enter the picture:

AG-UI (Agent-User Interaction Protocol) and A2UI (Agent-to-User Interface).

Although their names are similar, they address different problems.

AG-UI standardizes how agents communicate with user-facing applications. A2UI provides a declarative format for describing interfaces that client applications can safely render using their own component libraries.

Together, they provide an interesting foundation for building agent-powered applications beyond traditional chat interfaces.

References: AG-UI Documentation · Google A2UI

2. What Is AG-UI?

AG-UI stands for Agent-User Interaction Protocol.

It is an open, lightweight, event-based protocol designed to standardize communication between AI agents and frontend applications.

The underlying problem is straightforward.

An agent does not always produce one response and finish. It may execute multiple tools, delegate work, update its state, request additional input, and continue processing.

A traditional request-response model does not necessarily represent these interactions well.

For example, imagine an agent performing a database analysis:

  1. The user requests an analysis.
  2. The agent starts executing the task.
  3. It calls a database tool.
  4. The query completes.
  5. The agent processes the returned data.
  6. It generates a chart.
  7. It asks the user to confirm an additional filter.
  8. It completes the analysis.

If the frontend only receives the final response, the user has no visibility into what happened during execution.

We could implement custom WebSocket messages, HTTP streaming events, and application-specific state synchronization. But every application would need to define and maintain its own communication contract.

AG-UI provides a standardized event model for this interaction.

It allows agent backends to communicate execution events, messages, tool calls, state changes, and activity updates to the frontend.

The protocol is intentionally not tied to one agent framework or frontend technology.

You can build the backend using LangGraph, Google ADK, CrewAI, or a custom runtime, while the frontend uses React or another supported client implementation.

The important point is that AG-UI does not define how an agent reasons or executes its internal logic. It defines how that execution is communicated to the user-facing application.

Reference: AG-UI — Introduction

3. How Does AG-UI Work?

AG-UI follows an event-driven architecture.

Instead of treating an agent interaction as a single response, the backend emits a sequence of typed events that the frontend consumes.

A simplified architecture looks like this:

                 User
                   |
                   v
             React Application
                   |
                   v
               AG-UI Client
                   |
            Event Stream / SSE
                   |
                   v
              Agent Runtime
                   |
          +--------+--------+
          |        |        |
          v        v        v
        LLM      Tools    Subagents
          |        |        |
          +--------+--------+
                   |
                   v
             Agent Events
                   |
                   v
              AG-UI Client
                   |
                   v
              Update UI
Enter fullscreen mode Exit fullscreen mode

The frontend and backend have separate responsibilities.

Backend responsibilities:

  • Execute agent logic.
  • Handle model interactions.
  • Execute tools.
  • Maintain execution state.
  • Emit standardized events.
  • Handle additional user input and resume interactions.

Frontend responsibilities:

  • Initiate agent runs.
  • Consume event streams.
  • Render messages and activity updates.
  • Synchronize application state.
  • Present tool activity.
  • Handle user interactions and approvals.

AG-UI is transport-agnostic. Common integration patterns include Server-Sent Events (SSE), WebSockets, and webhooks.

The official HttpAgent client supports HTTP SSE and an HTTP binary transport.

This separation means we do not have to make frontend components understand the implementation details of the backend agent framework.

Reference: AG-UI — Core Architecture

4. Understanding AG-UI Events

Events are the foundation of AG-UI.

Rather than sending an unstructured text response, an agent can communicate different types of events depending on what is happening during execution.

The main event categories include:

4.1. Lifecycle Events

These events describe the execution lifecycle.

Event Purpose
RUN_STARTED An agent run has started
RUN_FINISHED An agent run has finished
RUN_ERROR An execution error occurred
STEP_STARTED A new execution step started
STEP_FINISHED An execution step finished

This allows the frontend to display meaningful execution states instead of relying on a generic loading indicator.

4.2. Text Message Events

These events represent streaming messages.

Event Purpose
TEXT_MESSAGE_START Starts a message
TEXT_MESSAGE_CONTENT Sends a text chunk
TEXT_MESSAGE_END Completes a message

The frontend can append each text chunk as it arrives.

This provides a familiar streaming experience while keeping the underlying event structure explicit.

4.3. Tool Call Events

Tool execution is an important part of agent workflows.

AG-UI defines events such as:

  • TOOL_CALL_START
  • TOOL_CALL_ARGS
  • TOOL_CALL_END
  • TOOL_CALL_RESULT

These events allow the frontend to display which tool is being used and follow its execution lifecycle.

For example, an interface might display:

Analyzing repository...
    |
    v
GitLab: Fetching merge request
    |
    v
Code Review: Analyzing changes
    |
    v
Security Check: Completed
    |
    v
Generating report
Enter fullscreen mode Exit fullscreen mode

One distinction is important: receiving a tool-call event does not automatically mean the frontend should execute that tool. Tool execution and authorization remain responsibilities of the appropriate runtime or application layer.

4.4. State Management Events

AG-UI also defines events for synchronizing application and agent state.

Event Purpose
STATE_SNAPSHOT Sends a complete state snapshot
STATE_DELTA Sends incremental state changes
MESSAGES_SNAPSHOT Synchronizes conversation history

For example, an agent might update the current analysis status:

{
  "type": "STATE_SNAPSHOT",
  "snapshot": {
    "status": "analyzing",
    "completedSteps": 3,
    "totalSteps": 5,
    "currentTask": "Evaluating transaction data"
  }
}
Enter fullscreen mode Exit fullscreen mode

The frontend can consume this state and update progress indicators, dashboards, or other components.

4.5. Activity and Subagent Events

Modern agent systems often involve multiple agents working together.

AG-UI includes activity and subagent-related events, allowing a frontend to represent more complex execution patterns.

For example:

  • A research agent starts working.
  • A data analysis agent receives a delegated task.
  • The security agent completes its review.
  • The coordinator produces the final result.

This makes it possible to build interfaces that expose useful execution activity without requiring users to understand the internal implementation of each agent.

The current AG-UI v1.0 schema documents event families for lifecycle, text, tools, state, activity, subagents, reasoning, and custom events.

A critical implementation consideration: reasoning-related events should not be treated as permission to expose raw model chain-of-thought. User-facing applications should expose approved progress summaries and operational status instead.

Reference: AG-UI — Event Types and Specification

5. How to Integrate AG-UI with a React Application

AG-UI provides a TypeScript SDK that can be used to connect frontend applications to compatible agent endpoints.

The official package is @ag-ui/client.

Step 1: Install the package 

pnpm add @ag-ui/client @ag-ui/core
Enter fullscreen mode Exit fullscreen mode

Step 2: Create an HTTP agent

The HttpAgent class provides a client for communicating with an AG-UI-compatible backend.

import { HttpAgent } from '@ag-ui/client';

const agent = new HttpAgent({
  url: '/api/agent',
  agentId: 'portfolio-assistant',
  threadId: crypto.randomUUID(),
});
Enter fullscreen mode Exit fullscreen mode

The configuration defines the backend endpoint and identifies the agent and conversation thread.

Step 3: Send a message and consume events

We can use the agent's addMessage and runAgent methods to start an interaction.

import { HttpAgent } from '@ag-ui/client';
import { EventType } from '@ag-ui/core';

const agent = new HttpAgent({
  url: '/api/agent',
  agentId: 'portfolio-assistant',
  threadId: crypto.randomUUID(),
});

agent.addMessage({
  id: crypto.randomUUID(),
  role: 'user',
  content: 'Analyze my portfolio and summarize its performance.',
});

await agent.runAgent(
  {
    tools: [],
    context: [],
  },
  {
    onEvent: ({ event }) => {
      switch (event.type) {
        case EventType.RUN_STARTED:
          console.log('Agent execution started');
          break;

        case EventType.TEXT_MESSAGE_CONTENT:
          console.log(event.delta);
          break;

        case EventType.TOOL_CALL_START:
          console.log('Tool started:', event.toolCallName);
          break;

        case EventType.RUN_FINISHED:
          console.log('Agent execution completed');
          break;

        case EventType.RUN_ERROR:
          console.error('Agent execution failed');
          break;
      }
    },
  },
);
Enter fullscreen mode Exit fullscreen mode

The example demonstrates the client-side event handling pattern. In a complete application, event handlers would update React state, render tool activity, and maintain conversation state.

The agent SDK also supports shared state, event subscriptions, middleware, and cancellation through abortRun().

Step 4: Synchronize agent state with React

One of the most useful capabilities is the ability to keep frontend and agent state synchronized.

For example, an agent can update task progress while the frontend renders the current status.

With a framework integration such as CopilotKit, this can be implemented through hooks such as useAgent.

Conceptually:

import { useAgent } from '@copilotkit/react-core/v2';

function TaskProgress() {
  const { agent } = useAgent();

  const progress = agent.state.progress ?? {
    completed: 0,
    total: 0,
  };

  return (
    <section>
      <h3>Agent Progress</h3>

      <p>
        {progress.completed} / {progress.total} completed
      </p>
    </section>
  );
}
Enter fullscreen mode Exit fullscreen mode

The component reacts to changes in the agent's shared state.

The important architectural detail is that AG-UI defines the communication contract, while libraries such as CopilotKit provide additional frontend integration and application-level abstractions.

We are not required to use CopilotKit to implement AG-UI. A custom frontend can consume the protocol directly.

References: AG-UI TypeScript SDK · CopilotKit Shared State

6. What Is A2UI?

AG-UI solves the communication problem, but there is another question:

What if an agent needs to generate an actual user interface instead of returning text?

A2UI stands for Agent-to-User Interface.

It is an open-source project initiated by Google that provides a declarative protocol for generating and updating user interfaces from structured JSON messages.

The central idea is simple.

Instead of asking an LLM to generate HTML, JavaScript, or React code, we let it describe what the interface should contain.

For example, an agent may want to display:

  • A title
  • A summary card
  • A table
  • A date picker
  • A confirmation button

It can describe these elements using A2UI messages.

The frontend then maps those descriptions to its own approved components.

This creates a separation between UI generation and UI execution.

The agent describes the interface. The application decides how that interface is rendered.

Why is this important?

Imagine allowing an LLM to generate the following:

function Dashboard() {
  // Arbitrary model-generated code
}
Enter fullscreen mode Exit fullscreen mode

Executing model-generated React code directly would create substantial security and maintenance problems.

Instead, we can let the model return structured data:

{
  "component": "Card",
  "children": [
    {
      "component": "Text",
      "text": "Portfolio Summary"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

The frontend maps Card and Text to components that already exist in its design system.

The model never needs to execute arbitrary JavaScript to create the interface.

This is the main architectural idea behind A2UI.

Reference: Google A2UI — Official Documentation

7. How Does A2UI Work?

A2UI uses a JSON-based streaming protocol.

The agent sends messages to the frontend, and the frontend processes those messages to create or update UI surfaces.

A2UI v0.9.1 defines four primary message types.

7.1. createSurface

Creates a new UI surface.

A surface represents a UI region that contains components and associated data.

{
  "version": "v0.9.1",
  "createSurface": {
    "surfaceId": "portfolio-dashboard",
    "catalogId": "https://a2ui.org/specification/v0_9_1/catalogs/basic/catalog.json"
  }
}
Enter fullscreen mode Exit fullscreen mode

7.2. updateComponents

Defines or updates the components within a surface.

The components are represented as a flat list with references that define their relationships.

For example:

{
  "version": "v0.9.1",
  "updateComponents": {
    "surfaceId": "portfolio-dashboard",
    "components": [
      {
        "id": "root",
        "component": "Column",
        "children": [
          "title",
          "summary"
        ]
      },
      {
        "id": "title",
        "component": "Text",
        "text": "Portfolio Overview",
        "variant": "h1"
      },
      {
        "id": "summary",
        "component": "Text",
        "text": "Your portfolio analysis is ready."
      }
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

The renderer understands the component definitions and constructs the corresponding UI tree.

7.3. updateDataModel

Updates the data displayed by the components.

A2UI separates component structure from application data.

This is particularly useful because changing data does not necessarily require sending the entire component tree again.

For example:

{
  "version": "v0.9.1",
  "updateDataModel": {
    "surfaceId": "portfolio-dashboard",
    "path": "/portfolio",
    "value": {
      "totalValue": 125000,
      "currency": "USD",
      "change": 4.2
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Components can reference values in the data model using JSON Pointer paths.

When the data model changes, the renderer can update the relevant parts of the interface.

7.4. deleteSurface

Removes a previously created surface and its associated components and data.

{
  "version": "v0.9.1",
  "deleteSurface": {
    "surfaceId": "portfolio-dashboard"
  }
}
Enter fullscreen mode Exit fullscreen mode

This is useful for managing dynamic UI regions as an interaction evolves.

The complete flow 

User Request
     |
     v
Agent Runtime
     |
     v
LLM Generates A2UI Messages
     |
     v
    JSON Stream
     |
     v
A2UI Message Processor
     |
     v
Component Catalog
     |
     v
React / Flutter / Angular Renderer
     |
     v
Interactive User Interface
Enter fullscreen mode Exit fullscreen mode

The process can happen incrementally.

The agent can create a surface first, add components later, and update the data model as more information becomes available.

This is different from generating an entire interface in one response.

References: A2UI Protocol v0.9.1 · A2UI Quickstart

8. Integrating A2UI with React

A2UI provides an official React renderer and a shared web core library.

The relevant packages are:

  • @a2ui/react
  • @a2ui/web_core

Step 1: Install the packages 

pnpm add @a2ui/react @a2ui/web_core
Enter fullscreen mode Exit fullscreen mode

Step 2: Create a MessageProcessor

The MessageProcessor handles protocol messages, surface lifecycle, component definitions, and data models.

For the v0.9 implementation:

import { useState } from 'react';

import {
  MessageProcessor,
} from '@a2ui/web_core/v0_9';

import {
  A2uiSurface,
  basicCatalog,
} from '@a2ui/react/v0_9';
Enter fullscreen mode Exit fullscreen mode

The processor is initialized with the component catalog that the application allows the agent to use.

const processor = new MessageProcessor([
  basicCatalog,
]);
Enter fullscreen mode Exit fullscreen mode

Step 3: Process agent-generated messages

For example, we can create a surface and populate it with components:

processor.processMessages([
  {
    version: 'v0.9',
    createSurface: {
      surfaceId: 'main',
      catalogId: basicCatalog.id,
    },
  },
  {
    version: 'v0.9',
    updateComponents: {
      surfaceId: 'main',
      components: [
        {
          id: 'root',
          component: 'Column',
          children: ['heading', 'description'],
        },
        {
          id: 'heading',
          component: 'Text',
          text: 'Hello from A2UI',
          variant: 'h1',
        },
        {
          id: 'description',
          component: 'Text',
          text: 'This interface was described by an agent.',
        },
      ],
    },
  },
]);
Enter fullscreen mode Exit fullscreen mode

The MessageProcessor maintains the surface and its component model.

Step 4: Render the surface

Once the surface has been created, the React renderer can display it.

function DynamicUI() {
  const [processor] = useState(() => {
    const instance = new MessageProcessor([
      basicCatalog,
    ]);

    instance.processMessages([
      {
        version: 'v0.9',
        createSurface: {
          surfaceId: 'main',
          catalogId: basicCatalog.id,
        },
      },
      {
        version: 'v0.9',
        updateComponents: {
          surfaceId: 'main',
          components: [
            {
              id: 'root',
              component: 'Column',
              children: ['title'],
            },
            {
              id: 'title',
              component: 'Text',
              text: 'Generated Interface',
              variant: 'h1',
            },
          ],
        },
      },
    ]);

    return instance;
  });

  const surface = processor.model.surfacesMap.get('main');

  if (!surface) {
    return <p>Preparing interface...</p>;
  }

  return <A2uiSurface surface={surface} />;
}
Enter fullscreen mode Exit fullscreen mode

This is a minimal rendering example. A production implementation should create and manage the processor at the appropriate application or session scope, rather than reconstructing it for each update.

As new A2UI messages arrive, the application can pass them to the same processor. The surface model drives the React renderer's updates.

Step 5: Handle user interactions

An interactive UI needs a return path.

For example, the agent may generate a form containing a confirmation button.

When the user clicks that button, the frontend captures the associated action and sends it back to the agent through the selected transport.

The flow becomes:

Agent Generates UI
       |
       v
A2UI Renderer
       |
       v
User Interacts
       |
       v
Frontend Captures Action
       |
       v
Application / Agent Endpoint
       |
       v
Agent Processes Input
       |
       v
New A2UI Messages
       |
       v
Updated Interface
Enter fullscreen mode Exit fullscreen mode

A2UI v0.9.1 uses an external communication channel for these return interactions. Its v1.0 candidate specification introduces additional structured function-call and response mechanisms.

This distinction matters when designing the frontend-backend contract.

References: A2UI React Renderer · A2UI Client Setup

9. What Is the Difference Between AG-UI and A2UI?

This is probably the most important distinction in the article.

AG-UI and A2UI are complementary, but they are not interchangeable.

Area AG-UI A2UI
Primary purpose Agent-frontend communication Declarative UI generation
Main abstraction Typed events UI surfaces and components
Data flow Run events and state updates UI structure and data updates
Main responsibility Interaction lifecycle Interface representation
Frontend role Consume and handle events Render approved components
User interaction Agent runs, tools, state and interrupts UI actions and data context

Consider an agent that needs to create a dynamic approval dashboard.

AG-UI can communicate:

  • The agent has started processing.
  • The data retrieval step is complete.
  • A tool has returned results.
  • The agent has updated its state.
  • A user approval is required.

A2UI can describe:

  • An approval summary card.
  • A table of requested changes.
  • A confirmation button.
  • A detailed information panel.

The frontend can render both the interaction lifecycle and the generated interface.

Can we use them together?

Yes.

A possible architecture looks like this:

                User
                  |
                  v
            React Frontend
                  |
                  v
               AG-UI
             Event Stream
                  |
                  v
             Agent Runtime
                  |
                  v
                 LLM
                  |
            +-----+-----+
            |           |
            v           v
        AG-UI Events   A2UI JSON
            |           |
            +-----+-----+
                  |
                  v
            Frontend Host
                  |
                  v
            A2UI Renderer
                  |
                  v
           Native React UI
Enter fullscreen mode Exit fullscreen mode

AG-UI manages the interaction boundary. A2UI describes the interface that should be rendered.

One protocol does not replace the other.

A2UI can also be transported over A2A, MCP-related integrations, SSE, or WebSockets. It is designed to remain independent of a particular transport.

References: AG-UI Architecture · A2UI Transport Decoupling

10. How Do They Fit Into the Existing AI Ecosystem?

We have already discussed MCP, ACP, and A2A in previous articles.

Adding AG-UI and A2UI gives us another important architectural layer.

Technology Responsibility
MCP Agent ↔ Tools and external data
ACP Coding Agent ↔ Client Application
A2A Agent ↔ Agent
AG-UI Agent ↔ Frontend interaction
A2UI Agent → Declarative UI

A typical enterprise AI platform could use several of these technologies simultaneously.

For example:

  1. An application communicates with an agent using AG-UI.
  2. The agent accesses internal services through MCP.
  3. The agent delegates a specialized task to another agent using A2A.
  4. The agent returns dynamic interface definitions using A2UI.
  5. The application renders those definitions through its own component system.

ACP can be used independently when we need to integrate coding agents with a client application.

This is not about adopting every protocol. It is about keeping architectural boundaries clear.

11. How Do These Approaches Compare With Traditional Generative UI?

AG-UI and A2UI are not the only ways to build agent-powered interfaces.

There are several approaches worth understanding.

AI SDK Tool-Based UI

Vercel AI SDK already allows applications to render custom UI based on tool calls and structured message parts.

For example, a model can call a weather tool, and the frontend can render a weather card instead of displaying only raw text.

This is a good approach when:

  • The application has a known set of components.
  • UI behavior is closely tied to model tool calls.
  • The application owns the entire interaction contract.

However, it does not automatically provide the same cross-framework UI specification and agent interaction model as AG-UI and A2UI.

MCP Apps

MCP Apps extend MCP tools with interactive UI experiences.

A tool can expose a ui:// resource containing its interface, which an MCP host can render in a sandboxed iframe.

This is particularly useful when a tool needs to provide its own interactive experience, such as a dashboard, form, or specialized workflow.

It solves a different problem from A2UI: the UI is associated with a tool rather than being a general declarative UI surface generated by an agent.

A2UI

A2UI focuses on agent-generated interface descriptions and framework-specific rendering.

The same declarative description can be consumed by compatible clients with different native component implementations.

AG-UI

AG-UI focuses on the interaction protocol rather than the visual representation.

It can be used with ordinary chat interfaces, custom React components, or declarative generative UI approaches.

Approach Best suited for
AI SDK Tool UI Application-defined component rendering
MCP Apps Interactive UIs provided by individual tools
A2UI Agent-generated, declarative interfaces
AG-UI Standardized agent-frontend communication

These approaches are not mutually exclusive.

References: AI SDK — useChat · Vercel — MCP Apps Integration · Google A2UI

12. Advantages and Trade-offs

Introducing these technologies can improve architecture and developer experience, but they also introduce new responsibilities.

AG-UI Advantages

Standardized event communication

Teams can consume a consistent event model instead of maintaining separate custom streaming contracts.

Frontend-backend separation

The frontend does not need to understand the internal implementation of each agent framework.

Better visibility into execution

Tool calls, progress updates, and agent state can be represented in the UI.

Framework interoperability

Different backend agent implementations can expose a common interaction contract.

Support for human-in-the-loop workflows

Applications can build approval, clarification, and user-steering experiences around agent execution.

AG-UI Trade-offs

  • Existing agent frameworks may require adapters or event translation.
  • Teams must manage protocol versions and event compatibility.
  • Application state and agent state can become inconsistent if ownership is unclear.
  • Authentication, authorization, and event validation remain application responsibilities.
  • For simple chat applications, a custom endpoint or ordinary AI SDK integration may be sufficient.

A2UI Advantages

Declarative and safer UI generation

Agents send structured data rather than executable React or JavaScript code.

Framework independence

The same UI description can be mapped to different client-side component systems.

Reuse of existing design systems

Applications can expose their own approved component catalog.

Incremental rendering

The UI structure and data can be updated without resending everything.

Separation of structure and data

Components can remain stable while the agent updates the underlying data model.

A2UI Trade-offs

  • A component catalog must be designed and maintained.
  • The renderer must support the required component types.
  • Complex application-specific interactions require additional integration.
  • Schema and protocol version compatibility require attention.
  • Debugging streamed component updates can be more difficult than debugging ordinary React components.
  • Cross-platform rendering does not guarantee identical visual behavior on every platform.

An important point: declarative JSON is safer than arbitrary executable code, but it is not automatically trustworthy.

The application must still validate messages, restrict available components, and authorize actions.

13. Security and Production Considerations

This is where the difference between a successful demo and a maintainable production implementation becomes important.

1. Never execute arbitrary generated code

An agent should not be able to send arbitrary JavaScript, HTML, or React code and have the application execute it.

A2UI's declarative component catalog provides a safer approach.

The application should only render components it explicitly supports.

2. Validate incoming messages

AG-UI events and A2UI messages must be treated as untrusted input.

Validate event structures, protocol versions, component definitions, data paths, and payload sizes before processing them.

3. Control available components

Not every component should be available to an agent.

For example, an internal banking application might allow:

  • Summary cards
  • Data tables
  • Charts
  • Read-only forms
  • Approval request components

However, a sensitive transaction operation should not become available merely because the agent can generate a button.

The backend must authorize the actual business operation.

4. Keep application state under application control

There should be a clear distinction between UI state, agent state, and authoritative business state.

An agent-generated UI should not be considered a source of truth for financial transactions, permissions, or other business-critical information.

5. Require human approval for sensitive actions

A dynamically generated interface can make it easier for an agent to request user confirmation.

However, the approval must be verified on the backend. Hiding or disabling a frontend button is not an authorization mechanism.

6. Handle interrupted streams and reconnection

Streaming applications need predictable recovery behavior.

Consider:

  • Reconnecting after network failures
  • Handling duplicate events
  • Recovering from incomplete UI updates
  • Preserving task and surface identifiers
  • Handling cancellation
  • Expiring stale sessions

AG-UI and A2UI define communication structures, but the application still needs an operational strategy for stream recovery and state consistency.

7. Audit agent-generated interactions

For enterprise applications, it should be possible to understand:

  • Which agent generated a UI.
  • Which components were requested.
  • Which actions the user performed.
  • Which backend operations were executed.
  • Whether an approval was obtained.
  • What the final result was.

This is particularly important when AI interfaces are used to interact with internal business systems.

14. What Can an AI Chapter Lead Contribute?

I believe this is where these technologies become particularly valuable.

The opportunity is not simply introducing generative UI into an application. It is establishing a reusable frontend-agent architecture that product teams can build on.

1. Establish a Shared Agent-Frontend Integration Layer

Instead of every team implementing its own event handling and agent-state synchronization, we can define a shared integration layer based on AG-UI.

It can provide:

  • Event subscription and processing
  • Streaming message handling
  • Tool execution indicators
  • State synchronization
  • Cancellation and error handling
  • Human approval workflows

This reduces duplicated infrastructure across applications.

2. Create a Governed Component Catalog

A2UI introduces an interesting opportunity to connect agent capabilities with an organization's existing design system.

For example, we can define an approved component catalog:

Component Purpose
SummaryCard Display structured summaries
DataTable Render tabular information
LineChart Display time-series data
ApprovalPanel Present approval requests
DateRangePicker Collect date filters
StatusIndicator Display execution status

The agent can request these components, while the frontend maps them to existing React components.

This means teams can introduce dynamic interfaces without giving the model unrestricted access to the frontend codebase.

For organizations with established design systems, this could be particularly valuable.

3. Define Reusable Frontend Patterns

We can establish standard patterns for:

  • Agent progress indicators
  • Interactive forms
  • Approval interfaces
  • Dynamic dashboards
  • Multi-step workflows
  • Tool execution views
  • Subagent activity panels

These patterns can become shared components and examples that product teams reuse.

4. Standardize the Security Model

A shared approach should define which components agents can request, which actions require approval, and how the backend validates every operation.

This is especially important for applications interacting with sensitive business systems.

5. Build a Reference Implementation

A small reference application could demonstrate the complete interaction:

  1. A user asks an agent to analyze a dataset.
  2. The agent starts execution and sends AG-UI events.
  3. The frontend displays progress and activity.
  4. The agent generates an A2UI dashboard.
  5. The React renderer maps the description to approved components.
  6. The user modifies a filter or submits an action.
  7. The frontend sends the interaction back to the agent.
  8. The agent updates the interface with new results.

This would help developers understand how the protocols work together in a real application.

6. Measure the Developer and User Experience

We should not evaluate generative UI only by how quickly an agent can produce a visual result.

Useful metrics include:

  • Time to interactive UI
  • Agent-to-frontend event latency
  • UI schema validation failure rate
  • Unsupported component requests
  • Rendering errors
  • User interaction completion rate
  • Human approval rate
  • Frontend integration effort

These metrics can help determine whether generative UI actually improves the application experience.

15. What Is the Current State of A2UI and AG-UI?

Both projects are evolving, so protocol versioning matters.

As of November 1, 2026:

AG-UI

AG-UI publishes a versioned v1.0 specification and provides TypeScript client libraries, event schemas, and integrations with different agent frameworks.

Its ecosystem includes integrations with projects such as LangGraph, CrewAI, Google ADK, and other agent runtimes.

A2UI

A2UI currently identifies v0.9.1 as its production protocol release.

The v1.0 specification is a candidate release, not the production version.

The project also provides an official React renderer, shared web core, Lit renderer, Angular renderer, and Flutter-based support.

There is an important migration consideration: the v1.0 candidate introduces changes to the protocol model and should not be assumed to be wire-compatible with v0.9.1.

For production applications, I would start with the stable v0.9.1 protocol and its matching renderer, and evaluate v1.0 separately before planning a migration.

References: A2UI Repository and Status · A2UI Roadmap · AG-UI Specification

Conclusion

AG-UI and A2UI address two important challenges in building modern agent-powered applications.

AG-UI standardizes the interaction between agents and frontend applications through a structured, event-driven communication model.

A2UI allows agents to describe dynamic interfaces using declarative JSON messages, while applications remain in control of the actual components and rendering process.

Together, they make it possible to move beyond traditional chat interfaces and build applications where AI agents can communicate their progress, update application state, and generate context-aware user interfaces.

For engineering teams, the opportunity is to establish reusable interaction patterns, govern agent-accessible components, maintain security boundaries, and integrate generative UI into existing design systems.

My recommendation: Start with a small React application that uses AG-UI for streaming and state synchronization, then introduce A2UI for one clearly defined dynamic interface. Evaluate rendering reliability, security, and user experience before expanding the approach.

The goal should not be to make every screen dynamic.

It should be to make the interface adapt when a conversation or workflow genuinely requires it.

References and Further Reading

AG-UI

  1. AG-UI Official Documentation — Introduction, architecture, events, and integration.
  2. AG-UI GitHub Repository — Protocol implementation and SDKs.
  3. AG-UI Architecture — Event-driven architecture and client-server communication.
  4. AG-UI Event Reference — Lifecycle, messages, tools, and state events.
  5. AG-UI TypeScript SDK — Client implementation and event handling.

A2UI

  1. Google A2UI Official Documentation — Project overview and developer resources.
  2. A2UI Protocol v0.9.1 — JSON protocol, surfaces, components, and data models.
  3. A2UI Quickstart — Full-stack example and generated UI workflow.
  4. A2UI React Renderer — React rendering implementation.
  5. A2UI Client Setup — Framework integration and component catalogs.
  6. A2UI Renderer Development — Building custom renderers and integrating design systems.
  7. A2UI v1.0 Candidate Specification — Upcoming protocol capabilities and changes.

Related Technologies

  1. Vercel AI SDK — useChat — Conversational streaming and frontend state.
  2. Vercel — MCP Apps Integration — Interactive tool UIs in AI SDK applications.
  3. CopilotKit — Shared State — Bidirectional state synchronization between React and agents.

Top comments (0)