Es gibt einen Moment, der fast jedem Team passiert, das zum ersten Mal einen KI-Agenten baut. Die Demo funktioniert wunderschön. Der Agent beantwortet Fragen, verwendet Tools, erinnert sich an Kontext. Man zeigt es Stakeholdern und sie sind beeindruckt. Dann fragt jemand: „Können wir das in die Produktion bringen?“
Diese Frage offenbart eine Lücke, die die meisten Teams unterschätzen. Demo-Agenten sind gebaut, um einmal zu funktionieren, in einer kontrollierten Umgebung, mit einem Entwickler, der zuschaut. Produktionsagenten müssen Tausende Male funktionieren, unter unvorhersehbaren Bedingungen, ohne dass jemand zuschaut.
Die Demo-Falle
Die Demo-Falle ist verführerisch, weil Demos wirklich einfach zu bauen sind. Moderne KI-Frameworks machen es trivial, ein Sprachmodell zu verdrahten, ihm einige Tools zu geben und es Fragen beantworten zu lassen. Das Schwierige ist nicht, es zum Laufen zu bringen – es ist, es am Laufen zu halten.
Demo-Agenten sind typischerweise zustandslos. Neustarten und nichts geht verloren. Sie haben keine Authentifizierung, keine Rate-Limits, kein Monitoring, keine Fehlerbehandlung. Produktion streift jede dieser Annahmen weg.
Was Produktion wirklich erfordert
Die erste Anforderung ist persistenter, zuverlässiger Zustand. Ein Produktionsagent verwaltet laufende Gespräche, akkumulierte Nutzerpräferenzen, Aufgabenwarteschlangen und gelernten Kontext. Dieser Zustand muss Neustarts überleben, Abstürze überleben und wiederherstellbar sein.
ZeroClaw behandelt das mit SQLite im WAL-Modus: ACID-konform, einzelne Datei, überlebt Stromausfälle. Der gesamte Agent-Zustand lebt in einer Datei. Backup ist `cp memory.db memory.db.bak`.
Die zweite Anforderung ist ein Sicherheitsmodell, das nicht auf Vertrauen basiert. Produktionsagenten verarbeiten echte Zugangsdaten, greifen auf echte Dateisysteme zu und interagieren mit echten Nutzern, die nach Schwächen suchen werden. Das Sicherheitsmodell muss Deny-by-Default sein: jedes Tool, jeder Dateipfad, jeder Netzwerk-Endpunkt muss explizit erlaubt sein.
Das ist genau, wo OpenClaws Architektur 2026 versagte. Das WebSocket-Vertrauensmodell, die OS-Level-Skill-Berechtigungen und der Plugin-Marktplatz mit 41,7 % verwundbaren Einträgen waren keine Bugs – sie waren Architekturentscheidungen, die für ein Entwickler-Tool Sinn ergaben und zu Verbindlichkeiten wurden, als dieses Tool als Produktionsinfrastruktur deployed wurde.
Die dritte Anforderung ist Observability. Wenn ein Agent in der Produktion eine falsche Antwort gibt, ist „er hat den falschen Kontext verwendet“ keine nützliche Diagnose. Man braucht Request-Tracing, Token-Usage-Tracking, Tool-Execution-Logs und Memory-Retrieval-Logs.
Zuverlässigkeit ist die vierte Anforderung. Produktion bedeutet 24/7-Verfügbarkeitserwartungen: automatischer Neustart bei Absturz, graceful Degradation wenn der KI-Anbieter nicht verfügbar ist, Connection-Retry mit exponential Backoff für Channels. Ein Agent, der in 10 Millisekunden neu startet, ist effektiv immer verfügbar.
Die fünfte Anforderung ist Kostenkontrolle. Unkontrollierte KI-Agenten verbrennen Tokens auf schwer vorhersehbare Weise. Produktion erfordert Token-Budgets pro Nutzer und pro Channel, Rate-Limiting und Modell-Routing.
Was die meisten Frameworks falsch machen
Das Muster ist konsistent bei Frameworks, die nicht für die Produktion entwickelt wurden: Sie optimieren für die Demo und investieren zu wenig in alles andere.
Der Happy Path bekommt die ganze Aufmerksamkeit. Die Fehlerbehandlung bekommt ein try-catch, das in die Konsole loggt. Die Retry-Logik ist dem Leser überlassen. Wenn der KI-Anbieter einen 429 zurückgibt, stürzt der Agent ab statt die Anfrage in die Warteschlange zu stellen.
Ressourceneffizienz wird als Nice-to-have behandelt statt als Kostenmultiplikator. Ein Framework, das 1 GB RAM für eine einzelne Agent-Instanz verwendet, kann nicht auf Multi-Tenant-Deployments skalieren ohne teure Infrastruktur.
Sicherheit ist der häufigste Nachgedanke. Sicherheit kann nicht nachträglich auf eine permissive Architektur aufgesetzt werden – die OpenClaw-Krise demonstrierte das im Großen.
ZeroClaws Produktionsgeschichte
ZeroClaw wurde von Anfang an für die Produktion entwickelt. Ein einzelnes Binary bedeutet, dass Deployment das Kopieren einer 12-MB-Datei ist. Der 4-MB-RAM-Fußabdruck bedeutet, dass man 50 Agent-Instanzen auf einem einzigen 1-GB-VPS betreiben kann. Der Sub-10ms-Cold-Start bedeutet, dass Neustarts für Nutzer unsichtbar sind.
Rusts Memory Safety eliminiert ganze Schwachstellenklassen zur Compile-Zeit. Das Deny-by-Default-Allowlist-Modell bedeutet, dass jedes Tool, jeder Dateipfad und jeder Netzwerk-Endpunkt explizit in config.toml erlaubt sein muss. SQLite mit WAL-Modus gibt ACID-konformen Zustand in einer einzigen Datei.
Die Produktions-Checkliste
Für Teams, die KI-Agenten in die Produktion bringen, geht die Checkliste weniger um Features als um operative Reife. Tool-Berechtigungen explizit definieren. Token-Budgets pro Nutzer und pro Channel setzen. Monitoring und Alerting auf Fehlerraten und Latenz-Perzentile konfigurieren. Automatische Backups der Speicherdatenbank einrichten. Versagensszenarios absichtlich testen: Was passiert, wenn der KI-Anbieter ausfällt? Wenn der Channel die Verbindung trennt?
Die Lücke zwischen Demo und Produktion ist operative Reife. Das Framework, das man wählt, bestimmt, wie viel davon eingebaut ist versus nachgerüstet. Eine Runtime, die von Tag eins für die Produktion entwickelt wurde, gibt einem ein Fundament zum Aufbauen. Eine Runtime, die für Demos entwickelt und mit Produktions-Features nachgerüstet wurde, gibt einem eine Wartungslast, die sich über die Zeit zusammensetzt.