2026 Comparative Analysis: Agent-to-User Interface Protocols for Generative UI — Applied Technology Index

Executive Summary

An agent-to-user interface protocol defines how an AI agent and a user-facing application exchange run events, state, interface descriptions, tool results, and user actions. The emerging stack is not converging on one interchangeable standard. AG-UI, A2UI, and MCP Apps solve different boundaries: AG-UI connects an agent runtime to a frontend through a bidirectional event stream; A2UI lets an agent describe an incrementally updatable interface using declarative data; MCP Apps lets an MCP server package an interactive HTML application that a compatible host renders in a sandbox.

The practical finding is that these protocols are more complementary than competitive. AG-UI is a run-communication protocol, A2UI is a declarative UI description format, and MCP Apps is an embedded application contract attached to MCP tools. AG-UI can transport A2UI messages. An MCP server can expose a packaged MCP App when a purpose-built interface is needed. A production system can use more than one, but each additional layer creates a separate compatibility, authorization, accessibility, state, and audit boundary.

The most important architectural choice is whether the agent sends trusted component descriptions or executable interface code. A2UI uses a client-controlled catalog of pre-approved components and explicitly avoids arbitrary generated code. MCP Apps serves HTML and JavaScript but requires sandboxed iframe isolation, restrictive content security policy, structured JSON-RPC communication, and host mediation. AG-UI is neutral about the rendered interface: it standardizes messages, tool calls, state snapshots and deltas, activities, interrupts, and run lifecycle events while leaving presentation to the frontend or a generative UI format layered over it.

No reviewed protocol turns a displayed button into authorized business intent by itself. A user clicking “approve,” “send,” or “purchase” is an input event, not proof that the backend action is permitted, idempotent, correctly scoped, or safe. High-impact actions still require server-side authentication and authorization, accurate read/write annotations, approval records, argument integrity, tool-level policy, and an auditable execution result.

For operators, the recommended selection rule is:

Use AG-UI when a product owns the frontend and needs a live, framework-neutral connection to one or more agent runtimes.
Use A2UI when an agent must compose portable interfaces from a trusted component vocabulary without shipping arbitrary executable code.
Use MCP Apps when an MCP tool provider needs to distribute a self-contained interactive view across compatible conversational hosts.
Use a layered architecture only when the boundaries are explicit—for example, AG-UI for run state plus A2UI for declarative surfaces, while MCP Apps remains a separate tool-host embedding path.

Key Findings

The protocols standardize different objects. AG-UI standardizes run events; A2UI standardizes UI description and update messages; MCP Apps standardizes the association of an MCP tool with a UI resource and the bridge between that resource and its host.
Portability has three separate meanings. Backend portability, component portability, and host portability should not be collapsed into one claim. A backend may speak AG-UI while its interface components remain application-specific. An A2UI payload may validate while relying on a catalog another renderer lacks. An MCP App may follow the shared specification while still using optional host extensions.
A2UI has the smallest executable-content attack surface. Its agent output is declarative data resolved against a trusted renderer catalog. That reduces code-injection risk, but unsafe functions, deceptive composition, excessive data exposure, and incorrectly authorized user actions remain possible.
MCP Apps has the richest packaged-app surface and the heaviest browser security boundary. The specification requires iframe sandboxing, host-controlled message validation, and CSP enforcement because the host is rendering potentially untrusted HTML from an MCP server.
AG-UI is the broadest runtime interaction envelope. Its event model covers run lifecycle, messages, tool calls, state, activity, reasoning, raw and custom events. It does not prescribe a component library, tool authorization model, or complete browser sandbox.
State is not equivalent across protocols. AG-UI carries snapshots and deltas for shared runtime state. A2UI maintains a per-surface data model bound to declarative components. MCP Apps delivers tool input and tool result to an isolated view, while durable business state should remain on the server.
Interrupts and approvals are distinct from authorization. AG-UI documents typed interrupts and resumable runs; OpenAI documents approval-gated tool arguments and destructive-action annotations. The enforcement decision still belongs to a trusted backend or host policy layer.
Fallback behavior is a procurement requirement. MCP tools should remain useful without their optional UI. Agent workflows should degrade to accessible text or structured data when a renderer, component catalog, display mode, or host capability is unavailable.

