The hard part of agent-driven UI isn't generating a screen — it's doing it without letting a remote, untrusted model push executable code into your app. A2UI's wager is to treat the interface as data, not code: the agent emits a JSON description naming which components to show, and the client renders them with its own native widgets from a catalog it already trusts.
What Sets It Apart
- Security by construction. The agent can only request components the client has pre-approved (Card, Button, TextField, …). There is no arbitrary code to sanitize, which is what makes remote and cross-trust-boundary agents practical.
- Render anywhere. The same payload maps to Flutter, Angular, and Lit renderers, so one agent can drive web, mobile, and desktop frontends without per-platform UI code.
- Built for LLMs. The format favors small incremental updates over re-emitting whole screens — cheaper tokens and smoother streaming as an agent revises a view.
- Day-zero ecosystem. Designed with the AG-UI / CopilotKit team and aligned with the A2A protocol, so it slots into existing agent stacks rather than replacing them.
Who It's For and the Tradeoffs
Great fit if you're building agents that need to surface real forms, cards, or controls — especially remote agents talking to clients you don't control. Look elsewhere if you only need plain text or markdown replies, or if you need pixel-perfect bespoke layouts: A2UI deliberately constrains you to a shared component vocabulary, and you must implement (and trust) a renderer for every target framework. With v0.9.1 shipped and v1.0 still in release-candidate, the spec and component registry are also still moving.
