A2UI · KITIHub

Ein KI-Agent schickt keinen Code, sondern eine Beschreibung der Oberfläche – deine App baut daraus ein echtes Formular statt einer Textwand.

In 30–45 Minuten: warum reiner Text als Agent-Oberfläche oft umständlich ist, wie A2UI das mit Katalog, Komponenten, Datenmodell und Aktionen löst – und was es von AG-UI, A2A und MCP Apps unterscheidet.

Selbst ausprobieren →Einführung lesen ↓

Beispiel · Animation

Agent → App

createSurfacebooking-surface
updateComponents6 Komponenten
updateComponents„root“
updateDataModel/ = {"reservationTime":"19:00","partySize":2}

App rendert mit eigenen Bausteinen

Reiner Text bremst: Der Agent fragt eine Sache nach der anderen

Du willst einen Tisch reservieren. Im Chat fragt der Agent erst den Tag ab, dann die Uhrzeit, dann die Personenzahl – eine Frage nach der anderen. Das Projekt sagt dazu knapp: „Text-only agent interactions are inefficient.“

Und ein entfernter Agent kann deine Oberfläche nicht einfach umbauen: Agents „can't directly manipulate your UI – they must send messages“. HTML und JavaScript in einer iframe zu schicken, ist schwerfällig, sieht nicht nach deiner App aus und macht die Sicherheit kompliziert.

Beispiel

Ich möchte einen Tisch reservieren.
Gern! Für welchen Tag?
Morgen.
Um wie viel Uhr?
19 Uhr.
Für wie viele Personen?
Zu zweit.
Alles klar: morgen, 19 Uhr, 2 Personen. Soll ich reservieren?

8 Nachrichten – der Agent fragt eine Sache nach der anderen.

Der Agent schickt Daten, keinen Code

Die Leitfrage des Projekts: „how can AI agents safely send rich UIs across trust boundaries?“

Die Antwort: Der Agent schickt eine deklarative JSON-Beschreibung der Oberfläche. Deine App rendert sie mit ihren eigenen, nativen Komponenten. Es wird kein Code ausgeführt – es sind nur Daten, die die App auslegt.

Name: A2UI = „Agent to UI“
Was: „a declarative UI protocol for agent-driven interfaces“
Leitsatz: „safe like data, but expressive like code“
Von: Google, mit Beiträgen von CopilotKit und der Open-Source-Community
Lizenz: Apache 2.0
Angekündigt: 15. Dezember 2025 im Google Developers Blog
Code: github.com/a2ui-project/a2ui (früher google/A2UI)

Gerendert wird nur, was im Katalog steht

Katalog: Die App hat einen Katalog vertrauenswürdiger, vorab freigegebener Komponenten. Der Agent kann nur daraus wählen.
Komponenten in einer flachen Liste: Sie verweisen per ID aufeinander. Das kann ein LLM leicht Stück für Stück erzeugen, korrigieren und streamen.
Drei Ebenen: UI-Struktur, Anwendungszustand (das Datenmodell) und Rendering im Client.
Aktionen: Ein Klick schickt ein event zurück an den Agenten – oder startet per functionCall nur lokal etwas wie openUrl, wovon der Agent nichts erfährt.

Anzeigen

Text
Image
Icon
Video
AudioPlayer

Anordnen

Row
Column
List
Card
Tabs
Divider
Modal

Eingeben

Button
CheckBox
TextField
DateTimeInput
ChoicePicker
Slider

Nicht im Katalog

Map
Chart

Basis-Katalog v0.9.1: 18 Komponenten. = auf dieser Seite im Mini-Renderer nachgebaut.

Sechs Schritte vom Wunsch zur Oberfläche

Der Kreislauf ist immer gleich: Du schreibst, der Agent antwortet mit A2UI-Nachrichten, die App rendert, du interagierst, die Aktion geht zurück, und der Agent schickt aktualisierte Nachrichten.

Technisch heißt das: Generation (Agent erzeugt JSON) → Transport (über A2A, AG-UI o. ä.) → Resolution (Renderer parst JSON) → Rendering (abstrakte Komponenten werden zu nativen Widgets). Das funktioniert mit jedem LLM, das JSON ausgeben kann.

…und wieder von vorn. Ein Klick auf einen Schritt hält den Kreislauf an.

GenerationAgent erzeugt JSON

Transportüber A2A, AG-UI o. ä.

ResolutionRenderer parst JSON

Renderingabstrakt → native Widgets

