UI4A: A Component-Native Harness for Generative UI

July 18, 2026

Every Generative UI system begins with a hidden decision: what language is the agent allowed to speak? Large language models generate tokens, but those tokens only become actions once a harness maps them into a specific, interpretable language. Whoever chooses that harness chooses what the model can express, how its output can be validated, and where its actions are allowed to reach.

At Mind Lab, this matters because dynamic UI is not decoration. It is the interface through which a personal agent turns reasoning into an experience that a person can inspect, correct, and continue using. A harness that is too loose makes that interaction difficult to control; one that is too rigid limits what the agent can build from real user needs.

UI4A stands for UI for Agent. The name is the thesis: a Generative UI harness should be designed around how an agent naturally works, rather than forcing the agent to conform to a UI shaped for a fixed schema. We introduce UI4A here, explain the reasoning that led us there, and preview Macaron Artifacts, a community plugin that brings UI4A into Claude Code and Codex.

Figure 1: The live UI4A carousel

TL;DR

UI4A is an agent-first harness for Generative UI. The agent writes ordinary frontend code and imports from a curated component registry. The runtime enforces the boundaries.
It combines what HTML and schema protocols each do well. UI4A keeps HTML's expressive ceiling while adding the auditability, controllability, and cross-target rendering associated with schema-native systems.
The included 48-case gallery benchmark shows lower output-token use than raw HTML. UI4A uses about 45% fewer tokens on average in this subset. Internal measurements also report substantially faster time-to-first-render, but the latency data is not included in the current artifact and should be treated as preliminary.
It is framework-agnostic. React, Vue, Svelte, and SolidJS render today. Macaron V1's UI4A LoRA is specialized for TSX (React and SolidJS).
Macaron Artifacts packages the harness for the community. The plugin supports Claude Code and Codex with a local runtime, streamed previews, and structured action handling.

1. The Harness Matters as Much as the Model

The right harness matters as much as the model behind it. Claude Code is the clearest example in coding today. It did not teach Claude to code. It gave Claude the right workspace, and the model's own capability did the rest. UI4A is our bet on that same shape for Generative UI.

A good harness has three properties. It is concise. It leans on skills the model already has. It stays out of the way as the model gets stronger. The question in Generative UI is not whether the model can render a card. It is what harness you hand it.

Prior Generative UI protocols mostly took the opposite framing: given a fixed UI schema, coax the agent into fitting it. UI4A inverts that. Start from how an agent naturally writes code - imports, components, functions, state, and actions - then let the harness manage the rest. UI for Agent, not Agent for UI.

This did not appear from thin air. Our earlier work on Macaron-A2UI fine-tuned models to speak the A2UI schema and taught us two things [1]. First, teaching a model when to render UI is more valuable than teaching it how. Second, the schema's expressive ceiling caps the model's ceiling. Every new capability turns into more catalog and more instruction.

UI4A is what we built after living inside a schema-native protocol long enough to see its edges. The harness and the model co-evolve. A better harness makes a sharper model, and a sharper model earns a lighter harness.

2. Three Approaches to Generative UI

Three positions have emerged in Generative UI. Each is coherent on its own terms, and each hits a wall for a different reason.

Figure 2: Comparison of HTML-native, UI4A, and schema-based approaches.

2.1 HTML-Native: Maximum Freedom, Minimum Control

Handing the model HTML is the most natural starting point. LLMs are already code generators, and the browser is already a universal target. The expressive ceiling is enormous, and modern models are fluent in the modern frontend stack.

But freedom is expensive. DOM, CSS, and JavaScript give the model too many ways to be wrong. Boilerplate burns context. Click handlers, permissions, state synchronization, and multi-turn coherence have no stable contract, so every product ends up inventing its own. When the model streams half a JSX file, someone has to make it valid, typed, and safe before it renders.

In practice, HTML-native pushes the protocol problem into compilers, bundlers, and error-recovery layers. Prototyping is straightforward. Production is another story.

2.2 Schema-Native: Maximum Control, Limited Expressiveness

Schema-native protocols swing the other way. The agent only emits components, layouts, data references, and actions that a fixed schema permits. A2UI is a prominent example [2]. A renderer publishes a catalog and instructions; the agent emits messages that update a shared data model and mount components on named surfaces; user gestures return as actions, either dispatched as agent events or executed locally as client functions.

json-render is a close cousin from Vercel Labs [3]. Our own Macaron-A2UI models sit on this line, trained to know when to render UI at all, not just how.

