Google führt A2UI Express als Zwischenformat mit kataloggebundenem Compiler ein

Google hat am 27. Oktober 2026 im Google Developers Blog A2UI Express vorgestellt, ein auf Inferenzgeschwindigkeit und Genauigkeit optimiertes Zwischenformat für Agenten. Statt JSON schreibt das Modell eine kompakte Syntax, die deterministischer Code in den Agent-SDKs in das JSON-basierte Transportprotokoll übersetzt.

Warum direktes JSON gebremst hat

A2UI ist laut Google ein Protokoll für generative Oberflächen. Der Client bietet dabei einen Katalog vertrauenswürdiger Komponenten als Vertrag an, der Agent setzt daraus eine Oberfläche zusammen, und der Renderer des Clients zeichnet sie. Anfangs erzeugten Agenten die JSON-Nachrichten direkt, mit jeder geschweiften Klammer und jedem verschachtelten Element. Für Sprachmodelle ist das langsam und fehleranfällig, sobald ein komplexes JSON-Schema die Bäume einschränkt.

Aufgedeckt haben die Probleme mit Latenz und Genauigkeit Rückmeldungen von Kunden. Darauf reagiert Google mit Express. Für gleichartige Oberflächen braucht das neue Format nach Googles Angabe bis zu dreimal weniger Tokens, verglichen mit Direct JSON. Das ist eine Obergrenze. Eine typische Ersparnis für den eigenen Katalog lässt sich daraus nicht ablesen.

Prompt und Compiler aus demselben Katalog

Als Inferenzformat bezeichnet Google das Format, in dem das Modell antwortet. Es besteht aus zwei Teilen, die das SDK beide aus dem JSON-Schema deines Katalogs erzeugt. Ein Prompt-Abschnitt bringt dem Modell die Syntax bei, ein Compiler macht aus der Modellantwort validierte A2UI-Nachrichten. Weil beides aus dem Schema stammt, kann ein Format keine Komponente und keine Eigenschaft beschreiben, die dein Katalog nicht kennt.

Der Katalog zieht damit die Grenze.

In den SDKs hängt die Wahl an einem einzigen Argument beim Erzeugen des Generators, im Python-SDK an inference_format_factory=ExpressFormatFactory(), in TypeScript an new ExpressFormatFactory() als drittem Argument. Für Sonderfälle ist auch eine andere Syntax samt zugehörigem Compiler einsetzbar.

So liest sich Express

Die Syntax ist an Python angelehnt. Googles Beitrag beschreibt eine Anweisung pro Zeile: Bei Komponentendefinitionen weist eine Zeile einer Variablen eine Komponente zu, und der Variablenname wird standardmäßig zur Komponenten-ID. Die technische Spezifikation auf a2ui.org kennt daneben eigenständige Befehle wie surface(...), Zuweisungen ins Datenmodell und Anweisungen über mehrere Zeilen. Argumente stehen positionsgebunden. Der Compiler ordnet sie den Eigenschaftsnamen in der Reihenfolge zu, in der das Katalogschema sie deklariert; _ überspringt eine Position.

Ein Ausschnitt aus der Benachrichtigungskarte der A2UI-Galerie, wie Google sie in Express zeigt:

root=Card(main_column)
main_column=Column([icon, title, description, actions], _, "center")
icon=Icon($/icon)
yes_btn=Button(yes_btn_text, _, Event("accept", {}))

$/title bindet einen Wert an das Datenmodell, Event("accept") deklariert eine Server-Aktion.

Übersetzung und Fehlerbehandlung im Compiler

Laut der Spezifikation auf a2ui.org übersetzt ein Compiler auf der Host-Seite Express in Standardnachrichten von A2UI v1.0. Für ältere Protokollziele wie v0.9 sieht sie teils andere Ausgaben vor, etwa getrennte Nachrichten für Oberfläche, Komponenten und Datenmodell.

Der Umbau der Struktur ist für v1.0 beschrieben. Dort verlangt das Protokoll ein flaches Komponenten-Array, in dem Verschachtelung über Verweise auf IDs abgebildet wird. Der Compiler folgt den Variablenverweisen ab root und gibt ein einzelnes flaches Array von Komponenten aus.

