A2UI 소개: 에이전트 기반 인터페이스를 위한 오픈 프로젝트

Source: Google Developers Blog

Generative AI does great at generating text, images, and code. Now, it’s time for it to be used to generate contextually relevant interfaces. Today we are making the A2UI project public so we can collaborate with others on this early‑stage format and implementations. A2UI was designed to address the specific challenges of interoperable, cross‑platform, generative or template‑based UI responses from agents. A2UI allows agents to generate the interface which best suits the current conversation with the agent, and send it to a front‑end application. We have been building A2UI for some of our products, and we would like to engage with the community to help refine the A2UI specifications, add more transports, and add more client renderers and integrations.

A2UI is an open‑source project, complete with a format optimized for representing updateable, agent‑generated UIs and an initial set of renderers. It allows agents to generate or populate rich user interfaces that can be displayed in different host applications and rendered by a range of UI frameworks such as Lit, Angular, or Flutter (with more to come). Renderers support a set of common components and/or a client‑advertised set of custom components which are composed into layouts. The client owns the rendering and can integrate it seamlessly into their branded UX. Orchestrator agents and remote A2A sub‑agents can all generate UI layouts which are securely passed as messages, not as executable code.

Below are examples of A2UI rendered cards, showing a variety of UI compositions that A2UI can achieve.

The Problem: Agents need to speak UI

Imagine an agent designed to help you book a table at a restaurant. A text‑only interaction might involve a clunky back‑and‑forth:

User: “Book a table for 2.”
Agent: “Okay, for what day?”
User: “Tomorrow.”
Agent: “What time?”
User: “Maybe 7 p.m.”
Agent: “We do not have reservation availability then, any other times?”
User: “When do you have reservations?”
Agent: “We have availability at 5:00, 5:30, 6:00, 8:30, 9:00, 9:30 and 10:00. Do any of those work for you?”

This can be slow and inefficient. A better experience would be for the agent to quickly generate, or use, a simple form with a date picker, a time selector, and a submit button. With A2UI, LLMs can compose bespoke UIs from a catalog of widgets to provide a graphical, beautiful, easy‑to‑use interface for the exact task at hand.

For example, instead of the text‑based chat above, you can use A2UI to compose a reservation UI. The image below shows one possible rendering of an A2UI representation of the restaurant booking (many other possibilities exist thanks to A2UI’s design, which gives the front‑end host app a lot of control over styling).

The Challenge: Rendering across trust boundaries

We are entering the era of the multi‑agent mesh. Agents from Google are talking to agents from Cisco, IBM, SAP, and Salesforce to solve complex tasks. This is why we collectively created the Agent‑to‑Agent (A2A) Protocol and donated it to the Linux Foundation: to enable agents to collaborate even when they don’t share memory, tools, or context.

However, this decentralization creates a user‑interface problem.

If your agent lives inside your application, it can directly manipulate the view layer (e.g., the DOM). In a multi‑agent world, the agent doing the work is often remote—running on a different server or owned by a different organization. It cannot touch your UI directly; it must send messages.

Historically, rendering UI from a remote, untrusted source meant sending HTML or JavaScript and sandboxing it inside iframes. This approach is heavy, can be visually disjointed (it rarely matches your app’s native styling), and introduces complexity around security boundaries.

We needed a way to transmit UI that is safe like data, but expressive like code.

The Solution: UI spec as a sequence of messages

A2UI provides a standard format which can be generated on the fly as structured output, or used as a template and hydrated with values. The JSON payload can be sent to the client over A2A, AG UI, or other transports. The client application renders using its own native UI components. This means the client retains full control over styling and security, ensuring the agent’s output always feels native to your app.

Example: Photo‑based landscaping form

In this example, the user uploads a photo, and a remote agent uses Gemini to understand it and creates a bespoke form for the specific needs of the landscaping customer.

Example: Interactive chart and map

In this example, the agent responds with a custom component containing an interactive chart and another custom component containing Google Maps.

Core Philosophy: Secure, updateable, and decoupled

We designed A2UI around a few key principles:

• Security first – A2UI is a declarative data format, not executable code. Your client application maintains a catalog of trusted, pre‑approved UI components (e.g., Card, Button, TextField). The agent can only request components from that catalog, reducing the risk of UI injection and other vulnerabilities.
• LLM‑friendly and incrementally updateable – The UI is represented as a flat list of components with ID references, which is easy for LLMs to generate incrementally. This enables progressive rendering and responsive user experiences, allowing agents to make incremental changes as the conversation evolves.
• Framework‑agnostic and portable – A2UI separates UI structure from UI implementation. The agent sends a description of the component tree and its data model; the client maps these abstract descriptions to native widgets—whether web components, Flutter widgets, React components, SwiftUI views, or anything else. The same A2UI JSON payload can be rendered on multiple clients built with different frameworks.

Navigating the agentic UI ecosystem

The space for agentic UI is evolving rapidly, with excellent tools emerging to solve different parts of the stack. We view A2UI not as a replacement for these frameworks, but as a specialized protocol that solves the specific problem of interoperable, cross‑platform, generative or template‑based responses.

Mapping the landscape

• Building the “host” application UI
  If you are building a full‑stack application (the “host” UI …)