Ein AI-Agent braucht vor dem Start eine Antwort auf eine unbequeme Frage: Wann gibt er auf? Ohne klare Stopbedingungen kann ein Agent dieselbe Suche wiederholen, Tools mit leicht veränderten Parametern aufrufen oder zwischen zwei Teilschritten pendeln. Das kostet Geld und kann Zielsysteme belasten.
Ein Kill Switch ist die letzte Sicherung. Gute Systeme stoppen viel früher durch normale Betriebsregeln.
Technische und fachliche Stopbedingungen unterscheiden
Technische Grenzen sind leicht messbar:
- maximale Zahl von Schritten,
- maximale Retries pro Tool,
- Zeitlimit pro Schritt und Workflow,
- Token- oder Kostenbudget,
- Rate Limit pro Zielsystem.
Fachliche Grenzen hängen von der Aufgabe ab. Ein Agent sollte stoppen, wenn verbindliche Quellen widersprüchlich sind, eine notwendige Freigabe fehlt, ein Betrag ausserhalb des erlaubten Bereichs liegt oder die geforderte Belegqualität nicht erreicht wird.
Beide Arten sind nötig. Ein Agent kann technisch fehlerfrei laufen und fachlich trotzdem keinen Fortschritt machen.
Fortschritt explizit definieren
Schrittzähler allein sind grob. Definieren Sie, woran Fortschritt erkennbar ist. Bei Recherche kann das eine neue belastbare Quelle sein. Bei Fehlerbehebung ein neuer Teststatus. Bei Datenerfassung ein validierter Datensatz.
Wenn mehrere Schritte keinen neuen Zustand erzeugen, sollte der Agent stoppen oder eskalieren. Das verhindert Schleifen, die formal unterschiedliche Tool-Aufrufe enthalten, aber inhaltlich nichts verändern.
Retries nach Fehlerklasse steuern
Nicht jeder Fehler darf wiederholt werden. Ein temporäres Netzwerkproblem kann einen Retry rechtfertigen. Eine fehlende Berechtigung, ein Validierungsfehler oder eine abgelehnte Freigabe wird durch Wiederholung nicht besser.
Ordnen Sie Fehler deshalb Klassen zu:
- temporär: begrenzte Wiederholung mit Wartezeit,
- korrigierbar: Parameter einmal anpassen und neu prüfen,
- dauerhaft: sofort stoppen,
- unklar: an einen Menschen eskalieren.
Ein globales "dreimal erneut versuchen" ist für Agenten zu undifferenziert.
Kostenbudget pro Aufgabe statt nur pro Monat
Monatliche Budgets erkennen Probleme spät. Ein einzelner fehlerhafter Agent kann in kurzer Zeit viele Aufrufe erzeugen. Setzen Sie deshalb zusätzlich ein Budget pro Workflow oder Auftrag.
Das Budget kann mehrere Grössen kombinieren: Modellkosten, externe API-Kosten, Rechenzeit und Anzahl teurer Tool-Aktionen. Bei Erreichen der Grenze sollte der Agent seinen Status sichern und mit einer verständlichen Begründung stoppen.
Was ein Kill Switch leisten muss
Ein Kill Switch muss mehr tun als den nächsten Modellaufruf verhindern. Er sollte laufende Jobs abbrechen, neue Tool-Aktionen blockieren, temporäre Berechtigungen entziehen und den aktuellen Zustand für die Untersuchung sichern.
Testen Sie den Mechanismus regelmässig. Eine Schaltfläche im Dashboard ist keine Kontrolle, wenn ein Worker im Hintergrund weiterarbeitet oder bereits geplante Aktionen noch ausführt.
Eskalation statt stilles Scheitern
Ein sauberer Abbruch liefert:
- den erreichten Stand,
- die Stopbedingung,
- bereits ausgeführte Aktionen,
- offene Risiken,
- den nächsten sinnvollen menschlichen Entscheid.
So kann eine Person übernehmen, ohne den gesamten Verlauf neu zu lesen. Ein Agent, der nur "Aufgabe fehlgeschlagen" meldet, verlagert die Arbeit zurück zum Menschen.
Stopbedingungen evaluieren
Testen Sie absichtlich problematische Situationen: nicht erreichbare APIs, widersprüchliche Dokumente, fehlende Rechte, sehr lange Tool-Ausgaben und Aufgaben ohne eindeutige Lösung. Prüfen Sie, ob der Agent rechtzeitig stoppt und ob der gespeicherte Zustand eine sichere Fortsetzung erlaubt.
Quellen
- OWASP, Agentic AI Threats and Mitigations: https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- Google SRE Book, Handling Overload: https://sre.google/sre-book/handling-overload/
- OpenAI auf X zu langlaufenden Agenten und Context Compaction: https://x.com/OpenAI/status/2082616641834422740
Nächster Schritt
Definieren Sie für einen Pilot maximale Schritte, Retries, Laufzeit und Kosten. Ergänzen Sie drei fachliche Stopbedingungen und einen Eskalationspfad. Führen Sie danach einen Test aus, bei dem jedes Limit absichtlich erreicht wird, und prüfen Sie, ob keine nachgelagerte Aktion weiterläuft.