Die Schnittstelle ist die Intelligenz: Warum action-first UX dialogorientierter KI in der Incident Response überlegen ist

KI einfach an ein Produkt anzuhängen, ist schwieriger als gedacht

Es ist 2:47 Uhr morgens. Eine P1-Alarmierung wird ausgelöst. Der dienstbereite Techniker öffnet ilert, sieht, dass die KI bereits eine Analyse durchgeführt hat, und erhält drei Remediation-Optionen. Aber wie geht es dann weiter? Das hat uns ganz besonders beschäftigt.

‍

Die meisten KI-Tools präsentieren dem Techniker in diesem Moment eine nummerierte Liste in einem Chatfenster und warten. Der Techniker liest, trifft seine Auswahl, tippt eine Antwort ein, und der Agent setzt die Arbeit fort. Das alles dauert – wenn Eile geboten ist - nur einige Sekunden, führt aber genau im falschen Moment zu Unklarheiten, erneutem Lesen und kognitiver Belastung.

‍

Wir entwickelten einen SRE-Agenten, d.h. einen direkt in unsere Incident Response-Plattform integrierten KI-Agenten, der alles übernimmt – von der Root Cause Analysis (RCA) und Triage bis hin zu On-Call-Anfragen und der Objekterstellung. Da wir Agenten zu einem zentralen Bestandteil unserer Lösung gemacht haben, wurden wir immer wieder mit der Frage konfrontiert: Welches ist die richtige Schnittstelle für einen Menschen, der während eines aktiven Incidents eine KI-Entscheidung genehmigen soll?

‍

Chat ist die naheliegende Lösung. Aber es ist nicht immer die richtige.

‍

Läuft der Agent als Sidecar? Als Overlay? Gibt es einen speziellen Ort, um mit ihm zu kommunizieren? Ist der Chat die einzige Schnittstelle?

‍

Für Chat spricht vor allem eines: Der Agent kann überall dort sein, wo der Nutzer ist: Slack, WhatsApp, Teams. Wann immer er Input benötigt, erreicht er den Menschen über seinen bevorzugten Kanal.

‍

Aber der Chat hat auch Nachteile: Oft ist der Eingabeaufwand immer noch zu hoch. Nutzer wissen nicht immer, was sie eingeben sollen oder wo sie anfangen sollen. Und wenn man die Interaktion in einen Chat-Kanal verlagert, ist man auf das beschränkt, was dieser Kanal unterstützt: in der Regel nur Text.

Unsere Herangehensweise ist:

‍

Die beste agentengestützte UX fühlt sich nicht wie ein Chatbot an, sondern vielmehr so, als wäre das Produkt intelligenter geworden. ActionOption Cards sind die Realisierung dieses Ansatzes, und sie beginnen damit, ein ganz bestimmtes Problem zu lösen.

Das Problem mit textbasierten Optionslisten

Zurück zu 2:47 Uhr morgens. Die KI hat den schwierigen Teil bereits erledigt: Sie hat Meldungen aus Datadog und GitHub miteinander verknüpft, ein fehlerhaftes Deployment identifiziert und die Remediation-Optionen auf drei eingegrenzt. Diese Arbeit ist wichtig. Was als Nächstes passiert, kann sie zunichte machen.

‍

Die meisten KI-Tools präsentieren dem Engineer eine nummerierte Liste in einem Chat-Fenster und warten. Das zwingt ihn dazu, zu lesen, sich für eine Option zu entscheiden und eine Bestätigung einzutippen – ein Reibungspunkt genau im falschen Moment und Quelle von Unklarheiten, die der Agent dann klären muss. Das Muster sieht so aus:

‍

Goal: Implement JWT middleware for the HTTP service.

1. Deployment des Zahlungsgateways hochskalieren
2. Betroffene Pods neu starten
3. Rollback auf die vorherige Version

‍

