Surface.
The Feature
After the Chat Log
Six proposals for what agents should be permitted to display
“The chat log is a box, and the box is running out of room.”
For three years conversational interfaces served as the default presentation layer for AI. Six different proposals answer the core question of what agents should be permitted to display. SURFACE removes brand affiliations and reveals three distinct architectural layers — payload, transport, distribution.
The chat log is a box, and the box is running out of room
Six proposals have emerged, each offering a distinct answer to the core question: what should agents be permitted to display?
For three years, conversational interfaces served as the default presentation layer for AI interactions. This arrangement has become inadequate as agents now handle complex tasks like ticketing, dashboards, travel booking, and contract drafting — work that demands more sophisticated visual surfaces than a simple text exchange.
Six different proposals have emerged in recent months, each offering a distinct answer to the core question: what should agents be permitted to display? Their creators operate from different institutional positions: Anthropic and OpenAI collaborated on formal standards, Google pursued an independent direction, Vercel built a constraining framework, while CopilotKit and the MCP-UI community addressed problems others hadn’t yet articulated. The surface layer ultimately determines where products manifest.
On MCP Apps: The Treaty
Anthropic and OpenAI co-authored SEP-1865. Iframes as the lowest common denominator. Straightforward standards that ship prove more valuable than elaborate specifications that remain theoretical.
Two major competitors — Anthropic and OpenAI — co-authored SEP-1865, the MCP Apps Extension, alongside the MCP-UI community project. This specification introduces a ui:// URI scheme for declaring UI resources. When models invoke tools, hosts render the declared HTML within sandboxed iframes, with components communicating back through the same JSON-RPC messaging already present in MCP, transmitted via postMessage.
The specification deliberately maintains simplicity: iframes represent the lowest common denominator across hosts, sandboxing provides shared security assumptions, and JSON-RPC integration uses existing infrastructure. This intentional restraint — avoiding novel approaches in favor of compatibility — enabled rapid adoption across Claude, ChatGPT, Goose, and VS Code.
However, the treaty deliberately defers complex problems. It doesn’t specify how UI and agent coordinate state beyond individual tool invocations. It provides no mechanism for agents in multi-agent systems to parse on-screen information. It assumes pre-bundled HTML frontends or prompt-generated code.
Yet straightforward standards that ship prove more valuable than elaborate specifications that remain theoretical. For developers requiring their dashboards to function across major clients without multiple implementations, this foundation provides essential ground.
On MCP-UI: The Garden
Patterns earn their shape through production use first, then get formally documented. The community garden remains upstream of the specification.
Before standardization came practice. The MCP-UI repository, stewarded by Ido Salomon and Liad Yosef with the #ui-wg Discord community, incubated interactive UI patterns in MCP well before formal specifications emerged. The design patterns, bidirectional communication models, and content type approaches were all developed in public.
Adoption came from pragmatic platforms — Postman, Shopify, Hugging Face, ElevenLabs, Goose — not early-adopter novelty seekers. This convergence from independent implementation made the official extension possible.
The working group persisted after standardization, becoming the maintenance body. The official announcement credits both MCP maintainers and MCP-UI creators as peers. The extension explicitly identifies MCP-UI’s approaches as predecessor patterns, with message translation pathways. The January 2026 announcement designates the MCP-UI Client SDK as the recommended host framework.
This reflects a larger principle about contemporary infrastructure development: patterns earn their shape through production use first, then get formally documented. The community garden remains upstream of the specification.
On the Apps SDK: The Storefront
The API as a listing. The model becomes the discovery mechanism. The unresolved question remains policy rather than technical.
OpenAI’s Apps SDK, released simultaneously with the MCP Apps proposal, employs “the API as a listing” concept. MCP provides the backbone — tools over JSON-RPC, components as embedded resources, models invoking tools during conversation. The differentiation emerges above this layer.
Discovery operates first-party: the model consumes tool metadata identically to first-party connectors, enabling natural-language discovery and launcher ranking. Conversation awareness is built-in: structured content and component state flow through conversation turns, allowing models to reference identifiers, re-render components, and reason across results.
An MCP server connected to ChatGPT functions as a distribution listing rather than a discrete tool. The model becomes the discovery mechanism.
This explains the apparent détente of November: a standardized extension benefits OpenAI more than forking would. Developers can run identical servers across Claude, Goose, and VS Code, then promote them in ChatGPT without migration overhead. The specification enables interoperable listings; attention concentrates on the storefront itself.
The unresolved question remains policy rather than technical: ranking algorithms currently operate through language models with opaque priors. Developers familiar with App Store review processes recognize this trajectory.
On json-render: The Constrained Palette
Vercel Labs rejects HTML generation entirely. Models select from a developer-defined component catalog, with constraints enforced through Zod schemas.
Vercel Labs’ json-render, released open-source in January 2026, rejects HTML generation entirely. Instead, models select from a developer-defined component catalog, with constraints enforced through Zod schemas.
The framework operates in three layers: developers define catalogs in Zod (which serves simultaneously as LLM schema and type contract); language models emit flat JSON trees referencing only catalog entries; renderers — available for React, Vue, Svelte, Solid, React Native and others — map those elements to concrete implementations. A shadcn catalog provides 36 pre-built components. Renderers exist for PDF, HTML email, Remotion video, Satori images, and Three Fiber.
This catalog-plus-schema structure guards against generative UI’s central risk: preventing models from emitting executable code. The LLM generates data, not executable output.
json-render and MCP Apps aren’t competitive. The repository includes an examples/mcp demonstrating a pre-bundled React app served as HTML via MCP Apps with json-render running inside. The specification handles transport; the framework handles payload.
The caveat: json-render remains pre-1.0 (v0.14). Wire formats will evolve. Prototypes are appropriate; long-term bets should anticipate migration.
On A2UI: The Native Tongue
Google's argument: iframes are the wrong architectural unit. Transmit native component blueprints. In multi-agent, multi-surface environments, opacity becomes technical debt.
Google’s A2UI, announced December 2025, offers the most substantial disagreement in this issue. Its fundamental premise: iframes represent the wrong architectural unit.
A2UI contends that iframes contain opaque HTML rendered by external code within a sandbox. While sandboxing provides security, it creates a legibility boundary. Host applications cannot style content to match their design systems. Host accessibility trees cannot reach inside. Agents in multi-agent systems cannot parse rendered information — they only know something exists. Models lose visibility into their own output.
A2UI’s alternative: transmit native component blueprints. JSON payloads describe which components a client should compose with which properties bound to which data. Clients — React apps, Flutter apps, native iOS apps — render using existing component libraries. Agent output inherits host styling. Accessibility emerges from host implementation. Other agents parsing the payload see structured information rather than opaque frames.
Transport remains deliberately unspecified. A2UI payloads can travel over Agent-to-Agent protocol, AG-UI, or REST. Google announced an MCP Apps bridge: servers could serve A2UI blueprints instead of HTML, with hosts rendering natively. The v0.9 draft explicitly supports MCP, A2A, AG-UI, SSE, and WebSocket transports.
Early implementations live within Google — Opal, Gemini Enterprise. Pre-1.0 churn is evident: the jump from 0.8 to 0.9 renamed all four message types. Declarative UI protocols risk every implementation shipping identical renamings.
The conceptual advancement remains sound: in multi-agent, multi-surface environments, opacity becomes technical debt. The shared language is native to everyone in the room.
On AG-UI: The Wire
CopilotKit's AG-UI addresses a harder problem: maintaining continuous bidirectional state synchronization between agent and interface.
While MCP Apps and A2UI debate what to render and where to place boundaries, CopilotKit’s AG-UI protocol addresses a harder problem: maintaining continuous bidirectional state synchronization between agent and interface.
Consider a generated dashboard where users apply regional filters. The agent must know this filter exists because the next query — “Show top customers” — depends on it. Under MCP Apps, UI callbacks happen through discrete tool invocations. Under json-render, return paths remain unspecified. AG-UI describes a stream: agents emit state deltas that interfaces apply; interfaces emit state deltas agents consume. Both maintain a shared model.
The protocol’s primitives are StateDelta messages over WebSocket or Server-Sent Events. While CopilotKit provides the reference framework, the specification intends independence.
A March 2026 analysis articulated the clearest framing: “json-render solves what to render; AG-UI solves how to coordinate.” These aren’t competitive frameworks — they occupy different layers. Production agentic interfaces at maturity will integrate all three: declarative payload formats, transport mechanisms, and distribution surfaces.
AG-UI’s challenge is growing beyond its origins. A protocol authored primarily by one company requires independent implementers to become infrastructure. MCP Apps achieved this through the formal treaty. A2UI is reaching it through enterprise adoption. AG-UI pursues the hardest path: proving correctness about problems nobody else had named.
A Synthesis: The Stack
Removing brand affiliations reveals three distinct layers — payload, transport, distribution.
Removing brand affiliations reveals three distinct layers.
Payload layer: the UI description format itself. HTML in iframes (MCP Apps). Constrained JSON from catalogs (json-render). Native component blueprints (A2UI). This choice determines model generation, host rendering, and styling ownership.
Transport layer: how payloads and state move. JSON-RPC over postMessage (MCP Apps). Agent-to-Agent protocol. Bidirectional state deltas (AG-UI). This choice determines agent-interface synchronization and interface-to-agent communication.
Distribution layer: the surface users encounter. ChatGPT, Claude, Goose, VS Code, Cursor, custom hosts. This choice determines user ownership.
For tool developers, the practical question becomes which layer warrants investment. Conservative approach: MCP Apps as transport, plain HTML as payload, universal host support. Ships today, works everywhere, bounded capabilities.
Ambitious approach: json-render or A2UI as payload, MCP Apps as transport, known distribution surfaces. Richer interfaces, more development, pre-1.0 exposure.
Most ambitious approach: all three layers with AG-UI maintaining state synchronization. This represents the agentic application runtime that MCP Apps documentation gestured toward without fully describing. It doesn’t exist as a unified system yet. Someone will ship it.
The conversation is no longer constrained by chat log architecture. It has become a surface where other surfaces compose. Each of these proposals answers the fundamental question in its own dialect: what should agents be permitted to display? That they differ confirms the question merits asking.