Methodology

This analysis checked the public Applied Technology Index research index and the local public content collection before selecting the topic. Current technical discussion around AG-UI, A2UI, MCP Apps, cross-framework renderers, and channel adapters was used only to identify the research question. Social posts and conference chatter were not used as evidence for protocol behavior, adoption, security, or compatibility.

Substantive claims are grounded in public technical materials available on 10 August 2026: the AG-UI documentation and repository; the A2UI repository, stable v0.9.1 specification, message reference, and transport guidance; the MCP Apps overview, repository, and 2026-01-26 specification; and OpenAI’s official plugin UI, reference, and publication-guideline documentation. OpenAI is treated as an implementation profile of MCP Apps rather than a fourth independent protocol.

The comparison applies nine criteria:

Standardized boundary: runtime-to-frontend, agent-to-renderer, or MCP server-to-hosted view.
Wire object: events, declarative messages, resources, tool results, or JSON-RPC methods.
Rendering model: application-owned components, catalog-constrained components, or sandboxed HTML.
State model: run state, per-surface data, view-local state, or server-side business state.
Interaction model: user messages, actions, tool calls, interrupts, and resumptions.
Transport model: prescribed, recommended, or transport-agnostic delivery.
Security boundary: executable-content isolation, catalog trust, CSP, message mediation, and backend enforcement.
Portability boundary: what can move between runtimes, renderers, and hosts without vendor-specific adapters.
Operational evidence: versioning, conformance artifacts, capability negotiation, fallback behavior, and auditable action handling.

This is a documented-capability and architecture comparison, not an interoperability benchmark. The same application was not implemented across every protocol and host. No renderer was fuzzed, no sandbox was penetration-tested, and no accessibility, latency, token-cost, or task-completion benchmark was run.

Comparative Analysis Table

Protocol or implementation	Standardized boundary	Payload and rendering model	State and interaction	Security center of gravity	Best fit	Main limitation
AG-UI	Agent runtime ↔ user-facing application	Ordered event stream for lifecycle, messages, tools, state, activity, reasoning, raw and custom events; frontend chooses components or layers a generative UI spec	Run input plus streamed snapshots, deltas, tool calls, interrupts and resumptions	Application authentication, tool policy, event validation, frontend trust and any separately chosen renderer or sandbox	Products that own their frontend and need one interaction contract across heterogeneous agent backends	Does not define a universal component catalog, embedded-app sandbox, or complete authorization model
A2UI v0.9.1	Agent ↔ renderer	JSONL messages describe surfaces, components and data bound to a client-approved catalog; renderer uses native components	Per-surface component tree and data model; incremental updates; renderer returns user actions	No arbitrary agent-generated code; trusted catalogs, function allow-lists, schema validation and server-side action enforcement	Cross-platform generative UI where component safety and native rendering matter more than arbitrary app freedom	Catalog compatibility and renderer completeness determine actual portability; project remains early-stage public preview
MCP Apps	MCP server/tool ↔ compatible conversational host and embedded view	Tool metadata points to a `ui://` HTML resource; host renders it in a sandboxed iframe and bridges JSON-RPC over `postMessage`	Host delivers tool input/results and context; view can request supported host or MCP operations; business state remains server-side	Mandatory iframe sandboxing, restrictive CSP, host mediation, message validation, capability negotiation and audit	Tool providers distributing interactive forms, charts or dashboards inside multiple MCP hosts	Executable HTML/JavaScript increases review and isolation requirements; host support and capabilities vary
OpenAI plugin UI	MCP Apps implementation in ChatGPT and Codex plugin ecosystem	Starts with shared MCP Apps fields and bridge methods, then adds optional `window.openai` extensions and presentation modes	Approval-gated inputs, tool results, temporary widget state, model-context updates and server-side cross-session state	Tool annotations, action labeling, approvals, CSP, privacy policy, directory review and host-specific restrictions	Developers targeting ChatGPT while retaining a standards-based path to other MCP Apps hosts	OpenAI-only extensions, review policy and compatibility aliases are not portable protocol guarantees

