AG-UI verstehen: Der Standard für Agentic User Interfaces

Agentic UI, unabhängig von Backend-Technologien und LLM

Sobald ein LLM im Frontend nicht nur Antworten erzeugt, sondern auch Tools aufruft, Formulare füllt, Routen wechselt oder UI-Komponenten auswählt, wird die Integration schnell unübersichtlich. Client, Agent und Modell greifen ineinander, und aus einer praktischen Lösung entsteht leicht ein eng gekoppeltes System. Genau hier setzt AG-UI an und definiert eine klare, nachrichtenbasierte Schnittstelle zwischen Frontend und Agent.

Dieser erste Teil der Serie zeigt, welche Probleme AG-UI adressiert, wie Runs, Nachrichten und Tool Calls zusammenspielen und warum der Standard eine entkoppelte Architektur ohne Vendor Lock-in ermöglicht.

📂 Source Code (siehe Branch agentic)

Was ist Agentic AI im Frontend?

Agentic AI bezeichnet Systeme, bei denen ein Sprachmodell nicht nur Text generiert, sondern mehrstufige Aufgaben bearbeitet, Tools nutzt und mit Anwendungen interagiert. Im Frontend zeigt sich das zum Beispiel dann, wenn ein Sprachmodell nicht nur Text liefert, sondern auch mit Stores, Routing und Formularen interagiert.

Das bedeutet nicht, dass die Anwendung nicht mehr auf herkömmliche Weise verwendet werden kann: Unsere Demo-Anwendung lässt sich ganz ohne AI-Integration verwenden. Wenn Benutzer allerdings feststecken oder Arbeitsschritte abkürzen möchten, können sie ein sogenanntes Sidecar aktivieren und über einen serverseitigen Agent mit einem LLM chatten:

Zur Beantwortung von Fragen kann das LLM auf Tools zurückgreifen, die das Sidecar bereitstellt. Im Backend können sie zum Beispiel auf Datenbanken zugreifen und im Frontend kümmern sie sich um Aufgaben rund um Stores, Formulare und Routing.

Außerdem kann das LLM Komponenten aus einem Katalog auswählen, die das Sidecar dann anzeigt. An diese Komponenten übergibt es Daten, die über Tools ermittelt wurden.

Im gezeigten Fall kommen zwei Werkzeuge zum Einsatz: Bei getBookedFlights handelt es sich um ein serverseitiges Tool, das die Flüge des aktuellen Benutzers in Erfahrung bringt. Das Tool findFlights stößt hingegen eine Flugsuche im Client an. Es wechselt auf die Route mit dem Suchformular, füllt es aus und triggert die Suche.

Aus Transparenzgründen ist es gute Praxis, den Benutzer über die durchgeführten Schritte wie Tool Calls zu informieren. Das gezeigte Beispiel macht das sehr explizit, indem es auch die internen Toolnamen ausgibt. In einer Fachanwendung würde man das etwas weniger technisch formulieren. Anstatt Tool Call: getBookedFlights könnte das Sidecar zum Beispiel Ermittle gebuchte Flüge ... in den Chatverlauf schreiben.

Neben den Tool Calls zeigt der Chat auch textuelle Antworten sowie eine Flugkarte an, die das LLM ausgewählt hat. Dieser Karte übergibt das Sidecar den anzuzeigenden Flug. Dazu greift die Angular-Anwendung über HTTP auf den Agent zu, der wiederum Zugriff auf ein oder mehrere LLMs hat:

Um die Details dieser Kommunikation kümmert sich ein Agent Client, der den Agent über die zur Verfügung stehenden clientseitigen Tools und Komponenten informiert. Der Agent hat zusätzlich eine Liste serverseitiger Tools.

Wenn der Agent die Anfrage des Benutzers an das LLM weiterleitet, übersendet er auch die gesammelten Infos zu serverseitigen Tools, clientseitigen Tools und zu den Komponenten. Das LLM entscheidet nun, welche weiteren Daten es braucht, und fordert Tool Calls an. Um serverseitige Tool Calls kümmert sich der Agent selbst, und die Ausführung clientseitiger Tools delegiert er an den Agent Client. Die so gewonnenen Ergebnisse meldet er an das LLM zurück, das daraufhin die Bearbeitung seiner Aufgabe fortsetzt.

