Skip to content
#AI

[1/2] Google Opens A2UI, a Protocol That Lets Agents Speak UI, Not Just Text (AI column)

#AI #Engineering #Agents #Software #Architecture #RnD #ML #DistributedSystems

15 December 2025 Google's A2UI team publicly posted A2UI (Agent-to-User Interface) Open format + rendering libraries so that “remote” AI agents can return complex (forms, cards, lists, buttons) as data, not as executable code. This protocol is designed to solve the problem of text chats, when simple user actions (book a table, fill the fields, choose the time) They turn into a long correspondence “question-answer-clarification”. A2UI suggests instead giving the agent the ability to generate context-form from the component catalog and draw it in your application. The protocol itself is available GitHub.

Essentially, this works roughly as follows – the agent generates a declarative description of the UI in JSON, the client renders it with the native components of its application. Key principles (formulated READMEME**):

  • Security‑first**The agent does not send the JS/HTML/code. It sends data that is validated, and the UI is built from a catalog of pre-permitted components. (Button/Card/TextField/etc). This reduces the risk of UI injections and “accidental RCE via UI.” - LLM-friendly + incremental updates: UI is described by a “flat” structure. (adjacency list) with ID links, so the agent can stream interface patch individual components by ID without sending the entire tree - Framework‑agnostic: The same A2UI-Peyload can be rendered in different clients (web/mobile/desktop) “How to paint” is decided by the client. - Transport‑agnostic: A2UI is a message format/contract that can be run over different “transports” (including A2A and AG-UI)

In practice. (v0.8, stable/public preview) The messages usually go as JSON Lines. (JSONL): one line = one message. There. 4 keynote:

  • beginRendering
  • surfaceUpdate
  • dataModelUpdate
  • deleteSurface The stream itself might look something like this.
{"surfaceUpdate": {"surfaceId":"main","components":[ ... ]}}
{"dataModelUpdate": {"surfaceId":"main","contents":[ ... ]}}
{"beginRendering": {"surfaceId":"main","root":"root-component"}}

But it should be noted that the speck is still being worked out between v0.8 (stable) and v0.9 (draft) There are already changes in the details and even the names of envelope messages.

Now let's talk about why this protocol is interesting to us and why it's better than the alternatives. 1. One alternative is to generate HTML/JS/React code by an agent.. Here we have a security and control problem -- you either have to execute untested code or you have to build a heavy sandbox. In A2UI, we have data instead of code, and rendering comes only from a trusted component catalog. 2. Another alternative is iframe approaches / “UI as a resource” (For example, MCP Apps) In the article, Google directly compares A2UI to MCP Apps: there UI often comes as “opaque payload”. (HTML) And rendered in the sandboxed iframe. But A2UI favorably has a “native-first” approach: the agent sends a blueprint of native components, and the UI inherits the style/design-system/accessibility of the host application, instead of a separate “mini-web in the iframe.” 3. End2end Platform Ecosystems (For example, OpenAI ChatKit) The solution is integration within a single platform. The disadvantage is portability and work in multi-agent scenarios with different vendors. A2UI targets a portable UI contract for your own customers and enterprise-mesh scenarios. 4. Just take AG-UI and stop. AG-UI Solves the Integration of Agent and UI)A2UI describes the UI response format. Google clearly positions A2UI as a complementary layer: connected host through AG-UI → you can use A2UI as a format for UI responses, including from external agents

Let’s talk about why this project is so interesting.

#Engineering #AI #Agents #Software #Architecture #RnD #ML #DistributedSystems