Skip to content

Agent UI Ecosystem

The agentic UI space is evolving rapidly. This page helps you understand where A2UI fits relative to other approaches.

Comparison

A2UI MCP Apps AG UI
Approach Agent sends declarative component blueprints Server provides pre-built HTML via ui:// URIs High-bandwidth protocol connecting any agent backend to any frontend
Rendering Native components (Angular, Flutter, Lit, etc.) Sandboxed iframe Developer-defined (any framework)
Styling Client controls — inherits host design system Isolated — server controls appearance Developer controls — part of the host app
Security Declarative data, no code execution Sandboxed iframe isolation Trusted code within your own app
Multi-agent ✅ Agents across trust boundaries ✅ Multiple MCP servers can each provide UI ⚠️ Primarily for apps where you build both agent and frontend
Cross-platform ✅ Web, mobile, desktop, native ⚠️ Web-focused (iframe) ✅ Protocol is framework-agnostic
LLM generation ✅ Designed for streaming LLM output ❌ Pre-built by server ✅ Via A2UI integration
Spec Open protocol (Apache 2.0) Part of MCP specification Open source protocol (by CopilotKit)

A2UI Integrations

Several projects have built A2UI renderers and integrations:

  • json-render — Vercel's React library for rendering A2UI component catalogs via Zod schemas. Maps A2UI's declarative JSON to React components. See json-render vs. A2UI comparison for an in-depth technical breakdown of the "monolith vs. protocol" tradeoff.
  • OpenClaw Canvas — OpenClaw uses A2UI to render agent-generated UI on connected devices (Mac, iOS, Android) via its canvas system and native node apps. See OpenClaw architecture overview for how A2UI fits into their agent runtime.

A2UI + MCP Apps Bridge

We are actively working on bridging A2UI and MCP Apps, enabling MCP servers to provide A2UI component blueprints as an alternative to HTML resources. This would let MCP tools return native, styled UI that renders in any A2UI-capable client. Follow progress on GitHub.

When to Use Each

Choose A2UI when:

  • Agents generate UI dynamically (forms, dashboards, workflows)
  • You need cross-platform rendering (web + mobile + desktop)
  • Multiple agents from different providers need to render UI in your app
  • Brand consistency matters — the client must control styling
  • Security is critical — no code execution from untrusted agents

Choose MCP Apps when:

  • The server owns the full UI experience (self-contained widgets)
  • You want iframe isolation with minimal client integration
  • UI is a pre-built resource, not dynamically generated by an LLM
  • Multiple MCP servers each provide their own isolated UI surfaces

Choose AG UI when:

  • You're building both the agent backend and the frontend together
  • You need high-bandwidth, real-time state synchronization between agent and client
  • You want a flexible transport layer that works with any frontend framework

AG UI vs. CopilotKit

AG UI is the open protocol for connecting agent backends to frontends — it's framework-agnostic. CopilotKit is a React-specific frontend framework built by the same team that also created AG UI. You can use AG UI without CopilotKit.

Using Them Together

These approaches are complementary, not competing:

  • A2UI + AG UI: Use AG UI as the transport layer connecting your agent backend to your frontend, and A2UI as the format for generative UI payloads — especially from remote or third-party agents.
  • A2UI + A2A: Send A2UI messages via the A2A protocol for multi-agent systems where agents communicate across trust boundaries.
  • A2UI + MCP: With the upcoming bridge, MCP servers will be able to provide A2UI blueprints alongside HTML resources, giving clients a choice of rendering approach.

Further Reading