Schema-native is verifiable, auditable, and cross-target. It is also capped by whoever maintains the schema. Every new capability has to enter the catalog. Every new prop has to be explicitly whitelisted. Complex, taste-heavy experiences have to be shaped to fit what the schema can describe.

The more you push toward "one schema covers everything," the more it starts to look like a bespoke frontend framework wearing a JSON costume. That is a valid engineering choice. It is also no longer a concise harness.

2.3 Component-Native: Code Inside Enforced Boundaries

The third position starts from a different question: What does an agent actually want to write? Empirically, the answer is code. Not JSON pretending to be code. Not HTML pretending to be a protocol. Code, with imports, components, state, and functions.

The harness meets the agent there: a curated registry of pre-built components, ordinary imports, familiar state and event patterns, and a runtime that enforces the boundaries schema-native protocols usually enforce.

That is UI4A. It keeps the auditable renderer-agent loop that A2UI and json-render established - surfaces, data model, and actions - while expressing UI as importable capabilities rather than leaves of a fixed component tree. The model writes code it already knows how to write. The harness decides what that code can reach.

3. What UI4A Actually Is

The mental model fits on one line: import + component + state + action. The agent writes an ordinary frontend file. It can import from the Macaron component registry, from familiar ecosystem primitives such as Radix, shadcn, Recharts, KaTeX, and lucide-react, or fall through to raw HTML and CSS when a case demands it. The runtime validates, mounts, and manages the rest.

The harness gives the agent two axes of flexibility:

Scale down to the registry alone when you want maximum token efficiency and predictability. An agent producing a booking card should not need to relearn Radix from scratch.
Scale up to arbitrary frontend code when a case genuinely calls for it: LaTeX, 3D scenes, generative visuals, or whatever the browser can host.

UI4A is framework-agnostic by design. The same output renders into React, Vue, Svelte, and SolidJS today. The Macaron V1 UI4A LoRA is specialized for TSX (React and SolidJS). Adding a new framework is a matter of shipping a small renderer, not rewriting the protocol.

The Action Contract

One example is worth highlighting: the Action contract. In HTML, a click handler is an opaque function attached to a DOM node. Auditing what it reads, what it sends, and whether it should have run at all is difficult.

In UI4A, every user gesture flows through a small contract that declares four things:

Origin: the surface and component that produced the gesture.
State: the data references that were read.
Execution: a local client function or an agent event.
Visibility: which fields cross the boundary into the model and which remain NoAI.

The runtime uses that contract to decide whether to handle the gesture locally, ask the user to confirm, or dispatch it as an event. Turning a click into an audited, structured object is what makes component-native interaction feel closer to a real product than either HTML onClick or a fixed schema action list.

We are keeping the rest of the internals brief on purpose. A future post will unpack the registry manifest, the data model as a context-compression layer, and the streaming and partial-render pipeline in depth.

Figure 3: The UI4A widget gallery

4. Why This Shape Wins

The central claim is not that component-native dominates every dimension. It is that component-native raises the floor on controllability without lowering the ceiling on expressiveness.

The included benchmark artifact covers 48 gallery cases. Across those cases, raw HTML averages about 1,224 output tokens and UI4A averages about 672, a reduction of approximately 45%. A2UI data is available for the first 20 cases only, so the chart should not be read as a full three-way comparison over all 48 cases.

Figure 4: UI4A uses fewer output tokens than raw HTML across most of the 48 included gallery cases; A2UI is shown for the first 20 cases.

The broader engineering case has five parts:

Token efficiency. Components collapse layout and styling boilerplate into a single import.
Latency. Internal measurements reported by the team show up to roughly 6x faster time-to-first-render when a non-reasoning LoRA, streaming, and partial rendering are combined. This remains an internal result until the latency artifact is published.
Auditability. Every user gesture is an Action, never an opaque onClick.
Cross-target rendering. One semantic layer supports four renderers today, with more planned.
Expressive ceiling. LaTeX, 3D, bento grids, and generative image tiles remain available because the system can fall through to frontend code.

There is also a compound effect. Because UI4A resembles what a frontend engineer would already write, a small LoRA can focus on helping a general-purpose model pick the right component and bind it correctly, rather than teaching the model to memorize a schema envelope. This is what we mean by harness and model co-evolving: the harness makes the model's job legible, and the model makes the harness feel effortless.

5. Release: Macaron Artifacts for Claude Code and Codex

Macaron Artifacts is a community edition of an Artifacts-style experience built on UI4A and packaged as a plugin for Claude Code and Codex [4,5].

Install

Claude Code

Run these commands inside a Claude Code session:

