Generative UI for AI Agents: AG-UI Architecture, Streaming, Shared State, and Production Safety

Most AI applications still place a chat box beside an existing product and call the integration complete.

That interface works for questions and short answers. It becomes limiting when an agent must compare records, present a chart, collect structured input, request approval, show tool progress, resolve validation errors, or guide a user through a long-running business workflow.

Generative UI addresses this mismatch. Instead of returning only text, an agent can drive an interface composed from trusted application components: tables, forms, timelines, approval panels, charts, diffs, and workflow status views. The interface adapts to the task while the product retains control over security, design, accessibility, and business rules.

AG-UI, the Agent-User Interaction Protocol, provides an event-based contract between an agent backend and a user-facing application. It standardizes streaming messages, tool activity, state changes, interruptions, and other interactions that otherwise become custom integration code.

This guide explains where generative UI is useful, how AG-UI fits with MCP and agent-to-agent protocols, and how to build a production architecture without allowing model output to become arbitrary executable UI.

Why generative UI is becoming relevant now

AI agents produce variable workflows. One request may need a short answer. Another may require a five-step review, several data sources, an approval, and a structured result with dozens of records.

A static interface can model every known path, but the number of combinations grows as agents gain tools and operate across more business processes. A pure chat interface avoids that frontend complexity by forcing everything into text, but users lose the controls and information density of normal software.

Recent platform work reflects this shift. AWS demonstrated generative UI with AG-UI on Amazon Bedrock AgentCore and later published an architecture for adaptive AI interfaces with AG-UI. The protocol is designed to work across agent frameworks and frontend stacks instead of tying the interface to one model provider.

The useful idea is not that an agent should invent every pixel. It is that an agent can select and populate trusted interaction patterns according to the current task.

Static UI, chat, and generative UI solve different problems

These interface models should coexist.

Static application UI

Static UI is best for predictable, frequent, high-consequence workflows. Login, checkout, payment confirmation, account permissions, and core navigation should remain stable and extensively tested.

Users benefit from spatial memory and consistent controls. A familiar action should not move or change shape because a model generated a different composition.

Conversational UI

Chat is useful for ambiguous intent, exploration, explanation, and low-structure input. It lets the user describe an outcome without navigating a complex information architecture.

Chat becomes inefficient when the user needs to scan many results, compare alternatives, edit structured data, or understand the exact scope of an action.

Generative UI

Generative UI bridges natural-language intent and application controls. The agent can stream a task-specific view while the application renders known components and enforces normal product rules.

Good use cases include:

• reviewing invoice exceptions with evidence and approval controls;
• comparing cloud resources and proposed cost changes;
• investigating an incident with a live timeline and service metrics;
• reconciling records with side-by-side diffs;
• configuring an automation from a generated draft;
• presenting a variable number of compliance findings;
• collecting missing information through a validated form;
• monitoring a long-running agent workflow.

Generative UI is a poor fit when the workflow is already simple, stable, and safer as a fixed screen.

What AG-UI provides

AG-UI is an open, lightweight, event-based protocol for connecting agent backends to user-facing applications. The official AG-UI introduction describes it as the interaction layer between an agentic frontend and an agentic backend.

The protocol gives both sides a common vocabulary for events such as:

• run start and completion;
• streamed text content;
• tool-call start, arguments, results, and completion;
• state snapshots and incremental state changes;
• activity, progress, and lifecycle messages;
• interruptions that require user input or approval;
• custom events for application-specific behavior.

Without a protocol, teams commonly invent their own WebSocket messages, state patches, retry behavior, and tool rendering. Those contracts become difficult to evolve and couple the frontend to one agent framework.

AG-UI does not provide business authorization, safe component design, data governance, or workflow durability by itself. It is a transport and interaction contract around which those controls can be built.

AG-UI, A2UI, MCP, and A2A are not interchangeable

The agent ecosystem contains several protocol layers.

AG-UI: agent-to-user interaction

AG-UI carries the event stream between the frontend and the agent runtime. It supports messages, tool visibility, state synchronization, and human interaction.

A2UI: declarative interface description

A2UI and similar generative UI specifications describe interface structures that a client can render from a trusted component catalog. They concern what view should appear, while AG-UI concerns the broader interaction stream that connects the application and agent.