Zur schlussendlichen Beantwortung der Anfrage antwortet das LLM mit Freitext. Außerdem kann es ein JSON-Dokument übermitteln, das angibt, welche Komponenten das Sidecar anzeigen soll. Auch die Werte für die Inputs dieser Komponenten sind im JSON enthalten. Abhängig von den Möglichkeiten des LLMs handelt es sich bei diesem JSON-Dokument um eine strukturierte Antwort oder um Parameter, die es an ein clientseitiges Tool übergibt.

Die strukturierte Antwort, also Structured Output, ist semantisch gesehen die sauberere Lösung. Leider unterstützen einige Modelle die gleichzeitige Nutzung von Tool Calling und Structured Output nicht. Außerdem unterstützen viele LLMs eine formale Beschreibung von Parametern für Tool Calls mittels JSON Schema. Deswegen ist die Nutzung von Tool Calling zur Anzeige von Komponenten häufig die pragmatischere Lösung.

Nun ergibt sich die Frage, wie die Kommunikation mit dem Agent gestaltet werden soll, ohne eine zu starke Kopplung mit dem Client zu erhalten. Der Standard AG-UI liefert darauf eine Antwort.

Was ist AG-UI?

Um unabhängig von den gewählten Servertechnologien zu bleiben und Vendor-Lock-in bei einzelnen LLM-Anbietern zu vermeiden, definiert der Standard AG-UI die Nachrichtentypen für die Kommunikation zwischen Client und Agent. Hinter dem Standard stehen die Macher von CopilotKit, einem komfortablen Frontend SDK für die Entwicklung von AI-basierten Assistenten und Sidecars. Mittlerweile existieren Adapter für so gut wie alle namhaften Agent Frameworks.

Als dieser Artikel verfasst wurde, hat die AG-UI Website die folgenden unterstützten Frameworks gelistet:

• AG2
• Agno
• AWS Bedrock AgentCore
• AWS Bedrock Agents
• AWS Strands Agents
• Cloudflare Agents
• CrewAI
• Google ADK
• LangGraph
• LlamaIndex
• Mastra
• Microsoft Agent Framework
• OpenAI Agent SDK
• Pydantic AI

AG-UI definiert Nachrichten, die zwischen Client und Agent ausgetauscht werden. Diese Nachrichten beschreiben zum Beispiel die Übertragung von Text oder Tool Calls samt Ergebnissen. Nachfolgende Nachrichten können Informationen aus vorherigen konkretisieren. Das ist die Grundlage für das Streaming von Texten sowie Parametern für Tool Calls.

AG-UI ist bewusst transportagnostisch gestaltet, das heißt, es trifft keine Annahmen über das darunterliegende Transportprotokoll. Typischerweise kommen HTTP mit Server-sent Events (SSE) oder WebSockets zum Einsatz.

Nachrichtentypen in AG-UI

Für die einzelnen zwischen Agent und Client ausgetauschten Nachrichten legt AG-UI Typen fest, die sich wiederum in verschiedene Kategorien untergliedern lassen. Die nachfolgende Tabelle zeigt eine Auswahl von Nachrichtentypen, die wir in diesem Artikel nutzen werden:

Der hier verwendeten Nomenklatur zufolge startet ein Run mit einer Frage des Benutzers. Er umfasst sämtliche Nachrichten, die der Agent zur Beantwortung versendet. Dazu gehören Nachrichten rund um Tool Calls, Ergebnisse von Tool Calls sowie textuelle Antworten. In der eingangs gezeigten Beispielanwendung lassen sich zum Beispiel zwei Runs erkennen.

Um Streaming zu ermöglichen, erlaubt AG-UI das Aufteilen der meisten Informationen in mehrere Nachrichten. Beispiele dafür sind die Nachrichtentypen TEXT_MESSAGE_CONTENT sowie TOOL_CALL_ARGS. Mehrere Nachrichten dieser Typen können nach und nach Text oder weitere Argumente für einen Tool Call liefern.

Die folgenden Nachrichten spiegeln den ersten Run aus der eingangs gezeigten Beispielanwendung wider und veranschaulichen die Nutzung von AG-UI:

{"type":"RUN_STARTED", "threadId":"f66a", "runId":"95e2"}

