Warum Ihre KI-Agenten Kontext verlieren und abstürzen: Wie persistentes file-based Planning den Produktivbetrieb sichert

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meinem DennisCraft AI Studio habe ich in den letzten sechs Monaten 14 KI-Agenten für DACH-B2B-Kunden produktiv bereitgestellt. Stack: Claude, Supabase, n8n, Doppler, selbstgehostetes Postgres. Die häufigste Ursache für Ausfälle im Produktivbetrieb? Agenten verlieren nach Neustart oder Crash ihren Kontext – und damit die Kontrolle über den Workflow.

Warum verlieren KI-Agenten Kontext im Produktivbetrieb?

Die meisten Open-Source-Frameworks (LangChain, Haystack, klassische n8n-Workflows) sowie viele Eigenlösungen speichern den Agentenstatus nur im RAM oder in temporären Tabellen. Nach einem Prozessneustart – sei es durch ein Container-Update, orchestrierten Rollout oder Infrastrukturfehler – gehen alle laufenden Workflows und deren Zwischenschritte verloren. Das ist kein theoretisches Problem: Ich habe bei Logistik- und Compliance-Agents erlebt, wie sie nach einem Kubernetes-Knoten-Neustart ihre letzten Entscheidungen „vergessen“ haben. In regulierten Branchen (Finanz, Industrie) ist dies aus Compliance-Sicht undenkbar.

Das Prinzip: Persistentes file-based Planning

Bei diesem Muster werden alle Agenten-Schritte – Zwischenergebnisse, Pläne, Prompts, Artefakte – als einzelne Dateien (JSON, YAML, PDF, Bild) oder versionierte Objekte in S3-kompatiblen Storages abgelegt. Es handelt sich nicht um klassisches Logging, sondern um atomare Zwischenstände zwischen den Workflow-Schritten. Ich nutze dafür Supabase Storage oder MinIO für Dateien und Postgres für Metadaten.

Welche Vorteile bietet das im Produktivbetrieb?

Reproduzierbarkeit: Jeder Workflow kann von jedem abgeschlossenen Schritt wieder aufgenommen werden.
Diagnose: Lückenlose Rückverfolgbarkeit der Agenten-Entscheidungen.
Auditierbarkeit: Gerade in regulierten Branchen (DSGVO, ISO 27001, EU AI Act) wird der Nachweis aller Zwischenstände gefordert, nicht nur des Endergebnisses.

Beispiel: Status in Supabase Storage speichern


import os
from supabase_py import create_client

client = create_client(os.environ["SUPABASE_URL"], os.environ["SUPABASE_KEY"])

def save_agent_step(agent_id, step_num, data):
    filename = f"agent-{agent_id}/step-{step_num}.json"
    client.storage().from_("agent-steps").upload(filename, data)
    # Metadaten in Postgres speichern
    client.table("agent_steps_metadata").insert({
        "agent_id": agent_id,
        "step_num": step_num,
        "filename": filename
    }).execute()

Vergleich: Drei Methoden zur Statuspersistenz

Methode	Vorteile	Nachteile
In-Memory	Schnell, einfach	Geht bei Absturz verloren, nicht auditierbar
Nur Datenbank	Stabil, unterstützt Rollback	Ungeeignet für große Dateien oder verschachtelte Strukturen
Persistentes File-Based	Flexibel, beliebige Artefakte, Wiederaufnahme von jedem Schritt	Zusätzliche Infrastruktur und Konsistenzlogik erforderlich

Praxis: File-Based Planning mit Claude Code und n8n

Im Stack Claude Code + n8n setze ich persistentes file-based Planning um: Jeder Workflow-Schritt (z. B. Spezifikation, Validierung, Bereitstellung) erzeugt ein JSON-Artefakt sowie eventuelle Binärdateien in Supabase Storage. n8n orchestriert, jeder Schritt nutzt eine individuelle Action, die die Outputs in das Storage und die Metadaten in Postgres schreibt.

Beispiel: Custom Node für n8n


// n8n custom node
import { IExecuteFunctions } from 'n8n-core';

export async function execute(this: IExecuteFunctions) {
  const stepData = this.getInputData();
  // ... Agenten-Schritt-Logik ...
  await supabase.storage.from('agent-steps').upload(`agent-${agentId}/step-${stepNum}.json`, JSON.stringify(stepData));
  await supabase.from('agent_steps_metadata').insert({ agent_id: agentId, step_num: stepNum, filename: `agent-${agentId}/step-${stepNum}.json` });
  return this.helpers.returnJsonArray([{ status: "ok" }]);
}

Compliance und Audit: Warum persistentes Planning regulatorische Anforderungen sichert

Gerade in DACH-Märkten mit DSGVO, BSI Grundschutz oder dem neuen EU AI Act reicht es nicht, nur das Endergebnis zu dokumentieren. Die Nachvollziehbarkeit aller Zwischenschritte – inklusive Prompt-Versionen und Artefakten – ist Pflicht für ISO 27001 Audits oder Bankaufsichtsprüfungen. In meinen Projekten war dieser Pattern der entscheidende Faktor, um das Go-live bei DACH-Kunden mit regulatorischem Fokus zu ermöglichen.

FAQ

Warum nicht alles direkt in der Datenbank speichern?

Postgres eignet sich für Metadaten, aber nicht für große Binärdateien oder verschachtelte Strukturen (z. B. PDFs, Bilder). File-Storage ist hier effizienter und besser skalierbar.

Wie vermeiden Sie Race Conditions zwischen Agenten-Schritten?

Ich nutze Optimistic Locking in den Metadaten (Postgres) und generiere eindeutige Dateinamen (SHA256-Hash oder UUID) für jeden Schritt.

Wie werden alte Dateien entfernt?

Über Aufbewahrungsrichtlinien auf Storage-Ebene (z.B. Supabase Storage, MinIO): automatische Löschung nach Alter oder bei Speicherlimit.

Beeinflusst dieser Ansatz die Performance?

Im B2B-Kontext sind 100–200 ms Latenz pro Schritt akzeptabel. Für Echtzeit-Anwendungen kann asynchron synchronisiert werden.

Wie stellen Sie Konsistenz zwischen Storage und Datenbank sicher?

Jeder Schritt schreibt zuerst ins Storage, dann atomar die Metadaten in Postgres. Falls ein Fehler auftritt, wird der gesamte Schritt zurückgesetzt.

An welcher Stelle im Workflow verlieren Ihre Agenten im Produktivbetrieb am häufigsten Kontext: nach Container-Restarts, durch Race Conditions oder beim Verlust von Zwischenartefakten? Ich freue mich auf Ihre Erfahrungen. Ich biete einen kostenlosen 30-min Stack-Audit für DACH-Gründer im regulierten KI-Umfeld – schreiben Sie mir auf LinkedIn oder an @ger_dennis_ai.