An AG-UI event may carry a declarative UI payload, but the two concepts remain distinct.

MCP: agent-to-tool integration

The Model Context Protocol exposes tools and resources to an agent. MCP can connect the agent to a CRM, database service, repository, or internal API. AG-UI exposes the resulting interaction to the user-facing application.

Our MCP security guide explains why tool authorization and data boundaries must remain outside model reasoning.

A2A: agent-to-agent communication

Agent-to-agent protocols support delegation and coordination across independent agents. The frontend usually should not connect directly to every specialized agent. An orchestrator can expose one coherent AG-UI session while coordinating other agents behind that boundary.

Protocols reduce integration friction, but they do not remove the need for architecture. Identity, authorization, state ownership, retries, observability, and compatibility still need explicit design.

Reference architecture

A production generative UI system usually has seven layers.

1. Trusted web or mobile client

The client authenticates the user, opens the event stream, renders approved components, captures interaction, and maintains accessible fallback states.

It should never execute arbitrary JavaScript, HTML, CSS, SQL, or shell content returned by the model. Agent output is data, not application code.

2. Session and API gateway

The gateway validates the user's session, tenant, product entitlements, request size, origin, and rate limit. It creates a server-side run ID and binds the connection to an authorized agent and workflow.

Do not rely on identifiers sent by the browser for tenant or resource authorization. Resolve trusted scope from the authenticated session.

3. AG-UI adapter

The adapter translates between protocol events and the chosen agent framework. It validates inbound events, normalizes outbound events, assigns sequence numbers, and applies compatibility rules.

Keep this layer separate from business logic so the agent framework or transport can change without rewriting the product interface.

4. Agent orchestrator

The orchestrator manages model calls, tools, context, budgets, and run state. It may delegate to specialist agents, but the client should receive one ordered interaction stream.

Long-running processes should not depend on one web connection. Store workflow state durably and let the client reconnect. The retry, timer, and approval patterns in our durable execution guide apply directly.

5. Policy-controlled tool gateway

Tools operate behind authentication, authorization, schema validation, rate limits, and audit. The agent proposes a tool call; a deterministic service decides whether it is allowed.

The UI may display the proposed operation and collect approval, but approval must bind to the exact tool name, arguments, resource version, and expiry.

6. State store and event log

Persist authoritative session state and an append-only event history. The browser's current component tree is not the source of truth.

The store should support:

• reconnection from a known event sequence;
• idempotent interaction handling;
• optimistic concurrency or version checks;
• audit and replay;
• session expiry and deletion;
• tenant and regional data boundaries.

7. Observability and evaluation

Trace frontend interaction through the gateway, agent, tools, and business systems. Record latency to first event, stream interruptions, tool duration, approval time, state conflicts, rendering errors, and user corrections.

The telemetry model in our OpenTelemetry production guide can connect these layers without logging sensitive prompts or generating unbounded cardinality.

Prefer a trusted component registry

The safest generative UI architecture uses a fixed registry of components owned by the product team.

For example:

type ComponentSpec =
  | {
      type: "metric-card";
      props: { label: string; value: string; trend?: number };
    }
  | {
      type: "approval-panel";
      props: {
        actionId: string;
        title: string;
        impact: string;
        expiresAt: string;
      };
    }
  | {
      type: "record-table";
      props: {
        columns: string[];
        rows: Array<Record<string, string | number>>;
      };
    };

The agent can choose a component and provide validated properties. The frontend controls the implementation, styling, interaction, keyboard behavior, localization, and responsive layout.

Each registry entry should define:

• a versioned schema;
• maximum payload size;
• allowed actions;
• permission requirements;
• loading, empty, error, and stale states;
• accessibility behavior;
• analytics events;
• safe fallback rendering.

This approach creates flexibility without asking a model to generate production frontend code during a user session.

Treat generated specifications as untrusted data

Schema validation is necessary but not sufficient.

A technically valid component payload can still create problems:

• a table may include records from another tenant;
• a link may point to an untrusted destination;
• a label may contain deceptive instructions;
• a chart may hide important values through scale choices;
• an approval component may describe a different action than the backend will execute;
• a very large payload may exhaust browser memory;
• repeated components may create interaction spam.

Validate data authorization at the server before emitting the event. Sanitize text and links, enforce size and count limits, and calculate high-consequence summaries from trusted business data rather than model prose.