Vier Nachrichten bauen jede Oberfläche

Jede Nachricht ist ein JSON-Objekt mit "version": "v0.9.1" und genau einem von vier Schlüsseln. Sie müssen der Reihe nach und sauber getrennt ankommen, etwa als JSONL-Zeilen, WebSocket-Frames oder SSE-Events.

Komponenten werden gepuffert, bis root da ist. Daten hängen über JSON Pointer wie /user/name an den Komponenten: Ändert sich der Wert, ändert sich die Anzeige.

createSurface

legt eine Fläche an (Pflicht: surfaceId, catalogId)

updateComponents

fügt Komponenten hinzu oder ändert sie – eine heißt „root“

updateDataModel

setzt Daten an einem Pfad; ohne value wird gelöscht

deleteSurface

entfernt die Fläche

Beispiel: Begrüßung in drei Nachrichten

{"version": "v0.9.1", "createSurface": {"surfaceId": "greeting", "catalogId": "<catalog-uri>"}}
{"version": "v0.9.1", "updateComponents": {"surfaceId": "greeting", "components": [{"id": "root", "component": "Text", "text": {"path": "/user/name"}}]}}
{"version": "v0.9.1", "updateDataModel": {"surfaceId": "greeting", "path": "/user/name", "value": "Alice"}}

Zurück an den Agenten gehen nur zwei Arten: action (Pflicht: name, surfaceId, sourceComponentId, timestamp, context) und error.

JSON rein, Oberfläche raus

Links stehen die Nachrichten, rechts rendert ein Mini-Renderer dieser Seite. Ändere das JSON und sieh sofort, was passiert.

Eingaben landen sofort im Datenmodell.
Der Button schickt eine action – mit den aktuellen Werten an den Stellen, auf die path zeigt.
Erfindest du eine Komponente, wird sie nicht gerendert: VALIDATION_FAILED.

Vereinfacht: Die Eigenschaften der Eingabefelder sind für diese Seite gewählt und nicht spezifikationsgenau.

Beispiel · vereinfachter Mini-Renderer

A2UI-Nachrichten (bearbeitbar)

{
  "version": "v0.9.1",
  "createSurface": {
    "surfaceId": "booking-surface",
    "catalogId": "<catalog-uri>"
  }
}

{
  "version": "v0.9.1",
  "updateComponents": {
    "surfaceId": "booking-surface",
    "components": [
      {
        "id": "title",
        "component": "Text",
        "text": "Tisch reservieren",
        "variant": "title"
      },
      {
        "id": "date",
        "component": "DateTimeInput",
        "label": "Datum",
        "value": {
          "path": "/reservationDate"
        },
        "enableDate": true
      },
      {
        "id": "time",
        "component": "TextField",
        "label": "Uhrzeit",
        "value": {
          "path": "/reservationTime"
        }
      },
      {
        "id": "size",
        "component": "Slider",
        "label": "Personen",
        "value": {
          "path": "/partySize"
        },
        "min": 1,
        "max": 10
      },
      {
        "id": "submit-btn",
        "component": "Button",
        "child": "btn-text",
        "action": {
          "event": {
            "name": "submit_reservation",
            "context": {
              "time": {
                "path": "/reservationTime"
              },
              "size": {
                "path": "/partySize"
              }
            }
          }
        }
      },
      {
        "id": "btn-text",
        "component": "Text",
        "text": "Reservieren"
      }
    ]
  }
}

{
  "version": "v0.9.1",
  "updateComponents": {
    "surfaceId": "booking-surface",
    "components": [
      {
        "id": "root",
        "component": "Column",
        "children": [
          "title",
          "date",
          "time",
          "size",
          "submit-btn"
        ]
      }
    ]
  }
}

{
  "version": "v0.9.1",
  "updateDataModel": {
    "surfaceId": "booking-surface",
    "path": "/",
    "value": {
      "reservationTime": "7:00 PM",
      "partySize": 4
    }
  }
}

Tipp: Ändere „Personen“ oder "max": 10, oder mach aus "Slider" ein "Map".

Tisch reservieren

DatumUhrzeitPersonen 4

Datenmodell (live)

{
  "reservationTime": "7:00 PM",
  "partySize": 4
}

An den Agenten

Noch nichts. Klick auf einen Button – dann erscheint hier die „action“-Nachricht.

Ruf mir einen Wunsch zu – der Agent baut das Formular