Observed Profiles

AG-UI: the runtime-to-frontend event envelope

AG-UI defines itself as an open, lightweight, event-based protocol connecting user-facing applications to agentic backends. Its architecture is transport-agnostic, while the standard HttpAgent client documents HTTP Server-Sent Events and an HTTP binary protocol. This distinction matters: the protocol’s portable object is the ordered event sequence, not one mandatory network transport or frontend framework.

The event model is broader than chat streaming. AG-UI defines run and step lifecycle events; text-message start, content, end, and chunk events; tool-call start, argument, end, result, and chunk events; state and message snapshots; JSON Patch-style state deltas; activity snapshots and deltas; reasoning events; and escape hatches for raw or custom events. A frontend can therefore render partial text, expose tool progress, synchronize application state, and recover a coherent view without treating every update as an unstructured token stream.

Shared state is one of AG-UI’s strongest operational features. The agent and application can exchange complete snapshots infrequently and smaller deltas during execution. That supports interfaces such as plans, editable forms, task lists, dashboards, or review queues whose state evolves while the agent works. It also creates concurrency requirements: implementations need ordering, stable identifiers, replay behavior, reconnect semantics, validation, and conflict policy rather than assuming that a visual component is merely decoration.

AG-UI also defines typed interrupts for runs that pause and later resume. An interrupt can be bound to a tool call, carry a reason and response schema, and accept approval, denial, edits, or other structured input. The interface can render the interruption appropriately, but the trusted backend must verify that the response matches the outstanding interrupt and that protected tool arguments did not change outside the approved edit path.

AG-UI does not attempt to be a generative UI component specification. Its own documentation distinguishes AG-UI from A2UI and other generative UI formats. This separation is architecturally useful. AG-UI can carry a runtime conversation while the application uses fixed components, tool-based generative UI, or A2UI payloads. The cost is that “supports AG-UI” says little by itself about visual portability, accessibility, design-system fidelity, or executable-content isolation.

A2UI: declarative surfaces resolved through trusted catalogs

A2UI is an open-source format for representing updatable agent-generated interfaces. Its current production release is documented as v0.9.1 in the stable v0.9 family, while v1.0 is a release candidate. The project labels itself an early-stage public preview, so operators should distinguish a usable implementation from a frozen long-term compatibility promise.

The security model starts from a clear constraint: A2UI is declarative data, not executable code. The client application owns a catalog of trusted components and the agent asks the renderer to compose those components. The agent does not send arbitrary JavaScript, Flutter, or native code for direct execution. This lets each client map the same semantic component to a native implementation that follows its design system, accessibility conventions, and platform controls.

A2UI messages are JSON objects commonly sent as JSON Lines. A typical sequence creates a surface with a catalog identifier, incrementally updates components, updates the per-surface data model, and eventually deletes the surface. Components can bind to data rather than duplicating full values throughout the tree. Progressive updates let a renderer show useful structure before the agent finishes the complete interface.

Transport is deliberately separate from the UI format. A2UI documentation describes delivery through A2A, AG-UI, or a custom transport. This makes A2UI composable: AG-UI can carry the run, messages, state, and interrupts while A2UI carries the generated surface. It also means A2UI alone does not define all authentication, reconnect, delivery guarantee, or long-running task semantics.

The trusted catalog reduces one risk and introduces another compatibility boundary. A payload that names an unavailable component cannot render as intended. Custom catalogs improve product fidelity but reduce interchange. Functions exposed through components must also be constrained: a trusted button component can still invoke an unsafe backend function if the renderer accepts arbitrary names or the server treats every user action as authorized. Catalog schema, renderer capabilities, function allow-lists, data minimization, and server-side policy are all part of a production A2UI deployment.

MCP Apps: packaged interactive views attached to tools

MCP Apps extends MCP so a server can associate a tool with an interactive UI resource. Tool metadata includes a _meta.ui.resourceUri; the host can read the referenced ui:// resource, render its HTML, and send tool input and tool results to the view. The view and host communicate using JSON-RPC 2.0 over postMessage, reusing MCP-style structured methods rather than an opaque custom event bus.