For an approval, the backend should resolve the action by an opaque ID and display server-derived facts. Never execute an operation reconstructed from editable component text.

Streaming transport and event ordering

Server-Sent Events are a strong default when most traffic flows from the agent to the browser. SSE works over normal HTTP infrastructure, supports incremental delivery, and is simpler to operate than a bidirectional socket.

WebSockets can be appropriate for highly interactive sessions with frequent client events, collaborative state, or low-latency bidirectional updates. They add connection lifecycle, scaling, backpressure, and infrastructure complexity.

Whichever transport is used, define:

• monotonically increasing event sequence numbers;
• run and session identifiers;
• heartbeat and idle timeout behavior;
• reconnect with lastEventId or equivalent cursor;
• idempotency keys for user actions;
• maximum event and stream size;
• backpressure strategy;
• terminal success, failure, cancellation, and expiry events.

Do not assume the browser receives every event exactly once. Mobile networks, proxies, tab suspension, deployments, and backend restarts will interrupt streams.

Shared state needs one authority

AG-UI can synchronize state between the agent and interface, but teams must define which side owns each field.

Separate state into categories:

• server-authoritative: identity, permissions, balances, workflow status, approvals;
• agent-proposed: draft plan, selected evidence, suggested filters;
• client-local: open panels, focus, unsaved text, view preferences;
• collaborative: a form or plan that both user and agent can update under version control.

Use version numbers or compare-and-swap semantics for collaborative state. If the user edits a field while an older agent event is in flight, the client must not silently overwrite the new value.

State patches should be bounded and validated. Avoid replacing an entire large document when one field changes.

Human-in-the-loop should be a first-class event

An agent often needs information or approval before continuing. Model this as a durable interruption, not a chat message that the backend hopes the user answers correctly.

An approval request should include:

• exact proposed operation;
• affected tenant, environment, and resource;
• evidence and business reason;
• expected impact;
• validation and rollback plan;
• expiration time;
• policy that requires approval.

The UI renders a trusted approval component. The user's decision is sent with an idempotency key and authenticated identity. The server verifies that the operation and underlying state have not changed, records the approval, and resumes the workflow.

Our guide to AI agents for DevOps and SRE shows how exact-scope approvals prevent ambiguous production authority.

Authentication, authorization, and multi-tenancy

The AG-UI connection inherits the same security requirements as the rest of the product.

At connection time, validate:

• user session and MFA state where required;
• tenant membership;
• product role and entitlements;
• allowed agent and workflow;
• region and data-residency policy;
• origin and anti-CSRF protections for relevant transports.

At every tool call and data event, re-evaluate resource authorization. A session authorized to discuss one customer case is not automatically authorized to retrieve another case because the model requested it.

For multi-tenant systems, include trusted tenant context in server-side tool execution and query policy. Do not place tenant isolation solely in prompts. The patterns in our multi-tenant SaaS architecture guide apply to agent sessions, caches, event stores, and background jobs.

Design for accessibility and predictability

Dynamic UI can be disorienting if components appear, move, or claim focus without warning.

Build accessibility into the registry:

• preserve logical heading and landmark structure;
• announce meaningful progress through appropriate live regions;
• avoid announcing every streamed token;
• never steal focus when a component arrives;
• provide keyboard access for every interaction;
• retain a text representation of charts and visual evidence;
• respect reduced-motion preferences;
• keep approval actions visually and semantically distinct;
• allow users to pause streaming or automatic updates;
• restore focus after a component is removed.

High-impact actions should remain consistent across generated views. Users should not need to relearn the location or meaning of approval controls for each run.

Failure states are part of the product

Agentic interfaces fail in more ways than ordinary request-response screens.

Design explicit states for:

• agent run timeout;
• disconnected stream;
• partial tool result;
• rejected tool authorization;
• component schema mismatch;
• unavailable component version;
• stale shared state;
• expired approval;
• model refusal or invalid output;
• user cancellation;
• server deployment during a run.

The client should preserve already verified results and clearly mark incomplete sections. It should not display a generic spinner indefinitely.

Provide a stable fallback: a structured text event or known error component that can render even when a richer specification fails. Feature flags should allow one component type or generative UI mode to be disabled without taking down the entire agent.

