Introduction
Generative UI is the idea that an LLM should return an interface, not a wall of text. The user asks a question, the model answers with a form, a table, a chart, or an approval step, and the application renders it natively. That shift, from generative text to generative user interfaces, is now backed by a real crop of frameworks and protocols. This guide walks through the main generative ui frameworks a team would actually evaluate in 2026, how each one works under the hood, and where each fits.
The point is not to crown one winner. These generative ui tools sit in different layers of the stack and make opposite bets about where the UI comes from. Understanding those bets is the whole job when you pick a generative ui framework, so this overview groups them by mechanism rather than ranking them. Get the mechanism right and the rest of the generative ui decision follows.
How popular is generative UI, really?
The interest is real and climbing. Google Keyword Planner puts global monthly searches for "generative ui" at roughly 5,400 on average over the last year, and the trend line is up and to the right: the term sat near 2,400 to 2,900 searches a month through the second half of 2025, then jumped to 8,100 in November 2025 and again in May 2026, running 6,600 or higher through spring. That is close to a doubling in under a year for the core concept.
The framework names carry even more volume, which tells you where developers are actually looking. "Vercel ai sdk" pulls about 27,100 searches a month and "ai sdk" the same, "copilotkit" about 12,100, "ag-ui protocol" around 1,900, and "google a2ui" about 1,300. Every one of these keywords is marked low competition, which is the interesting part: demand is high and rising, but the content and tooling around these generative interfaces are still thin. The category is forming in real time, not settled. That is the backdrop for the frameworks below.
The one distinction that explains every framework
Before the list, one split explains most of the differences between these generative ui tools. When a generative ui system produces a user interface, either the model selects UI that developers already wrote, or the model authors the UI itself as data.
- Component selection. The application registers a set of React components. The model acts as a router: it reads intent and calls a component, and the framework streams props into it. The UI is code you wrote; the model only decides which piece runs. Vercel AI SDK, Tambo, and CopilotKit's tool rendering work this way.
- Format authoring. The model emits a portable description of the interface, JSON or Markdown, and a renderer turns that description into components. The UI is data the model wrote, validated against a schema. A2UI, json-render, and MDMA work this way.
CopilotKit, which helped standardize this space, uses almost the same taxonomy in its own docs: static generative ui (protocol events), declarative (an authored format), and open-ended (MCP apps and open JSON). Keep the selection-versus-format line in mind and every framework below slots into place.
Vercel AI SDK (streamUI)
Overview
The Vercel AI SDK is the most widely used TypeScript toolkit for building AI features, and its generative ui implementation is streamUI, part of AI SDK RSC. If you already ship on Next.js, this is the path of least resistance.
How it works
streamUI is a component-selection model. You define tools whose generate function returns a React component. The model does not emit UI; it behaves as a dynamic router that reads the user prompt and picks a tool, and streamUI streams the resulting React Server Components from a server action to the client. The UI renders server-side and streams down as components, not as a data format the client parses.
Where it fits
This is the strongest option when your stack is Next.js and React and you want server components with minimal glue. The trade-off is coupling: the generated interfaces are RSC-specific and not portable to another framework, and you write every component the model can reach. It is a great generative ui experience inside the Vercel ecosystem, and a poor fit if you need the same output on mobile or a non-React client.
CopilotKit
Overview
CopilotKit calls itself the frontend stack for agents and generative ui. It is broader than a single rendering trick: it ships chat, a copilot sidebar, state sync, and human-in-the-loop controls for agentic applications.
How it works
The framework supports several rendering modes at once. It can render pre-registered React components from backend tool calls, stream static generative ui through the AG-UI protocol, accept declarative formats, and handle open-ended MCP apps and open JSON. In practice you register components and tools, the agent triggers them, and the framework manages the chat interface, state, and streaming around that interaction. It works across React and Next.js first, with Angular, Vue, and React Native support.
Where it fits
It is the choice when you want a batteries-included assistant surface, not just a rendering primitive, and it is also the connective tissue for AG-UI, below. If you need a full copilot experience with agents, tools, and a chat interface out of the box, it is one of the most complete frameworks here.
Tambo
Overview
Tambo is an open-source generative ui toolkit for React with a tight, focused pitch: connect your components, and Tambo handles streaming, state, and MCP.
How it works
Tambo is component selection done cleanly. You register React components with Zod schemas, and those schemas become the model's tool definitions, a component registry the LLM can call like functions. When the model picks one, props stream into the component as the model generates them, with built-in cancellation, error recovery, and reconnection. It supports OpenAI, Anthropic, Gemini, Mistral, and OpenAI-compatible providers, and persists stateful "interactable" components like carts and task boards.
Where it fits
Tambo is a good middle ground for React teams that want more structure than raw streamUI but less surface than CopilotKit. Like the others in this camp, the UI is the components you register; the model routes among them rather than authoring new interfaces.
Google A2UI
Overview
A2UI (Agent to User Interface) is Google's open protocol for agent-driven interfaces. It is the flagship of the format-authoring camp: the model writes UI as declarative JSON, and clients render it with native widgets.
How it works
The agent emits structured JSON, never executable code, referencing a catalog of trusted components like Card, Button, or TextField. A2UI splits UI structure, application state, and client rendering into separate concerns, and uses a flat list of components joined by ID references so LLMs can stream and generate them incrementally. Google ships renderers for Lit, Angular, and Flutter, with community renderers for React and SwiftUI, so one payload can target web, mobile, and desktop.
Where it fits
A2UI wins on cross-platform breadth and protocol standardization. The cost is verbosity: JSON UI trees are token-heavy for a model to author. We compared the two formats directly in MDMA versus Google A2UI on token cost and enterprise features, if you want the deep version of that trade-off.
AG-UI Protocol
Overview
AG-UI is not a UI format at all, which is exactly why it belongs on this list. It is the transport layer that carries generative ui between an agent and a frontend.
How it works
AG-UI is a lightweight, event-based user interaction protocol: an agent backend emits a stream of standard event types (around 16 of them) over SSE, WebSockets, or webhooks, and the frontend reacts. It sits above MCP, which gives agents tools, and it is framework-agnostic by design. It came out of work with LangGraph and CrewAI and has been picked up across the agent ecosystem, including Google, LangChain, AWS, and Microsoft.
Where it fits
Treat AG-UI as complementary, not competing. It answers "how does UI stream from agent to client," while a format like A2UI or MDMA answers "what is the UI." You can stream a declarative format over AG-UI. Our full breakdown lives in AG-UI protocol explained and how it compares to MDMA.
json-render
Overview
json-render is an open framework whose tagline is literally "AI to json-render to UI." It is the pure JSON take on format authoring: the model writes a UI tree, guardrails keep it renderable.
How it works
A json-render document is a flat tree, a root id plus an elements map of id to type, props, and children. The model may only use component types and actions you have declared in a catalog, so its output cannot drift outside what your app already knows how to render. Like A2UI it authors JSON, and like the whole camp it renders into React.
Where it fits
json-render is a strong pick when you want declarative, model-authored UI and are happy for the authoring format to be JSON. The open question, which we take up in json-render versus MDMA for generative UI, is whether JSON or Markdown is the better surface for a model to write onto.
MDMA
Overview
MDMA (Markdown Document with Mounted Applications) is the Markdown-native option in the format-authoring camp. Instead of asking the model to emit JSON, it asks the model to write an ordinary document with interactive blocks mounted inline, the format models were trained on.
How it works
MDMA extends Markdown with components defined in fenced `mdma blocks. The model writes prose and drops in a block when it needs interaction:
Based on the submitted documents, this application qualifies for review.
` ``mdma
id: loan-assessment
type: form
fields:
- name: risk_score
type: select
label: Risk Classification
options:
- { label: "Low Risk", value: low }
- { label: "High Risk", value: high }
onSubmit: submit-assessment
` `It ships nine component types (form, button, tasklist, table, callout, approval-gate, webhook, chart, thinking), each validated against a Zod schema before render. The monorepo is model-agnostic and framework-independent at the core: a remark-based parser, a headless runtime, a validator, and a separate React renderer (@mobile-reality/mdma-renderer-react), plus a prompt-pack that teaches any LLM the syntax and an eval suite for measuring generation quality. Because the parser and runtime are headless, the format is not tied to one frontend the way streamUI is tied to RSC.
Where it fits
MDMA is the pick when you want portable, model-authored UI with an enterprise runtime attached: an append-only audit log, automatic PII redaction, a policy engine, and approval gates as a first-class component. It fits regulated work, fintech, healthcare, insurance, where those are requirements, not extras. It is one option among several here, and the honest summary is: choose it for portability plus compliance, choose a selection framework like streamUI or Tambo when you want the model to route among components you already control.
Evaluating generative UI frameworks for production?
Side-by-side: the generative UI frameworks compared
| Framework | Mechanism | UI comes from | Framework binding |
|---|---|---|---|
| Vercel AI SDK (streamUI) | Component selection | React server components you write | Next.js / RSC |
| CopilotKit | Selection + protocol | Registered components, AG-UI, MCP apps | React-first, multi-framework |
| Tambo | Component selection | Registered components (Zod, component registry) | React |
| Google A2UI | Format authoring | Model-authored JSON | Cross-platform renderers |
| AG-UI | Transport protocol | N/A (carries UI events) | Framework-agnostic |
| json-render | Format authoring | Model-authored JSON tree | React |
| MDMA | Format authoring | Model-authored Markdown | Headless core, React renderer |
How to choose
Start with the selection-versus-format question, because it decides most of the rest.
- Pick a component-selection framework when you want tight control and the model only needs to choose among UI you already built. Vercel AI SDK if you live on Next.js, Tambo for a lean React setup, CopilotKit when you want a full assistant surface with chat and agents included.
- Pick a format-authoring framework when you want the model to author interfaces as portable data. A2UI for cross-platform reach, json-render for a JSON catalog, MDMA for Markdown authoring plus an enterprise runtime.
- Add AG-UI underneath either camp when you need a clean transport between agent and frontend; it is a protocol, not a competitor to the formats.
There is no single best generative ui framework. There is the one that matches your stack, your need for portability, and how much of the interface you want the model to author versus select. Map those three, and the choice is usually obvious.
Conclusion
The generative ui space in 2026 is no longer a pile of demos. It is a real set of frameworks with clear, opposing designs: models that select developer-written components (Vercel AI SDK, Tambo, CopilotKit) and models that author UI as a format (A2UI, json-render, MDMA), with AG-UI as the transport that ties agents to frontends. Decide whether you want the model to route or to write, match the framework binding to your stack, and weigh portability against control.
If your work lands in the format-authoring camp and needs compliance features built in, MDMA is the Markdown-native option we build and ship for exactly that.
More on generative UI frameworks
Still weighing your options? Read our other side-by-side breakdowns of the leading generative UI frameworks, formats, and protocols:
Building generative UI for production and need portable, model-authored output with audit trails? Explore MDMA on GitHub.
I'm Marcin Sadowski, CTO at Mobile Reality. We build AI agents and automation for fintech and proptech teams. MDMA came out of the generative UI problems we kept hitting on real projects: portable output, model-friendly formats, audit trails, and approval workflows. If you're evaluating generative ui frameworks for production, happy to compare notes.
Frequently Asked Questions
What is the fundamental difference between component selection and format authoring in Generative UI?
In component selection, the model acts as a router that reads user intent and invokes pre-built components you have already registered, such as React Server Components in streamUI or Tambo's component registry. In format authoring, the model writes a portable description of the interface as structured data, whether JSON in A2UI and json-render or Markdown blocks in MDMA, and a renderer turns that data into widgets. The first approach keeps the UI tightly coupled to code you wrote, while the second treats the interface as data the model itself generated.
Is Generative UI secure, and does it risk rendering malicious code?
Production frameworks avoid that risk by restricting the model to controlled outputs rather than arbitrary code. Component-selection systems only render pre-registered components from your own codebase, while format-authoring approaches like A2UI and MDMA emit declarative data that is validated against a schema before it ever reaches the renderer. MDMA adds an enterprise runtime with automatic PII redaction, policy enforcement, and approval gates for teams working in regulated environments.
Can I implement Generative UI if my tech stack isn't based on React or Next.js?
Yes. While Vercel AI SDK and Tambo are tightly bound to React and Next.js, Google A2UI ships native renderers for Lit, Angular, and Flutter with community support for SwiftUI. AG-UI is framework-agnostic by design, and MDMA's core parser, validator, and runtime are completely headless, so you can feed its Markdown format into any frontend and use the React renderer only if you need it.
When should a team choose MDMA over Vercel AI SDK's streamUI?
Choose MDMA when you need the model to author portable, framework-independent UI and you operate in a regulated space that requires an enterprise runtime with audit logs, PII redaction, and approval gates. Choose streamUI when your entire stack is Next.js and you want the model to route among React Server Components you already control with minimal glue. The honest split is portability plus compliance versus ecosystem convenience and tight coupling to React.