Agentic UI – losgelöst von Backend-Technologien und LLM
Wenn ein LLM im Frontend über das bloße Erzeugen von Antworten hinausgeht, also Werkzeuge aktiviert, Formulare ausfüllt, Routen ändert oder UI-Elemente ansteuert, gerät die Integration rasch aus dem Ruder. Der Client, der Agent und das Modell greifen ineinander, und eine sinnvolle Lösung mutiert schnell zu einem stark verflochtenen Konstrukt. Genau für diesen Fall liefert AG-UI einen definierten, auf Nachrichten basierenden Kanal zwischen Frontend und Agent.
Der erste Teil dieser Reihe beleuchtet, welche Schwierigkeiten AG-UI lösen will, wie Runs, Nachrichten und Tool-Calls zusammenhängen und weshalb dieser Standard eine lose Kopplung ermöglicht, die von Anbietern unabhängig bleibt.
📂 Source Code (Branch copilotkit)
Was bedeutet Agentic AI im Frontend?
Bei Agentic AI übernimmt ein Sprachmodell mehr als nur Textgenerierung: Es arbeitet mehrstufige Aufgaben ab, bedient sich Werkzeugen und tritt mit Anwendungen in den Dialog. Im Frontend äußert sich das etwa darin, dass ein LLM nicht nur Antworten formuliert, sondern mit Stores, Routing-Systemen und Formularen zusammenspielt.
Die Anwendung bleibt dennoch klassisch nutzbar: Unsere Demoversion ist in vollem Umfang ohne KI-Integration nutzbar. Erst wenn Nutzer nicht weiterwissen oder Abläufe verkürzen wollen, rufen sie ein sogenanntes Sidecar auf und sprechen über einen serverseitigen Agent mit einem LLM:
Um Fragen zu beantworten, hat das LLM Zugriff auf Werkzeuge, die vom Sidecar bereitgestellt werden. Auf der Serverseite können diese beispielsweise auf Datenbanken zugreifen, während sie sich im Frontend um Belange wie Stores, Formulare und Routing kümmern.
Darüber hinaus hat das LLM die Möglichkeit, Komponenten aus einem Katalog zu wählen, die dann vom Sidecar gerendert werden. Die Daten für diese Komponenten stammen vom Sprachmodell und den Tools und werden vom Sidecar übergeben.
Im dargestellten Szenario kommen zwei Hilfsmittel zum Einsatz: getBookedFlights fungiert als serverseitiges Werkzeug, das die Flüge des angemeldeten Benutzers abruft. Im Gegensatz dazu initiiert findFlights eine Flugsuche im Client, indem es zur Route mit dem Suchformular navigiert, dieses ausfüllt und die Suche auslöst.
Für mehr Transparenz ist es empfehlenswert, den Nutzer über ausgeführte Aktionen wie Tool Calls zu unterrichten. Das gezeigte Beispiel handelt dies sehr deutlich ab, indem es die internen Werkzeugnamen ausgibt. In einer professionellen Anwendung würde man eine weniger technische Sprache wählen. Anstelle von Tool Call: getBookedFlights könnte das Sidecar etwa Ermittle gebuchte Flüge ... im Chatverlauf festhalten.
Zusätzlich zu den Tool Calls enthält der Chat textuelle Antworten sowie eine vom LLM ausgewählte Flugkarte. Das Sidecar reicht dieser Karte den anzuzeigenden Flug weiter. Hierfür greift die Angular-Anwendung per HTTP auf den Agenten zu, der wiederum auf ein oder mehrere LLMs zurückgreifen kann:
Ein Agent Client übernimmt die Feinheiten dieser Kommunikation und informiert den Agenten über die verfügbaren clientseitigen Werkzeuge und Komponenten. Auf der Serverseite verfügt der Agent zusätzlich über eine eigene Liste von Tools.
Leitet der Agent die Benutzeranfrage an das LLM weiter, fügt er die gesammelten Informationen zu serverseitigen Tools, clientseitigen Tools und Komponenten bei. Das LLM bewertet daraufhin, welche Daten es noch benötigt, und verlangt Tool Calls. Serverseitige Tool Calls führt der Agent selbst aus, während er die clientseitigen an den Agent Client weitergibt. Die erzielten Ergebnisse schickt er ans LLM zurück, das damit seine Aufgabe weiterbearbeitet.
Für die finale Antwort liefert das LLM Freitext. Zudem kann es ein JSON-Dokument mitgeben, das festlegt, welche Komponenten im Sidecar erscheinen sollen. Dieses JSON enthält auch die Werte für die Inputs dieser Komponenten. Je nach Fähigkeiten des LLMs ist dieses Dokument eine strukturierte Antwort oder besteht aus Parametern, die ein clientseitiges Tool erhält.
Structured Output stellt semantisch die sauberere Variante dar. Allerdings bieten manche Modelle keine gleichzeitige Unterstützung von Tool Calling und Structured Output. Viele LLMs erlauben zudem eine formale Parameterbeschreibung für Tool Calls per JSON Schema. Aus diesem Grund erweist sich die Tool-Calling-Methode zur Komponentendarstellung häufig als pragmatischste Wahl.
Daraus ergibt sich die Frage nach einer Kommunikationsform mit dem Agenten, die keine starke Kopplung an den Client verursacht. Genau hier setzt der AG-UI-Standard an.
Was genau ist AG-UI?
Um unabhängig von der gewählten Servertechnologie zu bleiben und ein Vendor-Lock-in bei LLM-Anbietern zu verhindern, legt der Standard AG-UI die Nachrichtenformate für den Austausch zwischen Client und Agent fest. Entwickelt wurde der Standard von den Machern von CopilotKit, einem komfortablen Frontend-SDK für KI-gestützte Assistenten und Sidecars. Inzwischen gibt es Adapter für nahezu alle bekannten Agent-Frameworks.
Zum Zeitpunkt der Erstellung dieses Artikels führt die AG-UI-Website die folgenden unterstützten Frameworks auf:
- 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 die ausgetauschten Nachrichten zwischen Client und Agent. Diese beschreiben etwa die Übermittlung von Text oder Tool Calls samt ihren Ergebnissen. Nachfolgende Nachrichten können Details aus vorherigen präzisieren – die Basis für das Streaming von Texten und Tool-Call-Parametern.
AG-UI ist bewusst transportagnostisch ausgelegt: Es trifft keine Annahmen über das darunterliegende Protokoll. Üblich sind HTTP mit Server-sent Events (SSE) oder WebSockets.
Agentic UI with Angular
Wenn du AG-UI nicht nur integrieren, sondern sauber in größere Architekturen einbetten willst:
In meinem Buch Agentic UI mit Angular gehe ich genau auf diese Patterns und Trade-offs im Detail ein.
Nachrichtentypen in AG-UI
Innerhalb des Nachrichtenstroms zwischen Agent und Client definiert AG-UI spezifische Typen, die in unterschiedliche Klassen fallen. In der folgenden Tabelle sind diejenigen Nachrichtentypen aufgeführt, die im weiteren Verlauf dieses Textes zur Anwendung kommen:
| Kategorie | Nachrichtentyp | Beschreibung |
|---|---|---|
| Lifecycle | RUN_STARTED |
Startet einen Run, der sämtliche Nachrichten zur Beantwortung einer Frage enthält. |
RUN_FINISHED |
Schließt einen Run ab | |
RUN_ERROR |
Meldet einen Fehler für einen Run | |
| Text | TEXT_MESSAGE_START |
Startet mit der Übertragung einer Textnachricht |
TEXT_MESSAGE_CONTENT |
Liefert weitere Teile der Textnachricht | |
TEXT_MESSAGE_END |
Beendet eine Textnachricht | |
| Tool Call | TOOL_CALL_START |
Startet einen Tool Call |
TOOL_CALL_ARGS |
Liefert weitere Parameter für den Tool Call | |
TOOL_CALL_END |
Beendet den Tool Call | |
TOOL_CALL_RESULT |
Liefert das Ergebnis eines Tool Calls |
Ein Run bezeichnet die einmalige Ausführung eines Agents oder Modells, angestoßen durch eine Eingabe, die innerhalb eines festgelegten Kontexts einen Stream oder ein Ergebnis hervorbringt. Aus jedem Run gehen Nachrichten hervor, die Tool-Aufrufe, deren Resultate und textuelle Antworten umfassen. In der Regel existiert ein Run je Nutzeranfrage; ein Agent kann eine Anfrage aber auch in mehrere Runs aufteilen, etwa um sie an verschiedene spezialisierte Modelle weiterzuleiten.
Für Streaming-Zwecke gestattet AG-UI, den Großteil der Informationen über mehrere Nachrichten zu verteilen. Hierzu zählen unter anderem die Nachrichtentypen TEXT_MESSAGE_CONTENT und TOOL_CALL_ARGS. Über mehrere Nachrichten dieser Art lassen sich schrittweise Text oder zusätzliche Argumente eines Tool Calls übermitteln.
Die nachfolgenden Nachrichten repräsentieren den ersten Run aus der eingangs dargestellten Beispielanwendung und zeigen, wie AG-UI eingesetzt wird:
{"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 repräsentieren Tool Calls für das serverseitige Tool getBookedFlights, das clientseitige Tool showComponents sowie eine Textantwort. Zur besseren Übersichtlichkeit wurden die IDs – normalerweise GUIDs – abgekürzt, und das in Strings eingebettete JSON mit Argumenten und Tool-Ergebnissen ist nur angedeutet. Über die IDs lässt sich feststellen, zu welchem früher gestarteten Tool Call die späteren Argumente oder protokollierten Ergebnisse gehören.
Um bereits während der Übertragung erste Inhalte anzuzeigen, unterteilt der Agent seine Antwort in mehrere Textnachrichten. Wie bei den Tool Calls werden auch hier die Nachrichten, die zusammen eine Antwort bilden, mit derselben ID versehen. Die beiden Lifecycle Messages zu Beginn und Ende des Runs enthalten zusätzlich zur runId eine threadId, um alle Runs eines Chatverlaufs zu gruppieren.
Fazit
AG-UI schafft eine übersichtliche Schnittstelle zwischen Frontend und Agent, die Runs, Texte und Tool Calls einheitlich darstellt. So lassen sich Streaming, Tool Calling und UI-Updates standardisiert umsetzen, ohne Bindung an ein bestimmtes Agent-Framework oder einen LLM-Anbieter.
Für agentische Frontends bedeutet dies vor allem technologische Unabhängigkeit vom Backend und weniger Vendor-Lock-in. Als Auftakt der Serie vermittelt der Artikel die fachliche Basis.
Weiter geht's
So viel zur Theorie – im folgenden Teil wird gezeigt, wie Runs, Nachrichten und Tool Calls mithilfe des offiziellen AG-UI SDK sowohl auf dem Server als auch im Browser praktisch umgesetzt werden.
Interesse an produktionsreifen Agentic-UI-Architekturen?
In meinem Workshop beschäftigen wir uns mit AG-UI, A2UI, MCP Apps, HITL-Patterns und modernen Angular-Architekturen für reale agentische Systeme.
FAQ
Was ist Agentic AI?
Bei Agentic AI geht es um Systeme, in denen ein Sprachmodell über die reine Antwortgenerierung hinausgeht: Es plant Schritte, ruft Werkzeuge auf und agiert mit Anwendungen. Im Frontend-Bereich zeigen sich diese Fähigkeiten etwa in Sidecars, Tool Calling oder dem bedarfsgerechten Einblenden von UI-Komponenten.
Was ist AG-UI?
AG-UI stellt einen Standard für den Austausch zwischen Client und Agent dar. Nachrichtentypen für Runs, Textnachrichten und Tool Calls sind festgelegt, wodurch eine transportunabhängige Verbindung für agentische Frontends entsteht.
Wofür braucht man AG-UI im Frontend?
Mit AG-UI lassen sich Frontend, Agent und Modell sauber trennen. Das macht es möglich, Streaming, Tool Calls und UI-Updates einheitlich umzusetzen, ohne dass man sich zu früh auf ein bestimmtes Framework oder einen Anbieter festlegt.
Wie hängen Runs, Nachrichten und Tool Calls zusammen?
Ein Run beschreibt die Ausführung eines Agents oder Modells, die durch eine Eingabe in einem vorgegebenen Kontext angestoßen wird. Die während dieser Ausführung erzeugten Nachrichten umfassen textuelle Inhalte, Tool-Aufrufe, deren Ergebnisse sowie Statusmeldungen wie Start, Abschluss oder Fehler. Meist entsteht ein Run aus einer Benutzeranfrage, doch ein Agent kann eine Anfrage auch zerlegen und mehrere Runs starten, unter anderem um Aufgaben an spezialisierte Modelle weiterzugeben.