KI in eine Anwendung zu integrieren, heißt heute oft: Man setzt ein Chatfenster daneben. Nutzer:innen formulieren eine Frage, das Large Language Model antwortet mit Text. Doch sobald KI nicht mehr nur Informationen liefern, sondern tatsächlich Aufgaben übernehmen soll, stößt dieses Muster an seine Grenzen. Was passiert, wenn ein Agent Daten analysiert, einen Workflow anstößt, ein Dashboard zusammenstellt oder mehrere Schritte selbstständig ausführt? Muss der Nutzer dann wirklich jede Interaktion über einen Chat verfolgen?
Michael Dowden spricht im Podcast mit Manfred Steyer, Google Developer Expert, Angular-Experte und langjähriger Trainer der JavaScript & Angular Days. Im Mittelpunkt steht die Frage, wie sich KI-Agenten sinnvoll in moderne Anwendungen integrieren lassen – jenseits endloser Textdialoge und ohne dabei Kontrolle, Sicherheit oder eine saubere Architektur aufzugeben.
Hinweis: Dieses Video wurden mithilfe von KI erstellt auf Grundlage der ursprünglichen Inhalten sowie den technischen Erkenntnissen des Autors des Blogartikels.
Der Chatbot ist nicht das Ziel
Die aktuelle KI-Welle hat Chat zu einem beinahe universellen Interface gemacht. Doch für Manfred Steyer greift die Frage, ob eine Anwendung einen Chat braucht oder nicht, zu kurz. Denn entscheidend ist nicht die Eingabeform. Entscheidend ist die Absicht des Nutzers. Ein Agent bekommt ein Ziel, plant Schritte, nutzt Tools und passt sein Vorgehen abhängig von den Ergebnissen an. Das unterscheidet agentische Systeme von klassischen KI-Assistenten, die in erster Linie auf eine einzelne Anfrage reagieren. Für die Benutzeroberfläche eröffnet das neue Möglichkeiten.
Statt auf eine Anfrage mit einer langen Textantwort zu reagieren, kann ein Agent beispielsweise:
- ein passendes Dashboard zusammenstellen,
- relevante Daten direkt visualisieren,
- interaktive Komponenten anzeigen,
- einen bestehenden Workflow vorbereiten,
- oder gemeinsam mit dem Nutzer Schritt für Schritt ein Ergebnis entwickeln.
Die Oberfläche wird damit nicht abgeschafft. Im Gegenteil: Sie bekommt eine wichtigere Rolle. Der Agent muss nicht jedes Ergebnis erklären. Er kann die passende Oberfläche für die jeweilige Aufgabe bereitstellen.
Von der Textantwort zum dynamischen Interface
Genau darin liegt ein wesentlicher Unterschied zwischen klassischen Chatbots und Agentic UI. Wenn ein Nutzer Daten vergleichen möchte, ist eine Tabelle oft hilfreicher als fünf Absätze Text. Soll er Parameter verändern, sind Eingabefelder, Slider oder Auswahlmöglichkeiten effizienter. Und wenn mehrere Kennzahlen zusammengehören, kann ein dynamisch erzeugtes Dashboard deutlich mehr Orientierung bieten als eine rein sprachliche Antwort. Die KI entscheidet in solchen Szenarien nicht nur, was sie zurückgibt, sondern teilweise auch, wie das Ergebnis präsentiert werden sollte. Damit entsteht eine Form von Generative beziehungsweise Adaptive UI: Die Oberfläche kann sich zur Laufzeit an den aktuellen Kontext und die Absicht des Nutzers anpassen. Für Entwickler bringt das allerdings eine neue Herausforderung mit sich. Sobald Backend-Agent und Frontend eng miteinander verzahnt werden, entsteht schnell eine Architektur, in der das UI von einer bestimmten Agentenimplementierung, einem Framework oder sogar einem konkreten LLM-Anbieter abhängig ist. Genau dieses Problem adressieren offene Standards wie AG-UI und A2UI.
AG-UI: Eine gemeinsame Sprache zwischen Agent und Frontend
AG-UI definiert eine standardisierte Kommunikation zwischen einem Agenten und dem Frontend.
Der entscheidende Punkt ist die Entkopplung.
Das Frontend sollte nicht wissen müssen, ob im Hintergrund ein bestimmtes Agent Framework, ein bestimmtes Backend oder ein bestimmtes Large Language Model arbeitet. Stattdessen kommunizieren Agent und Anwendung über definierte Nachrichten und Ereignisse miteinander.
Dazu gehören beispielsweise:
- der Start und das Ende eines Agenten-Laufs,
- gestreamte Textinformationen,
- Tool Calls,
- Zustandsänderungen,
- Ergebnisse von Aktionen,
- und Ereignisse, auf die das Frontend reagieren kann.
Dadurch lässt sich die technische Implementierung hinter dem Agenten austauschen, ohne gleichzeitig die gesamte Benutzeroberfläche neu entwickeln zu müssen. Gerade bei Enterprise-Anwendungen ist diese Trennung relevant. KI-Technologien verändern sich aktuell schnell. Eine Architektur, die das Frontend direkt an den heutigen Anbieter oder Agent Stack koppelt, kann deshalb schon kurze Zeit später zum Problem werden. AG-UI schafft hier eine stabile Grenze zwischen beiden Welten.
A2UI: Wenn der Agent selbst UI-Strukturen anfordert
AG-UI löst die Kommunikation zwischen Agent und Anwendung. Doch eine weitere Frage bleibt: Wie kann ein Agent dynamisch bestimmen, welche Oberfläche der Nutzer sehen soll?
Hier kommt A2UI ins Spiel. Anstatt dass ein Sprachmodell beliebigen HTML- oder JavaScript-Code erzeugt, kann es eine strukturierte Beschreibung der benötigten Benutzeroberfläche liefern. Das Frontend setzt diese anschließend mit bekannten Komponenten um. Der Agent könnte beispielsweise erkennen, dass für eine bestimmte Anfrage nicht nur eine Textantwort, sondern ein Dashboard benötigt wird. Er beschreibt daraufhin dessen Struktur und Daten. Das Frontend rendert daraus die entsprechenden Komponenten. Für Entwickler ist dieser Unterschied entscheidend. Die KI bekommt Flexibilität, aber nicht völlige Freiheit. Welche Komponenten zur Verfügung stehen und wie sie sich verhalten, bleibt unter Kontrolle der Anwendung. Das Sprachmodell entscheidet innerhalb eines vorgegebenen Rahmens, welche davon für die aktuelle Aufgabe sinnvoll sind. So verbindet A2UI zwei zunächst widersprüchlich wirkende Anforderungen: dynamische Interfaces und kontrollierbare Softwarearchitektur.
Autonomie braucht Grenzen
Doch je mehr ein Agent kann, desto wichtiger wird die nächste Frage:
Wie viel darf er selbstständig tun?
Eine KI, die nur Text generiert, hat relativ begrenzte Auswirkungen. Ein Agent dagegen kann Tools aufrufen, Daten verändern und Prozesse anstoßen. Seine Entscheidungen können also reale Konsequenzen haben. Das macht klassische Guardrails allein nicht ausreichend. Im Gespräch geht es deshalb um einen stärker technischen Ansatz: Statt sich darauf zu verlassen, dass ein probabilistisches Modell immer die richtige Entscheidung trifft, sollten Entwickler deterministische Grenzen um das nichtdeterministische System bauen. Der Agent darf innerhalb dieses Rahmens flexibel handeln. Die Anwendung definiert jedoch, welche Aktionen überhaupt möglich sind und welche Bedingungen dabei gelten. Die Architektur selbst wird damit zum Sicherheitsmechanismus. Ein Agent bekommt nicht einfach unbegrenzten Zugriff auf das System. Er erhält definierte Werkzeuge und Möglichkeiten, mit denen er sein Ziel verfolgen kann.
Kontrolle bedeutet nicht, vor jedem Schritt „Bist du sicher?“ zu fragen
Bei Human-in-the-Loop wird häufig an Bestätigungsdialoge gedacht. Der Agent möchte etwas tun. Die Anwendung fragt: „Bist du sicher?“ Der Nutzer bestätigt. Doch bei längeren agentischen Prozessen wäre dieses Prinzip schnell störend. Wenn ein Nutzer jede einzelne Zwischenentscheidung bestätigen muss, verschwindet genau der Vorteil, den autonome Agenten bieten sollen. Manfred Steyer beschreibt deshalb differenziertere Muster. Ein Beispiel sind Action Cards. Sie zeigen dem Nutzer, was der Agent gerade getan hat oder tut, ohne den Prozess bei jedem Schritt vollständig anzuhalten. Statt jede Aktion vorher bestätigen zu lassen, kann die Oberfläche beispielsweise eine Möglichkeit zum Undo anbieten. Und wenn der Agent erkennbar in die falsche Richtung läuft? Dann braucht der Nutzer eine einfache Möglichkeit, den Prozess vollständig zu stoppen – im Zweifel über einen deutlich sichtbaren Stop-Button. Das verschiebt Human-in-the-Loop von permanenter Genehmigung hin zu Transparenz, Eingriffsmöglichkeiten und Recovery.
Warum ein Agent nicht 30 Minuten schweigen sollte
Wie wichtig diese Transparenz ist, verdeutlicht Steyer im Gespräch mit einem ungewöhnlichen Vergleich. Man stelle sich vor, ein Zahnarzt arbeitet zwanzig Minuten im eigenen Mund, ohne ein einziges Wort darüber zu verlieren, was er gerade macht. Selbst wenn am Ende alles richtig durchgeführt wurde, wäre die Situation unangenehm. Bei KI-Agenten entsteht ein ähnliches Problem. Ein Agent kann längere Zeit an einer komplexen Aufgabe arbeiten, Tools aufrufen und Entscheidungen treffen. Wenn die Benutzeroberfläche währenddessen lediglich einen Spinner zeigt, weiß der Nutzer nicht:
- Was passiert gerade?
- Ist der Agent noch auf dem richtigen Weg?
- Hat er bereits etwas verändert?
- Kann ich eingreifen?
Damit wird Feedback zu einer UX-Anforderung für agentische Systeme. Die Anwendung muss nicht jede interne Überlegung eines Modells offenlegen. Sie sollte aber sichtbar machen, welche relevanten Aktionen stattfinden und welchen Stand ein Prozess erreicht hat. Agentic UI ist deshalb nicht nur eine technische Integrationsfrage. Es ist ebenso eine Frage von User Experience und Vertrauen.
Feedback-Loops statt Blackbox
Agentische Anwendungen unterscheiden sich auch deshalb von klassischer Software, weil ihr Verhalten nicht vollständig vorherbestimmt ist. Ein klassischer Programmablauf ist weitgehend deterministisch: Bestimmte Eingaben und Zustände führen zu erwartbaren Ergebnissen. Ein LLM arbeitet dagegen probabilistisch. Das bedeutet aber nicht, dass die gesamte Anwendung probabilistisch werden muss. Im Gegenteil: Die Aufgabe der Softwarearchitektur besteht darin, um diese Unsicherheit herum verlässliche Strukturen aufzubauen. Dazu gehören Feedback-Loops. Der Agent führt einen Schritt aus. Das System liefert ein Ergebnis zurück. Der Agent bewertet den neuen Zustand und entscheidet über den nächsten Schritt. Gleichzeitig können Anwendung und Nutzer kontrollieren, ob sich der Prozess weiterhin innerhalb der erlaubten Grenzen bewegt. Dadurch entsteht keine einmalige Anfrage-Antwort-Beziehung mehr, sondern ein iterativer Kreislauf zwischen Ziel, Aktion, Ergebnis und Anpassung.
Testen, was tatsächlich beim Nutzer ankommt
Diese neue Art von Anwendung verändert auch das Testing.
Bei klassischer Software lassen sich viele Abläufe mit vorhersehbaren Eingaben und erwarteten Outputs prüfen. Bei einem LLM ist es dagegen wenig sinnvoll, auf exakt denselben generierten Text zu testen.
Entscheidend ist vielmehr, ob sich die Anwendung korrekt verhält.
Kann der Agent die benötigte Funktion erreichen?
Wird die richtige UI-Komponente dargestellt?
Funktioniert die Interaktion anschließend für den Nutzer?
Bleibt das System innerhalb der definierten Grenzen?
Manfred Steyer setzt deshalb unter anderem auf Blackbox Testing auf Komponentenebene. Statt interne Implementierungsdetails oder exakte Modellantworten festzuschreiben, wird geprüft, welches beobachtbare Verhalten tatsächlich entsteht. Für Angular-Anwendungen ist dabei auch Vitest relevant. Damit verschiebt sich der Fokus: Nicht die konkrete Antwort des Modells muss deterministisch sein – die Rahmenbedingungen und überprüfbaren Ergebnisse der Anwendung müssen es sein.
Agentic UI verändert die Rolle des Frontends
All das zeigt: Agentic AI ist nicht ausschließlich ein Backend-Thema. Sobald Agenten mit Nutzern zusammenarbeiten, wird das Frontend zum zentralen Bestandteil des agentischen Systems. Es muss Zustände sichtbar machen, dynamische Komponenten darstellen, Tool-Ergebnisse präsentieren, Eingriffe ermöglichen und Feedback an den Agenten zurückgeben. Gleichzeitig braucht es klare Grenzen. Das Frontend darf nicht vollständig davon abhängig werden, wie der aktuelle Agent im Backend implementiert ist. Standards wie AG-UI schaffen deshalb die Kommunikationsschicht, während Ansätze wie A2UI die dynamische Darstellung von Interfaces strukturieren. Das Ergebnis ist keine Anwendung, in der KI das UI ersetzt. Es ist eine Anwendung, in der Agent, klassische Softwarelogik und Benutzeroberfläche jeweils das tun, was sie am besten können.
Bleib informiert
Brancheninsights im Newsletter erhalten:
Das Ziel ist nicht mehr KI im Interface – sondern ein besseres Interface
Genau hier schließt sich der Kreis zur Produktfrage. Unternehmen wie Airbnb experimentieren bereits damit, KI nicht nur als internes Produktivitätswerkzeug, sondern als Bestandteil des eigentlichen Produkterlebnisses zu verstehen. Airbnb-CEO Brian Chesky hat dabei ebenfalls deutlich gemacht, dass Chat nicht automatisch die richtige Oberfläche für jede Aufgabe ist. Agentic UI liefert eine technische Perspektive auf genau dieses Problem. Wenn KI wirklich Bestandteil einer Anwendung werden soll, reicht es nicht, ein Sprachmodell hinter ein Texteingabefeld zu setzen.
Entwickler müssen entscheiden:
- Wo hilft natürliche Sprache?
- Wo braucht der Nutzer eine strukturierte Oberfläche?
- Welche Entscheidungen darf der Agent treffen?
- Wann muss der Mensch eingreifen können?
- Wie bleiben Frontend und Backend voneinander entkoppelt?
- Und wie lässt sich ein nichtdeterministisches System trotzdem verlässlich betreiben?
Die interessanteste Entwicklung bei AI-native Software ist deshalb vielleicht nicht der nächste Chatbot. Sie beginnt dort, wo der Chat aufhört.
Agentic UI bedeutet, KI nicht einfach in eine bestehende Oberfläche einzubauen, sondern neu darüber nachzudenken, wie Menschen und Software gemeinsam Aufgaben lösen.
Wer mit Manfred Steyer tiefer in moderne Angular-, KI- und Anwendungsarchitekturen einsteigen möchte, kann seine Themen bei den JavaScript & Angular Days in praxisnahen Workshops weiter vertiefen.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was ist Agentic UI?
Agentic UI bezeichnet Benutzeroberflächen, die mit KI-Agenten zusammenarbeiten und sich an das Ziel, den Kontext und den aktuellen Prozessschritt eines Nutzers anpassen können. Statt ausschließlich feste Abläufe darzustellen, können sie dynamisch relevante Informationen, Aktionen und UI-Komponenten bereitstellen.
2. Was kann eine agentische Benutzeroberfläche?
Eine agentische Benutzeroberfläche kann Nutzeranfragen interpretieren, passende Funktionen auswählen, Informationen aus verschiedenen Quellen zusammenführen und den nächsten Prozessschritt vorbereiten. Sie kann beispielsweise ein Formular, eine Tabelle oder eine Auswahl anzeigen, sobald diese für das aktuelle Ziel benötigt wird.
3. Was ist der Unterschied zwischen Agentic UI und einem Chatbot?
Ein Chatbot verwendet hauptsächlich einen textbasierten Dialog. Agentic UI kann Sprache mit klassischen UI-Elementen wie Buttons, Formularen, Karten und Tabellen kombinieren. Die Oberfläche passt sich dabei dynamisch an die aktuelle Aufgabe an, anstatt jede Interaktion ausschließlich über Chat abzuwickeln.
4. Was wird mit Agentic UI gemacht?
Agentic UI wird eingesetzt, um komplexe Prozesse zu vereinfachen und Nutzern kontextabhängige Unterstützung zu bieten. KI-Agenten können Aufgaben vorbereiten, Informationen suchen, Optionen vergleichen oder passende nächste Schritte vorschlagen. Kritische Aktionen können weiterhin eine Bestätigung durch den Nutzer erfordern.
5. Wer nutzt Agentic UI?
Agentic UI ist vor allem für Unternehmen und Entwickler interessant, die KI-Agenten in Webanwendungen, Unternehmenssoftware, Kundenportale oder digitale Produkte integrieren. Besonders relevant ist der Ansatz für Anwendungen mit komplexen Abläufen, vielen Datenquellen oder unterschiedlichen Nutzerzielen.
6. Wie werden KI-Agenten in eine Benutzeroberfläche integriert?
KI-Agenten werden über definierte Schnittstellen, Werkzeuge und strukturierte Datenformate mit der Anwendung verbunden. Der Agent kann eine Aktion oder UI-Komponente anfordern, während die Anwendung Berechtigungen und Regeln prüft. Das Frontend stellt anschließend eine bekannte und freigegebene Komponente dar.
7. Warum sind Feedback-Loops bei Agentic UI wichtig?
Feedback-Loops helfen dem Agenten zu erkennen, ob eine Aktion erfolgreich war oder korrigiert werden muss. Das Feedback kann vom Nutzer, von der Anwendung oder von einem aufgerufenen Tool stammen. Dadurch werden agentische Prozesse kontrollierbarer, transparenter und verlässlicher.





