5 heimliche Ausfälle in KI-Agenten: So erkennen Sie stille Fehler in Produktion

KI-Agenten verhalten sich anders als herkömmliche Anwendungen. Während klassische Software meist bei logischen Fehlern oder Ausnahmen versagt, liegen die größten Risiken in den unsichtbaren Schnittstellen: Zeitlimits, Tool-Aufrufe oder Routing-Entscheidungen. Diese Fehler manifestieren sich selten als offensichtliche Ausnahmen, weshalb Überwachungstools oft einen grünen Status anzeigen – obwohl Nutzer:innen längst keine Rückmeldung mehr erhalten.

Routinen, die „erfolgreich“ ausführen, aber nichts liefern

Cron-Jobs oder geplante Agenten-Aufgaben melden ihren Status oft nur basierend auf der eigenen Ausführung – nicht auf der tatsächlichen Nutzer:innen-Benachrichtigung. Eine typische Konstellation: Der Agent führt alle geplanten Aktionen aus, etwa das Erstellen eines Tickets oder das Aktualisieren einer Tabelle, scheitert aber knapp vor der Benachrichtigung (z. B. per Slack) an einem Zeitlimit. Das System protokolliert den Job als „erledigt“, obwohl die Nutzer:innen keine Rückmeldung erhielten.

Um solche Fälle sichtbar zu machen, haben wir eine dreistufige Statuslogik eingeführt („delivered“ | „not-delivered“ | „not-requested“). Zudem leiten wir kritische Fehler wie Zeitüberschreitungen direkt an Überwachungstools wie Sentry weiter – inklusive Job-ID, Run-ID und Fehlerzähler. Der eigentliche Hebel liegt jedoch in der Sequenzierung der Arbeitsschritte: Benutzer:innen-relevante Benachrichtigungen müssen vor Aufräumaktionen erfolgen, um Priorität im Zeitbudget zu erhalten.

Tool-Aufrufe mit 4xx-Fehlern, die niemand bemerkt

Ein häufiger Fallstrick: Ein Tool-Adapter gibt bei einem Fehler (z. B. 4xx-Antwort) eine leere Zeichenkette oder eine vage Meldung wie „Vorgang konnte nicht abgeschlossen werden“ zurück. Der KI-Agent interpretiert dies als gültige „No-Op“-Antwort und setzt die Ausführung fort. Die Logs zeigen zwar den Tool-Aufruf, nicht aber den tatsächlichen Fehlschlag – die Ausführung erscheint als erfolgreich.

Die Lösung: Fehler müssen im Runtime-Layer laut werden. Wir haben Muster eingeführt, die Tool-Fehler wie [tools] NAME failed: Grund … automatisch als Ausnahmen an Sentry melden – inklusive Tool-Name als Tag. So lassen sich Fehlerraten pro Tool auf einen Blick erkennen, statt sie in Debug-Logs suchen zu müssen. Zudem haben wir Protokollierungen für stille Abbrüche bei Nachrichtenversand (z. B. durch Rate-Limits) von „verbose“ auf „info“ hochgestuft, um solche Probleme früher zu identifizieren.

Kanäle, die eingehende Nachrichten ohne Rückmeldung unterdrücken

Wenn ein KI-Agent plötzlich keine Direktnachrichten mehr beantwortet, liegt der Fehler meist nicht beim Agenten selbst, sondern beim Inbound-Handler – der Schnittstelle zwischen Plattform (z. B. Slack) und Agent. Dieser entscheidet, welche Nachrichten weitergeleitet und welche verworfen werden. Häufige Gründe für Unterdrückungen:

• Selbst-Erwähnungen des Bots, die keine Schleifen auslösen sollen
• Nachrichtenbearbeitungen, die keine neue Ausführung benötigen
• Threads, für die der Agent nicht konfiguriert ist

Das Problem: Der Handler gibt keine Rückmeldung, wenn er eine Nachricht verwirft. Nutzer:innen warten vergeblich, während die Überwachungstools weiterhin „grün“ anzeigen. Um dies zu ändern, haben wir zwei Maßnahmen umgesetzt:

• Strukturierte Protokollierung: Bisherige „verbose“-Logs für verworfene Nachrichten werden nun als „info“ protokolliert – sie erscheinen also in Standard-Logs, ohne Debug-Modus.
• Kanonische Absagegründe: Jede verworfene Nachricht wird mit einem von 14 vordefinierten Gründen getaggt (z. B. no-mention, channel-not-allowed, dm-not-authorized). Bei einer Beschwerde kann der Support nun direkt die Ursache per Nachrichten-ID nachvollziehen.

„Reasoning Leaks“: Wenn die KI ihre Aktionen nur beschreibt

Ein besonders tückischer Fehler: Der KI-Agent formuliert in einem Slack-Thread eine Nachricht wie **Jetzt wird ausgeführt: message(action=send, channel=#alerts)**, statt den Befehl tatsächlich auszuführen. Für Nutzer:innen sieht es so aus, als hätte der Agent die Arbeit erledigt – tatsächlich wurde jedoch kein side-effecting Tool aufgerufen. Die Überwachungstools zeigen keine Ausnahme an, da der Agent seine „Arbeit“ nur beschrieben hat.

Um solche Fälle zu verhindern, setzen wir auf zwei Ebenen an:

1. Prompt-Design: Der Agent wird angewiesen, routinemäßige Tool-Aufrufe nicht zu beschreiben, sondern direkt auszuführen. Nur bei komplexen oder risikoreichen Aktionen ist eine Beschreibung erlaubt.
2. Delivery-Layer: Vor dem Versand von Nachrichten in Kanäle wie Slack oder Discord werden alle Reasoning-Tags entfernt, sodass selbst interne Erklärungen der KI nicht in der Oberfläche landen.

Ein fehlender Beobachtungsmechanismus bleibt jedoch: Bisher gibt es keine Runtime-Prüfung, die prüft, ob ein Agenten-Turn einen Tool-Call-Syntax enthält – und im Fehlerfall eine Warnung auslöst. Dies ist ein geplanter nächster Schritt für mehr Robustheit.

Zeitfresser Bootstrap: Warum Zeitlimits oft zu knapp bemessen sind

Ein oft unterschätzter Faktor ist die Bootstrap-Phase – etwa das Laden von Modellen, die Auflösung von Berechtigungen oder das Scannen verfügbarer Skills. Diese Zeit wird häufig als „Overhead“ betrachtet, obwohl sie voll auf das Zeitbudget des Agenten angerechnet wird. Ein scheinbar großzügiges Limit von 300 Sekunden schrumpft so schnell auf 225 Sekunden zusammen, bevor die eigentliche Arbeit beginnt.

Im eingangs beschriebenen Fall des Bug-Triage-Jobs verbrauchte die Bootstrap-Phase rund 75 Sekunden – genug, um die finale Benachrichtigung (die immer als letzter Schritt ausgeführt wurde) zu verhindern. Die Lösung: Bootstrap-Aktionen müssen priorisiert und ihre Laufzeit aktiv gemessen werden, um sicherzustellen, dass die verbleibende Zeit für die Nutzer:innen-relevanten Schritte ausreicht. Nur so lässt sich verhindern, dass stille Zeitüberschreitungen zu frustrierten Nutzer:innen führen.

Die stille Natur dieser Fehler macht sie besonders gefährlich. Doch mit der richtigen Instrumentierung, klaren Sequenzierungsregeln und strukturierter Protokollierung lassen sich selbst die unsichtbarsten Ausfälle früh erkennen – und beheben, bevor sie Nutzer:innen betreffen.