{"type":"TOOL_CALL_START", "toolCallId":"3PQX", "toolCallName":"getBookedFlights"}
{"type":"TOOL_CALL_ARGS", "toolCallId":"3PQX", "delta":"{}"}
{"type":"TOOL_CALL_END", "toolCallId":"3PQX"}
{"type":"TOOL_CALL_RESULT", "toolCallId":"3PQX", "content":"...JSON...", "role":"tool"}

{"type":"TEXT_MESSAGE_START","messageId":"d110","role":"assistant"}
{"type":"TEXT_MESSAGE_CONTENT","messageId":"d110", "delta":"Yes - you already booked "}
{"type":"TEXT_MESSAGE_CONTENT","messageId":"d110", "delta":"a flight to France."}
{"type":"TEXT_MESSAGE_END","messageId":"d110"}

{"type":"TOOL_CALL_START", "toolCallId":"TjaS", "toolCallName":"showComponents"}
{"type":"TOOL_CALL_ARGS", "toolCallId":"TjaS", "delta":"...JSON..."}
{"type":"TOOL_CALL_END", "toolCallId":"TjaS"}

{"type":"RUN_FINISHED", "threadId":"f66a", "runId":"95e2"}

Diese Nachrichten beschreiben Tool Calls für das Server-Tool getBookedFlights und für das Client-Tool showComponents sowie eine textuelle Antwort. Aus Gründen der Lesbarkeit wurden die IDs, die typischerweise GUIDs sind, gekürzt und das in Strings eingebettete JSON mit Argumenten und Tool-Ergebnissen nur angedeutet. Dank der IDs lässt sich nachvollziehen, zu welchem zuvor gestarteten Tool Call die nachgelieferten Argumente oder protokollierten Resultate gehören.

Damit bereits während der Übertragung erste Inhalte angezeigt werden können, teilt der Agent seine Antwort in mehrere Textnachrichten auf. Ähnlich wie bei den Tool Calls werden auch hier die Nachrichten, die zusammen eine Antwort bilden, mit derselben ID versehen. Die beiden Lifecycle Messages, die den Run starten und abschließen, enthalten neben der runId auch eine threadId, um sämtliche Runs eines Chatverlaufs zu gruppieren.

Zusammenfassung

AG-UI definiert eine klare Schnittstelle zwischen Frontend und Agent, die Runs, Texte und Tool Calls einheitlich beschreibt. Dadurch lassen sich Streaming, Tool Calling und UI-Updates standardisiert abbilden, ohne sich auf ein bestimmtes Agent-Framework oder einen bestimmten LLM-Anbieter festzulegen.

Für agentische Frontends bedeutet das vor allem Unabhängigkeit von Backend-Technologien und weniger Vendor-Lock-in. Als erster Teil dieser Serie legt der Artikel die fachlichen Grundlagen. Im nächsten Teil betrachten wir das SDK für AG-UI und zeigen, wie sich Runs, Nachrichten und Tool Calls auf Client- und Serverseite praktisch umsetzen lassen.

FAQ

Was ist Agentic AI?

Agentic AI beschreibt Systeme, bei denen ein Sprachmodell nicht nur Antworten formuliert, sondern Aufgaben plant, Tools aufruft und mit Anwendungen interagiert. Im Frontend betrifft das zum Beispiel Sidecars, Tool Calling und das dynamische Anzeigen von UI-Komponenten.

Was ist AG-UI?

AG-UI ist ein Standard für die Kommunikation zwischen Client und Agent. Er definiert Nachrichtentypen für Runs, Textnachrichten und Tool Calls und schafft damit eine transportagnostische Schnittstelle für agentische Frontends.

Wofür braucht man AG-UI im Frontend?

AG-UI hilft dabei, Frontend, Agent und Modell sauber voneinander zu entkoppeln. Dadurch lassen sich Streaming, Tool Calls und UI-Updates standardisiert umsetzen, ohne sich früh an ein bestimmtes Framework oder einen Anbieter zu binden.

Wie hängen Runs, Nachrichten und Tool Calls zusammen?

Ein Run umfasst sämtliche Nachrichten, die zur Bearbeitung einer Benutzeranfrage ausgetauscht werden. Dazu gehören textuelle Antworten, Tool Calls, Tool-Ergebnisse und Statusinformationen wie Start, Ende oder Fehler eines Runs.