Googles A2UI und CopilotKit: Agenten bauen interaktive Oberflächen

Von Textantworten zu gerenderten Oberflächen

Der Beitrag beginnt mit einem Reisebeispiel. Ein Nutzer fragt nach einem Urlaubspaket für Bali im März, und der Agent antwortet mit sechs Paketen in Fließtext und verweist dann für die Buchung auf die Website des Anbieters. Laut den Autoren konnten Agenten die Reise zwar planen, hatten aber keinen standardisierten Weg, eine auswählbare Liste, eine Karte mit Reisezielen oder eine Datumsauswahl innerhalb der Unterhaltung darzustellen.

Generative UI wird als die Schicht beschrieben, mit der Agenten Oberflächen zur Laufzeit aufbauen, zugeschnitten auf das, was die jeweilige Anfrage erfordert. Dafür braucht es zwei Bausteine: eine Möglichkeit, die Oberfläche zu beschreiben, und einen agentischen Stack, der den Agenten mit der Anwendung verbindet und das Ergebnis rendert.

A2UI (Agent-to-UI) ist Googles framework-agnostischer und transport-agnostischer offener Standard für den ersten Baustein. Der Agent beschreibt eine Oberfläche als Daten, und die Anwendung zeichnet sie mit Komponenten, die sie bereits besitzt. CopilotKit liefert den zweiten Baustein. Es lässt sich in Agenten-Frameworks wie LangChain, AWS Strands und Google ADK integrieren und bietet eine Chat-Oberfläche, eine Runtime und einen A2UI-Renderer für React und Angular. Zudem gibt es eigene A2UI-Renderer für Vue und Slack.

Wie A2UI das Spektrum der Generative UI abdeckt

Der Beitrag versteht Generative UI als Spektrum. Am kontrollierten Ende bauen Entwickler jede Komponente vorab, und der Agent wählt aus, welche er mit welchen Daten rendert. Das ist markensicher, begrenzt aber die Personalisierung. Am offenen Ende liefert der Agent ein rohes UI-Programm in HTML, JavaScript und/oder Dart zurück, das in einem Sandbox-Iframe läuft. Das deckt alles Ungeplante ab, doch die Oberfläche kann vom Designsystem abweichen und führt von einem Modell geschriebenen Code aus.

A2UI funktioniert laut dem Beitrag über dieses gesamte Spektrum, wobei der deklarative Modus, in dem Agenten vorab deklarierte Komponenten und Funktionen zusammensetzen, am beliebtesten ist. Der Beitrag nennt mehrere Designprinzipien:

• Sicherheit zuerst: A2UI ist ein deklaratives Datenformat und kein ausführbarer Code. Der Client führt einen Katalog vertrauenswürdiger Komponenten, sodass alles, was der Agent außerhalb dieser Menge erfindet, abgefangen wird, bevor es den Bildschirm erreicht.
• LLM-freundlich und streamingfähig: Die Nutzlast besteht aus einer flachen Liste kleiner JSON-Nachrichten, die sich per ID aufeinander beziehen. Der Agent gibt sie schrittweise aus, und der Client rendert Komponenten, sobald sie eintreffen.
• Framework-agnostisch und portabel: Dieselbe Antwort lässt sich mit React, Lit, Angular, SwiftUI, Jetpack Compose oder Flutter rendern, dazu kommen Community-Renderer für Vue und das Terminal.

Der Basic Catalog enthält 18 universelle Grundbausteine für Layout, Anzeige, Eingabe und Container. Da er bewusst schlank gehalten ist, definieren laut dem Beitrag die meisten Produktivanwendungen einen eigenen Katalog, der alles enthalten kann, was das Frontend ohnehin darstellt, etwa eine Live-Karte.

A2UI mit CopilotKit einrichten

CopilotKit baut auf AG-UI (Agent-User Interaction Protocol) auf, das A2UI-Nutzlasten unterstützt und Agenten-SDKs für viele Backends bereitstellt. Der Agent gibt A2UI-Operationen aus, AG-UI überträgt sie als typisierte Events an den Client, und Nutzeraktionen laufen im selben Stream zurück. Der Beitrag nennt Google ADK, LangChain, Mastra und Strands als AG-UI-kompatibel, sodass die Einrichtung unabhängig vom verwendeten Agenten gleich bleibt.

Am Beispiel von Google ADK: Das Paket ag_ui_adk umhüllt einen ADK-Agenten und stellt ihn als AG-UI-Endpunkt auf FastAPI bereit. Auf der App-Seite wird der Endpunkt unter /api/copilotkit bei der CopilotKit-Runtime registriert, wofür laut dem Beitrag nichts A2UI-Spezifisches nötig ist. Aktiviert wird A2UI auf der Client-Seite: Entwickler definieren, was der Agent zeichnen darf, ordnen jeder Definition einen Renderer zu und übergeben den Katalog an den CopilotKit-Provider.

Im Beispiel besteht eine FlightCard-Definition aus einer Beschreibung und einem Zod-Schema. Die Beschreibung fließt in den Prompt des Agenten ein, damit das Modell weiß, wann es sie verwenden soll, und das Schema validiert die Props, die das Modell zurückschickt. Die Konfiguration lässt sich vorab auf dem Server einrichten oder dynamisch erzeugen und vom Client mit der Anfrage mitschicken. Entwickler können CopilotKit auch überspringen und den Event-Stream direkt mit @ag-ui/client verarbeiten, indem sie die Operationen an einen kompatiblen Renderer wie @a2ui/react weitergeben.

Bidirektionale Oberflächen für mehrstufige Abläufe

Der Beitrag argumentiert, dass die meisten von Agenten erzeugten Oberflächen einmalig sind und veralten, sobald sich etwas ändert. A2UI-Oberflächen seien bidirektional und ihre Komponenten reaktiv: Aktionen wie die Wahl von Daten, die Auswahl eines Flugs oder die Eingabe von Passagierdaten laufen im Stream zurück, und der Agent gibt die Oberfläche mit diesen Werten erneut aus.

Zwei Dinge machen diesen Rundlauf möglich: Eingaben, die an einen Datenpfad gebunden sind, und ein Button mit einer Aktion, die festlegt, welche Pfade zurückgesendet werden. Die Validierung läuft auf dem Client, sodass eine fehlerhafte E-Mail-Adresse ohne Modellaufruf einen Inline-Fehler anzeigt und nichts beim Agenten ankommt, bevor der Button ausgelöst wird. Der Agent gibt die Oberfläche anschließend unter derselben surfaceId erneut aus, sodass Flugsuche, Ergebnisse, Passagierdaten und Bestätigung auf einer einzigen Oberfläche stattfinden können. Der Beitrag veranschaulicht das mit einem AG-UI-Agenten auf Cloud Run, der A2UI-Oberflächen an ein CopilotKit-Frontend streamt.

Was das für Entwickler bedeutet

Für Frontend-Teams lautet das Versprechen des Beitrags, Bausteine einmal auszuliefern und den Agenten sie für jede Anfrage neu zusammensetzen zu lassen, wobei ein vertrauenswürdiger Katalog die Grenze dessen bildet, was auf dem Bildschirm erscheinen darf. Teams, die bereits Agenten-Frameworks wie ADK oder LangChain nutzen, können A2UI laut dem Beitrag mit einer kurzen clientseitigen Katalogdefinition ergänzen, ohne ihren Backend-Ansatz zu ändern.