Dies zwingt den Nutzer, die Option zu lesen, sie gedanklich auszuwählen und eine Folge-Nachricht einzugeben, um seine Absicht zu bestätigen. Das ist unnötiger Aufwand genau im falschen Moment. Es führt auch zu Unklarheiten: Meinte der Nutzer genau Option 1 oder eine Variante davon?

‍

Die Schnittstelle sollte entscheidungsorientiert sein, nicht nur dialogorientiert. Während eines aktiven Incidents arbeiten Engineers unter kognitiver Belastung. Jede Sekunde, die mit erneuten Lesen, Analysieren oder Eintippen verbracht wird, ist eine Sekunde, in der der Incident andauert.

Was sind A2UI (Agent-to-User Interface) ActionOption-Cards?

Wir nutzen das A2UI-Framework, um interaktive UI-Elemente dynamisch innerhalb des Agenten-Konversations-Threads darzustellen – Komponenten, die der Agent spontan generiert, keine statischen Bildschirme. Eine ActionOption-Card ist die primäre Ausdrucksform: Sie ist das, was der Agent anstelle einer nummerierten Textliste anzeigt, wann immer eine Aktion durch den Nutzer erforderlich ist.

‍

Jede Card steht für eine einzelne, eigenständige Handlungsoption und besteht aus:

• Titel: Eine kurze, eindeutige Bezeichnung für die Aktion, z. B. „Option 1: Zahlungsgateway skalieren“.
• Beschreibung: Eine Erläuterung der Funktion der Aktion und der damit verbundenen Vor- und Nachteile, damit Engineers auf einen Blick eine fundierte Entscheidung treffen können.
• Tag-Badge (optional): Eine farbcodierte Kennzeichnung: Empfohlen (grün), Sofort (gelb), Schnell (blau) oder Am besten (grün). Wird nur angezeigt, wenn sie eine Option sinnvoll unterscheidet.
• Aktionsschaltfläche: Eine anklickbare Schaltfläche mit einem kurzen Aktionsverb und einem optionalen Symbol. Ein Klick genügt, um fortzufahren.

Ein einfaches Beispiel: Der Agent schlägt drei Optionen vor. Anstatt „1“, „2“ oder „3“ einzugeben, klicken Sie auf eine Schaltfläche. Dieses Muster lässt sich auf komplexere Szenarien übertragen: Auswahlmenüs, Schieberegler, umfangreiche Tabellen.

‍

Technische Architektur: So werden Cards generiert und dargestellt

Diese drei Dinge sorgen dafür, dass es funktioniert: das LLM, einige wenige Tools und das Frontend.

Schritt 1: Tool-Call

Wir haben ein spezielles Tool entwickelt, das der Agent aufrufen kann, wenn er entscheidet, dass strukturierte Optionen sinnvoller sind als eine einfache Textantwort. Das LLM übergibt eine Liste von Optionsobjekten (je eines pro Card):

‍

{
  "options": [
	{
  	"title": "Scale up payment-gateway",
  	"description": "Increase replica count from 3 to 6 to absorb current traffic spike. No downtime expected.",
  	"tag": "Recommended",
  	"risk": "low",
  	"effort": "~2 min",
  	"actionLabel": "Scale up"
	},
	{
  	"title": "Option 2: Roll back to v2.4.1",
  	"description": "Revert the deployment to the last stable version. Resolves regression but requires redeployment.",
  	"tag": "Immediate",
  	"risk": "medium",
  	"effort": "~10 min",
  	"actionLabel": "Roll back"
	}
  ]
}

‍Schritt 2: Rendering

Für jede Option wird eine eindeutige Kennung generiert. Anschließend wird ein A2UI-Befehl zur Aktualisierung der Nutzeroberfläche an den Backend-Message-Bus gesendet. Das Frontend abonniert diese Ereignisse und rendert die Cards in Echtzeit innerhalb des Konversations-Threads, sobald sie eintreffen – ohne Page Reload und manuelles Polling.

Schritt 3: Nutzerinteraktion und Intent-Injection