Observability for generative interfaces

Traditional frontend metrics remain important, but agentic UI adds new signals.

Measure:

• time to first meaningful event;
• total run and tool latency;
• stream reconnect and resume rate;
• events per run and bytes per event;
• component render success by schema version;
• state conflict and stale-event rate;
• approval completion and expiry;
• user cancellation and correction;
• accessibility errors;
• fallback usage;
• token, tool, and infrastructure cost;
• business workflow completion.

Trace IDs should propagate from browser request through agent and tool calls. Do not use raw prompts, customer text, or complete session IDs as metric labels.

Replayable event logs are valuable for debugging, but they may contain sensitive business data. Apply encryption, retention, regional storage, access logging, and deletion policy.

Evaluate usefulness, not visual novelty

A generated interface can look impressive while making the workflow slower or less trustworthy.

Evaluate with representative tasks and users. Measure:

• task completion time;
• error and abandonment rate;
• number of clarification turns;
• correctness of component choice;
• factual consistency between text and structured UI;
• user understanding of agent actions;
• approval decision quality;
• recovery from interrupted sessions;
• accessibility and keyboard completion;
• performance on small screens and slow networks.

Include adversarial tests:

• prompt injection in tool results;
• unauthorized cross-tenant records;
• malformed component specifications;
• duplicate and out-of-order events;
• extremely large tables;
• deceptive links or labels;
• approval replay;
• state updates after cancellation;
• component versions unknown to an older client.

The interface should remain secure and understandable when the model behaves incorrectly.

Common failure patterns

Generating raw frontend code at runtime

Executing model-generated JavaScript or HTML creates a severe security and reliability boundary. Use a trusted component registry and declarative data.

Turning every response into a custom component

Text is often sufficient. Generate structure only when it improves comprehension or interaction.

Letting the model own authoritative state

Balances, approvals, permissions, and workflow status belong in deterministic systems.

No reconnection or replay design

Streams will disconnect. Persist runs and support cursor-based resume.

Treating tool visibility as tool authorization

Showing a tool call in the UI does not make it permitted. Enforce authorization server-side.

Dynamic UI without design constraints

Unlimited component combinations produce inconsistent products. Define composition, density, hierarchy, and action placement rules.

Ignoring version compatibility

Frontend and agent deployments do not always happen together. Version events and component schemas, support a compatibility window, and retain fallbacks.

Measuring engagement instead of completion

More messages and longer sessions can indicate friction. Optimize for completed business outcomes and fewer preventable corrections.

A practical implementation roadmap

Phase 1: choose one variable workflow

Select a workflow where chat is clearly inadequate and static variants are expensive. Document users, data, actions, risk, and success metrics.

Phase 2: define the event and state model

Specify run lifecycle, event ordering, state ownership, reconnection, cancellation, and audit. Keep business state outside the model.

Phase 3: build a small component registry

Start with five to ten components such as a result list, detail panel, form, progress view, diff, and approval panel. Implement schemas, limits, accessibility, and fallbacks.

Phase 4: connect read-only tools

Let the agent retrieve authorized data and compose views without executing mutations. Test data boundaries and prompt-injection resistance.

Phase 5: add durable human interaction

Introduce validated forms and exact-scope approvals backed by durable workflow state and idempotent APIs.

Phase 6: add bounded actions

Expose narrow tools through a policy gateway. Verify preconditions and state versions before execution, then stream deterministic results.

Phase 7: evaluate and expand

Review task completion, errors, corrections, accessibility, cost, and security events. Add components when repeated workflows justify them, not because the model can generate more variety.

Generative UI should make software more usable, not less controlled

The next generation of AI applications will not be chat windows attached to every screen. They will combine natural-language intent with the structured controls, dense information, and predictable behavior that make software useful.

AG-UI provides a practical protocol for streaming agent activity, synchronizing state, and supporting human interaction across agent and frontend frameworks. Production quality still depends on the surrounding architecture: trusted components, server-side authorization, durable state, event ordering, accessibility, observability, evaluation, and safe failure behavior.

BoundLayer designs and builds full-stack AI agent products, internal tools, workflow automation, and cloud infrastructure. We can identify the right generative UI use case, define the event and state architecture, build a secure component registry, integrate agent frameworks and business systems, and carry the product from prototype to production.