The package model differs materially from A2UI. An MCP App is an HTML application and may contain JavaScript, styles, charts, forms, client-side state, and richer interaction logic. That makes it appropriate for purpose-built experiences that would be awkward to express through a shared catalog. It also means the host is executing content supplied by a potentially untrusted MCP server.

The MCP Apps specification therefore makes isolation part of the protocol architecture. View content must run in a sandboxed iframe. Web hosts must use an intermediate sandbox proxy on a different origin, mediate initialization, and apply the resource’s CSP configuration. If CSP metadata is absent, the host must use restrictive defaults. Nested frames are denied unless declared through frameDomains; network and resource origins are constrained through declared domain sets. The host remains in control of incoming messages and may block or require approval for operations requested by the view.

Predeclared UI resources also improve reviewability. A host can discover the association between a tool and a view before the first tool call rather than accepting arbitrary inline HTML in each result. This does not eliminate mutable-resource or compromised-server risk, but it gives connection setup and security review a concrete resource identity to inspect.

The specification’s portability claim must be interpreted narrowly. A compliant host can understand the resource association, lifecycle, bridge, dimensions, display modes, theming, and supported requests. It may still deny capabilities, render a different presentation mode, apply stricter CSP, omit host context, or lack MCP Apps support entirely. Tools should therefore produce useful structured content without relying on the view as the sole path to task completion.

OpenAI: standards-first MCP Apps with host extensions