Für Syntaxfehler und Abweichungen vom Katalogschema sieht die Spezifikation einen eigenen Wiederherstellungsablauf vor. Der Compiler markiert die ungültige Zeile, verwirft den zugehörigen Zweig und parst die übrigen Zeilen weiter. Ziel ist, dass die Oberfläche nicht zusammenbricht. Die Korrektur übernimmt ein Modell. Der Agent packt die fehlerhafte Zeile, die Signatur der betroffenen Komponente und die Fehlermeldung des Parsers in einen kleinen Korrektur-Prompt für ein schnelles Modell, und dessen korrigierte Anweisung fügt der Compiler vor der endgültigen Ausgabe in den geparsten Baum ein.

SDK-Stand und die Grenze beim Streaming

Express ist laut Google im Python-Agent-SDK (a2ui-agent-sdk 0.9.0 auf PyPI), im TypeScript-Agent-SDK (@a2ui/agent auf npm) und im Dart-SDK (a2ui_agent 0.0.1-wip004 auf pub.dev) verfügbar. Die Unterschiede stecken im Detail. Für Dart vermerkt die Spezifikation, dass der Express-Compiler v1.0 noch nicht unterstützt. Die Unterstützung mehrerer Kataloge ist dort für die Python- und TypeScript-SDKs als implementiert beschrieben.

Beim Streaming lohnt ein genauer Blick. In der Spezifikation steht, die zeilenorientierte Grammatik erlaube es dem Client-Host, die Komponentenhierarchie Zeile für Zeile aufzubauen und die Oberfläche progressiv darzustellen, bevor das Modell fertig ist. Die Ankündigung beschreibt den aktuellen SDK-Stand anders: Python- und TypeScript-SDK können Direct JSON stückweise streamen, Express kompilieren sie aus der vollständigen Antwort.

Zeilenweises Rendern ist für Express damit vorerst in der Grammatik angelegt, aber kein Merkmal der aktuellen Python- und TypeScript-SDKs.

51 Aufgaben, vier Formate

Für die Formatwahl hat Google vier Varianten getestet: Direct JSON als bisherige Basis, Express, Atom mit S-Ausdrücken im Lisp-Stil und Elemental mit HTML und eigenen Elementen. Alle vier liefen durch dieselbe Evaluation mit 51 Aufgaben auf gemini-3.5-flash, jeweils mit eingeschaltetem und ausgeschaltetem Thinking. In diesem Test funktionierte Express nach Googles Beobachtung auch mit ausgeschaltetem Thinking genauso gut.

Die Ergebnisse stammen aus einem Modell und einem Aufgabensatz. Auf andere Modelle oder Kataloge lassen sie sich nicht ohne eigene Prüfung übertragen.

Für den Betrieb mit Express empfiehlt Google ausgeschaltetes Thinking.

Wo Express aufhört und Entscheidungsmodelle anfangen

Für Bildschirme mit bekannter Form, etwa Einstellungsseiten oder einen Checkout, beschreibt Google einen zweiten Weg: Ein Entscheidungsmodell wählt zwischen vorher definierten Layouts. Als Beispiel dient Jev von TypeSafe, das Google als System-One-Modell bezeichnet. Die A2UI-Agent-SDKs enthalten laut Google aber noch kein Inferenzformat für Entscheidungsmodelle; das Projekt Apparite (jev2ui) ist ein Beispiel dafür, wie sich A2UI-Nachrichten aus solchen Entscheidungen zusammensetzen lassen.

Google rät, danach zu wählen, wie viel vom Bildschirm sich vorab festlegen lässt: kontrollierte Generierung, wenn ein Entscheidungsmodell liefern kann, was du brauchst, Express für volle Ausdrucksstärke. Kontrollierte Generierung kann nur die Layouts erzeugen, die ihre Grammatik beschreibt. Die Grammatik von Apparite deckt neun Bildschirmtypen und zwölf Bausteine ab. Bildschirme, deren Form diese Grammatik nicht vorab festlegt, passen nach Googles Einschätzung deshalb besser zu Express.

Weiterlesen: Jev trennt Agentenentscheidungen von Textgenerierung und Behavioral Evals: Google erklärt Tests für Coding-Agenten.