Vor einigen Wochen startete ich das Projekt SafeRun, eine zuverlässige Infrastruktur für KI-Agenten im Produktiveinsatz. Der erste Gedanke vieler Entwickler in diesem Bereich: Validierung vorab. Blockiere unerwünschte Aktionen, verhindere Endlosschleifen, erzwinge Richtlinien. Das sind wertvolle Funktionen – und SafeRun bietet sie alle. Doch sie waren nicht unser erster Schritt. Stattdessen entwickelten wir als Erstes ein System namens Replay. Der Grund dafür ist ein oft unterschätzter Fehler, der fast jedes Team trifft, das KI-Agenten in die Produktion bringt.
Der unsichtbare Flaschenhals: Warum Fehlersuche ohne Reproduzierbarkeit scheitert
Das Szenario ist vertraut: Ein KI-Agent führt eine unerwünschte Aktion aus. Das Team untersucht den Vorfall – doch die Logs sind unvollständig, die Spuren flach. Weder die Argumentation des Modells zwischen den Tool-Aufrufen noch der Kontext der Entscheidung ist dokumentiert. Selbst die Parameter des gescheiterten Aufrufs fehlen oft. Ohne diese Informationen bleibt nur eins: Man startet den Agenten erneut und versucht, die Bedingungen des Fehlers künstlich zu reproduzieren. Doch KI-Systeme sind nicht deterministisch. Die Umgebung ändert sich, der Fehler lässt sich nicht nachstellen – und am Ende verbringt das Team ein ganzes Wochenende mit der Analyse eines einzigen Vorfalls.
Dieses Problem ist kein Einzelfall. Bei Gesprächen mit über zwanzig Teams, die KI-Agenten im Produktiveinsatz betreiben, traf ich auf dieselbe Erfahrung: Jeder hatte diese Situation durchlebt. Nicht gehört, sondern selbst erlebt. Beobachtungswerkzeuge wie LangSmith oder Langfuse liefern zwar wertvolle Einblicke – sie beschreiben, was passiert ist, können aber keine exakte Reproduktion liefern. Ein Trace zeigt den Ablauf, doch ohne Replay fehlt die Möglichkeit, jeden Schritt im Detail nachzuvollziehen.
Replay als Grundpfeiler: Warum Nachverfolgbarkeit Prävention erst ermöglicht
Replay bedeutet, den vollständigen Zustand eines Agentenlaufs mit ausreichender Genauigkeit einzufangen – sodass man ihn später Bild für Bild analysieren kann. Jeder Tool-Aufruf, jede Argumentation des Modells, der abgerufene Kontext, die geprüften Richtlinien und die getroffenen Entscheidungen müssen lückenlos dokumentiert sein. Das ist kein Logging-Problem, sondern eine Frage der deterministischen Zustandsaufzeichnung.
Bei SafeRun folgt die Produktentwicklung einem klaren Prinzip: Replay → Verstehen → Regel erstellen → Verhindern. Ohne Replay lässt sich ein Fehler nicht exakt nachvollziehen. Ohne Verständnis des Problems kann keine Regel zur Vermeidung erstellt werden. Und ohne eine vollständige Analyse des Vorfalls bleiben Präventionsmaßnahmen nur oberflächliche Patches.
Ein konkretes Beispiel zeigt, warum diese Reihenfolge entscheidend ist. Ein Agent von Stripe führte versehentlich eine Rückerstattung statt einer Belastung durch – verursacht durch eine einzelne boolesche Variable, die während der Planung falsch gesetzt wurde. Die meisten Beobachtungswerkzeuge würden nur den erfolgreichen Aufruf der Rückerstattung protokollieren. Doch erst mit Replay wird sichtbar, dass die ursprüngliche Anfrage eine Belastung war und die boolesche Variable is_refund: false in der Planung korrekt gesetzt war. Irgendwo zwischen Planung und Ausführung wurde der Wert geändert – durch Halluzinationen des Modells, Prompt-Injection, einen Codefehler oder falsch interpretierten Kontext. Erst diese Analyse ermöglicht es, eine wirksame Regel zu erstellen und das Problem an der Wurzel zu beheben.
Die Entwicklung von SafeRun: Eine stufenweise Infrastruktur
Die Roadmap von SafeRun folgt einem logischen Aufbau, bei dem jede Phase auf der vorherigen aufbaut. Die ersten Schritte konzentrierten sich auf die Grundlagen:
- Phase 0: Ein funktionsfähiger Prototyp mit sechs simulierten Fehlerszenarien, darunter das Stripe-Boolean-Problem.
- Phase 1: Eine persistente Backend-Lösung auf Basis von Supabase, die Replays auch nach einem Seitenneuladen oder Browser-Close speichert.
- Phase 2: Die Einführung der API
/v1/check-actionmit einer Reaktionszeit unter 50 Millisekunden im 95. Perzentil. Entscheidungsrelevante Kontexte – Eingaben, abgerufene Daten, externe Zustände, Versionen von Richtlinien und Evaluierungsmodellen – werden synchron erfasst und asynchron gespeichert. Der Replay wird nicht nachträglich zusammengesetzt, sondern direkt aus der Entscheidung generiert. - Phase 3: Python- und TypeScript-SDKs, die sich in drei Zeilen installieren lassen. Ein
@guard-Dekorator umschließt jeden Tool-Aufruf. - Phase 4: Intent Guard, ein Mechanismus zur Erkennung von Tool-Aufrufen mit korrekter Syntax, aber falscher Absicht – wie im Stripe-Beispiel. Sichtbare Konfidenzwerte und die Möglichkeit zur Schwellenwerteinstellung ermöglichen eine iterative Verbesserung der Regeln.
- Phase 5: Unterstützung für Mehrbenutzerprojekte mit projektbezogenen API-Schlüsseln, Umgebungsseparierung (Dev-Logs, Staging-Warnungen, Produktionssperren), Replay-Redaktion und auditierbaren Protokollen.
- Phase 6: Onboarding von Designpartnern und ein Dashboard zur Messung der Präventionswirkung.
- Phase 7: Selbstgehostete oder VPC-basierte Bereitstellung, Unterstützung von SSO/SAML, Export von Audit-Protokollen und Vorbereitung auf SOC-2-Compliance. SafeRun wird zudem als MCP-fähiges Tool integrierbar.
Jede dieser Phasen dient dem übergeordneten Ziel: dem Replay-System. Ohne eine verlässliche Nachverfolgbarkeit wären alle folgenden Funktionen nur unvollständige Patches gegen Probleme, deren Ursachen im Dunkeln bleiben.
Ausblick: Von der Entwicklung zur produktiven Nutzung
Aktuell stehen wir kurz vor dem Onboarding der ersten Designpartner – Teams, die KI-Agenten entwickeln, die echtes Geld bewegen, Kundendaten ändern oder direkt mit Nutzern interagieren. Die Partnerschaft ist kostenlos und erfolgt im Austausch für ehrliches Feedback. Für Teams, die bereits Agenten in Produktion betreiben und SafeRun testen möchten, steht das SDK über pip install saferun zur Verfügung.
Die Lehre aus dieser Entwicklung ist klar: Prävention beginnt nicht mit der Blockade von Fehlern, sondern mit der Fähigkeit, sie exakt zu verstehen. Replay ist der Schlüssel – und erst darüber entstehen echte Fortschritte in der Zuverlässigkeit von KI-Agenten.
KI-Zusammenfassung
AI ajanlarınız üretimde hatalar yaptığında, logları incelemek yetmez. Bir hatayı yeniden üretmek için Replay yeteneğine ihtiyacınız var. Güvenilirlik altyapısının temeli burada yatıyor.