OpenAI’s plugin UI documentation explicitly instructs developers to start with MCP Apps. Components run in an iframe, use the shared ui/* JSON-RPC bridge over postMessage, and should prefer standard fields and methods. OpenAI then exposes optional ChatGPT-specific behavior through window.openai, including compatibility aliases and host capabilities not yet covered by the shared specification.

This standards-first layering is a useful implementation model. A developer can keep the MCP tool and shared UI contract portable, then isolate host-specific presentation or integration features behind capability detection. The inverse—making essential workflow behavior depend on a vendor global—would turn nominal MCP Apps compatibility into a one-host application.

OpenAI’s documentation adds concrete state and approval guidance. Business data and cross-session state should remain on the server. Temporary view state can stay in the component. Model-visible context can be updated through the portable bridge. Approval-gated tool arguments may be absent until the host sends them after approval, preventing an embedded view from presenting unapproved protected input as if execution were already authorized.

Tool annotations are operationally important. OpenAI requires accurate declarations for read-only, destructive, and open-world behavior so a host can apply suitable explanation and approval friction. The plugin guidelines also limit iframe use, require privacy and support information, and subject public listings to review. These are ecosystem policies, not MCP Apps protocol guarantees, but they demonstrate the controls a distribution layer needs beyond wire-format conformance.

How the protocols compose

A frontend application can use AG-UI as its main runtime connection and render ordinary application-owned components. When the agent needs to compose a new surface, it can send A2UI messages through that connection. The frontend resolves those messages against its trusted catalog and returns structured user actions through the same runtime path.

An MCP App is usually a different embedding boundary. The MCP server supplies an interactive view associated with one or more tools, and a compatible host renders it. A custom product could bridge MCP Apps into its own interface while also using AG-UI internally, but doing so requires two capability negotiations and two trust models: runtime events between the product and agent, plus sandboxed view messages between the MCP App and host.

The protocols should not be stacked merely to collect standards. Use each only where its object is needed. Fixed, reviewed components are often simpler than generated UI. A2UI is safer than arbitrary HTML when a trusted catalog covers the task. MCP Apps is more expressive when a tool provider owns a complex interaction. AG-UI is valuable when the application needs continuous run visibility and state coordination independent of either rendering strategy.

Production Decision Framework

Choose the ownership boundary first

If the application team owns both frontend and backend, AG-UI provides a common runtime seam without forcing the UI into a third-party host. If independent agents must generate interfaces across multiple native clients, A2UI’s catalog model is the stronger starting point. If independent tool providers need to ship a complete embedded experience to conversational hosts, MCP Apps matches that distribution boundary.

Require explicit capability negotiation

Do not infer support from a protocol name. Record the protocol version, event or message types, component catalog and version, renderer capabilities, bridge methods, display modes, CSP policy, host extensions, and fallback behavior. Reject unsupported operations explicitly rather than silently dropping them and leaving the user with stale state.

Separate visible intent from executable authority

A rendered control can collect intent, but the server must authorize the resulting operation against the authenticated actor, tenant, resource, scope, current state, and policy. Bind approvals to immutable tool names and canonical arguments. Use idempotency keys for retried actions. Return a signed or otherwise durable receipt for consequential mutations where the risk justifies it.

Treat every dynamic surface as untrusted input

For AG-UI, validate event schemas, identifiers, deltas, URLs, markdown, and custom events before rendering. For A2UI, validate messages against the negotiated schema and catalog, reject unknown components and functions, constrain data bindings, and prevent deceptive overlays or inaccessible interaction traps. For MCP Apps, enforce the required sandbox, validate every JSON-RPC message, deny undeclared network and frame origins, and keep host credentials unavailable to the iframe.

Preserve an accessible fallback

Every consequential interface should have a text or structured-data representation that exposes the same facts and action consequences. Keyboard operation, focus order, labels, error announcements, contrast, reduced-motion preferences, localization, and small-screen behavior must be tested in the actual renderer or host. Protocol conformance does not prove accessibility.

Make state ownership explicit

Document which state is authoritative: agent run state, frontend view state, A2UI surface data, iframe-local state, or backend business state. Durable business truth should live on the server, not only in an event stream or embedded frame. Reconnect and replay tests should establish whether duplicate, delayed, reordered, or missing messages can create a false confirmation or repeated side effect.

Test the failure matrix, not only the happy path

Minimum conformance tests should cover unknown event types, unsupported components, malformed JSONL, invalid JSON Patch operations, stale surface IDs, interrupted streams, reconnects, duplicate actions, denied tool calls, changed tool arguments, CSP violations, sandbox message forgery, unavailable host extensions, renderer crashes, server timeouts, and fallback without UI.

Capture an end-to-end audit trail

For important actions, retain the authenticated user, agent and host identities; protocol and schema versions; run, surface, tool-call and view identifiers; rendered action label; canonical arguments; approval or denial; authorization decision; backend result; idempotency key; and correlation trace. Screenshots and chat transcripts are useful evidence, but they are not a complete action ledger.

Limitations

This analysis relies on public specifications, official documentation, and open repositories available on 10 August 2026. AG-UI, A2UI, MCP Apps, and host implementations are evolving. A2UI identifies v0.9.1 as its current production release and v1.0 as a release candidate while labeling the project an early-stage public preview. MCP Apps fields include documented deprecations and host capabilities that can change before broader general availability.

The protocols have different scopes, so the comparison is architectural rather than a feature score. AG-UI includes a broad runtime event model but is not a component specification. A2UI constrains rendering through catalogs but does not replace a run transport or backend authorization system. MCP Apps embeds richer executable views but requires browser isolation and host mediation. OpenAI’s profile combines the open standard with product-specific extensions and marketplace policy.

No common reference application was built across all reviewed systems. The analysis does not measure renderer fidelity, protocol overhead, time to first render, incremental-update latency, token consumption, component-generation accuracy, accessibility conformance, browser compatibility, mobile behavior, production adoption, pricing, or security vulnerability rates.

Public documentation cannot establish that every listed integration implements every protocol feature correctly. Repository activity, SDK availability, a documentation table, or a host-support statement is not equivalent to independent conformance certification. Buyers should test the exact versions, transports, catalogs, hosts, and tools they intend to deploy.

The security discussion is a threat-model comparison, not a claim that one implementation is secure or vulnerable. Declarative payloads can still produce deceptive or unsafe workflows, and sandboxed code can still manipulate users or request authorized host operations. Formal application security review, privacy assessment, accessibility testing, and organization-specific authorization controls remain necessary.