Jetzt seid ihr dran: Ruft einen Wunsch rein, zum Beispiel „Ich will ein Fahrrad mieten“. Ein Agent (Claude Haiku) antwortet nicht mit Text, sondern mit A2UI-Nachrichten, und dieselbe App rendert daraus ein Formular.

Der Agent bestimmt was abgefragt wird, die App bestimmt wie es aussieht. Ohne Key oder nach dem Tageslimit kommt eine feste Vorlage nach Stichwort – deutlich als Simulation markiert.

Ruf einen Wunsch rein – der Agent schickt die passende Oberfläche als JSON.

A2UI ist der Inhalt, nicht die Leitung

AG-UI ist der Transport: „use AG-UI as the pipe, A2UI as the content.“
A2A: A2UI-Nachrichten können zwischen Agenten über A2A laufen. A2UI selbst ist kein Transport.
MCP Apps liefern fertiges HTML über ui://-URIs in einer sandboxed iframe, Aussehen und Inhalt bestimmt der Server. Bei A2UI bestimmt die App das Styling.
Angekündigt ist eine Brücke, mit der MCP-Server A2UI-Baupläne neben HTML-Ressourcen anbieten können.
A2UI ist kein Framework, kein Ersatz für HTML, kein Styling-System und nicht aufs Web beschränkt.

Quiz: Wer macht was?

Beschreibt als JSON, welche Oberfläche entstehen soll – der Inhalt.
Die Leitung zwischen Agent und App, über die die Nachrichten laufen.
Verbindet Agenten untereinander – A2UI-Nachrichten können darüber reisen.
Liefert fertiges HTML über ui://-URIs in einer sandboxed iframe, Aussehen bestimmt der Server.

0 von 4 beantwortet

Früher Stand: Rechne mit Änderungen

Das Projekt nennt sich selbst „Early stage public preview“ und schreibt „Expect changes“.
Drei Versionen sind parallel im Umlauf; manche Forks und Mirrors beschreiben noch v0.8.
Renderer gibt es bisher für Web und Flutter. Compose und SwiftUI stehen auf der Roadmap.
Mehrere Pakete sind noch nicht veröffentlicht und müssen aus dem Quellcode genutzt werden.
Der Agent kann nur zeigen, was im Katalog steht, und hat wenig Einfluss aufs Aussehen. Das ist der Sicherheitsgewinn – und zugleich die Grenze.

Version	Status	Wichtigstes
v1.0	Release Candidate	Client-zu-Server-RPC (`actionResponse`), Action-IDs, `theme` heißt `surfaceProperties`
v0.9.1	aktuell	MIME-Typ `application/a2ui+json`, lockerere Regeln für `surfaceId`
v0.9	vorherige stabile	„Prompt-First“: createSurface, Client-Funktionen, eigene Kataloge, modulare Schemas
v0.8	Legacy	„Structured Output first“; die Rückmeldung hieß noch `userAction`

Loslegen: Renderer, Pakete, Werkzeuge

Der schnellste Einstieg ist der Quickstart Restaurant Finder: ein ADK-Agent mit Gemini und dem Lit-Renderer, in etwa fünf Minuten. Du brauchst Node.js 18+, uv und einen Gemini-API-Key. Für A2UI selbst brauchst du kein Gemini – jedes LLM, das JSON ausgeben kann, reicht.

Weitere Beispiele des Projekts:Landscape Architect (Foto hochladen, Gemini wertet es aus, der Agent baut ein Formular zur Gartenplanung) und eigene Komponenten wie ein Diagramm oder eine Google-Karte, die der Client bereitstellt.

Web (npm): @a2ui/lit, @a2ui/angular, @a2ui/react, dazu @a2ui/web_core und @a2ui/markdown-it
Flutter: Das GenUI SDK nutzt A2UI unter der Haube
Python (PyPI): a2ui-core, a2ui-agent-sdk
Dart (pub.dev): a2ui_core, a2ui_agent
Noch nicht veröffentlicht: u. a. @a2ui/agent, a2ui_flutter, die Swift-Pakete
Werkzeuge: A2UI Composer (visueller JSON-Editor), A2UI Theater (Streaming-Szenarien)

Nimm das mit

Daten statt Code, Katalog statt Wildwuchs

Mit A2UI beschreibt der Agent, was die Oberfläche braucht, und deine App entscheidet, wie sie aussieht – nur mit Bausteinen, die du freigegeben hast. Noch ist es eine Public Preview: v0.9.1 ist aktuell, v1.0 ist Kandidat.

a2ui.org →Composer öffnen GitHub Noch mal ausprobieren