/plugin marketplace add https://github.com/MindLab-Research/macaron-artifacts
/plugin install macaron@macaron

After installation, enter /macaron in the session to open Macaron.

Codex

Run these commands in a terminal:

codex plugin marketplace add https://github.com/MindLab-Research/macaron-artifacts
codex plugin add macaron@macaron

After installation, tell Codex: Open the Macaron WebUI.

Update

Claude Code

Run these commands inside a Claude Code session:

/plugin marketplace update macaron
/reload-plugins
/macaron:macaron

Codex

Upgrade the marketplace, then reinstall the plugin:

codex plugin marketplace upgrade macaron
codex plugin remove macaron@macaron
codex plugin add macaron@macaron

After installation, the plugin provides:

The Macaron component registry as imports in the agent's generated code.
A local runtime and preview panel that mounts streamed output as it arrives.
Action-contract wiring by default, so user gestures return to the agent as structured events rather than free-form strings.
Optional use of Macaron's UI4A LoRA when the model supports adapters. The plugin also works with the base model, at somewhat higher latency and token cost.

Macaron Artifacts is intentionally aimed at the community. The plan is to avoid a gated tier or proprietary hosting requirement, and to allow the UI4A protocol to accept third-party component registries over time.

6. What Is Next

UI4A is a first release, not a finished protocol. The near-term roadmap includes:

Registry expansion. More first-party components, plus a specification for third-party component packages so teams can bring their own design systems.
More render targets. Beyond the web, we are prototyping Flutter and native-mobile adapters for the same surface semantics.
Evaluation. We are extending the evaluation stack started with A2UI-Bench toward the four layers that matter in production: transport stability, structural validity, runtime safety, and user-outcome metrics.
Continued model-harness co-evolution. As Macaron Artifacts sees real usage, the LoRA can become sharper and the registry clearer, following the same loop that produced UI4A.

Conclusion

UI4A is a bet that the best Generative UI protocol will feel less like a serialization format and more like a carefully bounded workspace. The agent gets to use the frontend language it already understands; the runtime makes that language auditable, portable, and safer to execute.

For Mind Lab, the deeper point is about learning from real experience. Dynamic interfaces are where an agent's decisions meet a person's corrections, preferences, and outcomes. A harness that preserves expressiveness while structuring those interactions gives the system a cleaner stream of experience to learn from. The next generation of UI4A should therefore be shaped not only by benchmark cases, but by the places where real users find the harness helpful, confusing, or insufficient.

References

[1] Macaron-A2UI: A Model for Generative UI in Personal Agent (Mind Lab et al, 2026)

[2] Introducing A2UI: An Open Project for Agent-Driven Interfaces (Google et al, 2025)

[3] json-render: The Generative UI Framework (Vercel Labs et al, 2026)

[4] Create Plugins (Anthropic et al, 2026)

[5] Claude Code Now Supports Artifacts (Anthropic et al, 2026)

Author

Mind Lab

Core Contributors

Murphy Zhuang, Rio Yang, Hao Fu, Fan Lin, Hera Feng, Xiang Liu, Qian Qiao, Theo Li, Sueky Zhang, Andrew Chen, Pony Ma

Team

Asher Cai, Song Cao, Kaijie Chen, Cleon Cheng, Steven Chiang, Kaixuan Fan, Jun Gao, Pyke Han, Nolan Ho, Mutian Hong, Charles Huang, Fancy Kong, Andrew Lei, Lucian Li, Ray Li, Fan Lin, Kieran Liu, Logan Liu, Neo Liu, Xiang Liu, Yuxin Lu, Pony Ma, Cole Qiao, Vince Qu, Vincent Wang, Bo Wu, Chengdong Xu, Rio Yang, Regis Ye, Yihang Zeng, Di Zhang, Jiahao Zheng, Adrian Zhou, Yuhua Zhou, Murphy Zhuang and Mindverse Team

Names are listed alphabetically by surname within team.

Citation

Please cite this work using the BibTeX citation:

@misc{zhuang2026ui4a,
  author = {Murphy Zhuang and Rio Yang and Hao Fu and Fan Lin and Hera Feng and Xiang Liu and Qian Qiao and Theo Li and Sueky Zhang and Andrew Chen and Pony Ma and {Mind Lab}},
  title = {UI4A: A Component-Native Harness for Generative UI},
  year = {2026},
  howpublished = {Mind Lab: A Lab for Experiential Intelligence},
  note = {https://macaron.im/mindlab/research/ui4a-a-component-native-harness-for-generative-ui}
}

Share to