Wenn der Engineer auf eine Aktionsschaltfläche klickt, wird ein Ereignis mit der eindeutigen Kennung der Option an den Agenten zurückgesendet. Der Agent ordnet dies einem vorkonfigurierten Bestätigungssatz zu, zum Beispiel „Ja, skaliere die Replikate des Zahlungsgateways“, und fügt ihn in den Chat-Thread ein, als hätte der Nutzer ihn selbst eingegeben. Dadurch wird der LLM-Loop nahtlos mit der bestätigten, eindeutigen Absicht des Nutzers fortgesetzt.

Schritt 4: Status nach der Auswahl

Sobald der Engineer klickt, aktualisiert die Card ihren eigenen Status: Die Aktionsschaltfläche wird durch ein grünes Häkchen mit der Beschriftung „Ausgewählt“ ersetzt. Diese visuelle Bestätigung macht deutlich, dass die Aktion bestätigt wurde, und verhindert versehentliche doppelte Übermittlungen.

‍

‍

Warum dieses Muster wichtig ist

Dies ist unsere Antwort auf eine Frage, mit der sich jeder AI-SRE-Anbieter auseinandersetzt: Wie viel sollte der Agent autonom erledigen, und wann gibt er an einen Menschen zurück? Unsere Antwort lautet, dass der Übergabemoment genauso reibungslos sein muss wie die ihm vorausgehende Untersuchung. ActionOption Cards sind für diesen Moment konzipiert. Das bedeutet in der Praxis Folgendes:

• Visuell leicht erfassbar: Die Cards sind räumlich voneinander getrennt, optisch klar erkennbar und enthalten strukturierte Metadaten. Ein Techniker kann drei Optionen auf einen Blick bewerten, anstatt einen ganzen Textabschnitt lesen zu müssen.
• Eindeutige Signalisierung von Risiken und Aufwand: Anstatt die Risikobewertung der Intuition zu überlassen, zeigt der Agent direkt neben jeder Option Daten zu Risiken und Aufwand an – Informationen, die aus Runbooks, historischen Incidentdaten oder seiner eigenen Analyse stammen.
• Eindeutige Absicht: Ein angeklickter Button ist einer exakten, maschinenlesbaren Aktion zugeordnet. Es gibt keine Mehrdeutigkeit in der natürlichen Sprache zwischen „skalieren“ und „die Replikate erhöhen“. Das Identifier-to-Sentence-Mapping stellt sicher, dass das LLM genau das erfährt, was der Engineer bestätigt hat.
• Fortsetzbarer Agenten-Loop: Da der eingefügte Bestätigungssatz wie jede andere Nachricht wieder in den Chat-Thread eingefügt wird, wird der LLM-Loop ohne Special Case-Handling fortgesetzt. Der Agent setzt seinen Workflow fort, als hätte der Engineer die Antwort ganz normal eingetippt.

‍

Governance auf Klick

Viele AI-SRE-Produkte sprechen von „Human-in-the-Loop“ als Sicherheitskonzept. ActionOption Cards machen dies zur gelebten Realität von UX. Der Engineer genehmigt eine Aktion nicht, indem er „Ja“ in ein Chatfeld eingibt, sondern er klickt auf eine Schaltfläche, die das Risiko, den Aufwand und den Kompromiss auf einen Blick anzeigt. Die Genehmigung erfolgt fundiert und schnell.

‍

Das ist der Unterschied zwischen einem KI-Agenten, der auf ein Produkt aufgesetzt wird, und einem, der in dieses integriert ist. Der Agent erlangt schrittweise Autonomie, und bei jedem Schritt ist der Moment der menschlichen Genehmigung so gestaltet, dass er ebenso klar und schnell ist wie die ihm vorausgehende KI-Untersuchung.

‍

Zurück zu 2:47 Uhr. Die KI hat recherchiert. Drei Optionen werden angezeigt. Ein Klick.

‍