Wie Sie Kontrollverlust über KI-Agenten verhindern: Lokale Memory-Layer für private Multi-Agent-Systeme

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. In meinem Studio DennisCraft AI baue und betreibe ich produktive Multi-Agenten-Systeme für DACH-B2B-Kunden in Logistik, Fintech und Industrie. Der verwendete Stack: Claude, Supabase, n8n, Doppler und selbst gehostetes Postgres. Im produktiven Alltag zeigt sich immer wieder ein zentrales Problem: KI-Agenten verlieren den Kontext, agieren inkonsistent, wiederholen Fehler oder geraten in Endlosschleifen. Genau dann, wenn Compliance und Nachvollziehbarkeit entscheidend sind.

Warum Standard-Memory-Ansätze in regulierten Private-Setups scheitern

Viele Multi-Agent-Frameworks nutzen Cloud-basierte Speicherlösungen (z.B. Vektor-Datenbanken, externe APIs) oder verzichten ganz auf persistente Memory-Strukturen. In der Demo funktioniert das, im regulierten Betrieb stoßen Sie schnell an Grenzen:

• Fehlende Nachvollziehbarkeit: Ohne persistente Speicherung lässt sich ein Entscheidungsweg nicht rekonstruieren.
• Datenabfluss-Risiko: Cloud-Memory verstößt gegen DSGVO/BSI-Anforderungen und erhöht das Audit-Risiko.
• Instabiles Agentenverhalten: Ohne lokal gesicherte Memory wiederholen Agenten fehlerhafte Aktionen oder verlieren die Übersicht in langen Reasoning-Chains.

Ich habe in drei aktuellen Produktiv-Projekten denselben Fehler beobachtet: Claude-Agenten, orchestriert via n8n, verloren zwischen einzelnen Workflows ihre Memory und führten dieselbe externe API mehrfach aus. Das führte zu erhöhten Kosten, Compliance-Fragen und operativen Ausfällen.

Lokale Memory-Layer: Ein stabiler Architekturansatz für Multi-Agenten

Die Lösung: Ein lokaler, auditierbarer Memory-Layer auf selbst gehostetem Postgres oder Supabase. Dadurch:

• Werden alle Reasoning-Schritte jedes Agenten persistent gespeichert.
• Lassen sich Ereignisse agentenübergreifend verbinden und nachverfolgen (Wer hat wann was ausgelöst?).
• Erhalten Sie vollständige Transparenz für Debugging und Revisionssicherheit.
• Bleiben alle Daten im Kundenperimeter – DSGVO- und BSI-konform.

Datenmodell: Was sollte gespeichert werden?

Beispiel: Minimales Postgres-Schema

CREATE TABLE agent_sessions (
  session_id UUID PRIMARY KEY,
  agent_id TEXT NOT NULL,
  started_at TIMESTAMP NOT NULL,
  status TEXT
);

CREATE TABLE agent_steps (
  step_id UUID PRIMARY KEY,
  session_id UUID REFERENCES agent_sessions(session_id),
  input JSONB,
  output JSONB,
  timestamp TIMESTAMP NOT NULL
);

CREATE TABLE agent_events (
  event_id UUID PRIMARY KEY,
  step_id UUID REFERENCES agent_steps(step_id),
  event_type TEXT,
  payload JSONB
);

Integration mit n8n und Supabase: Produktionsbewährtes Pattern

In meinem Ansatz mit n8n und Supabase sieht die Pipeline so aus:

1. n8n startet den Prozess (z.B. eingehender API-Aufruf).
2. Vor Start des Agenten wird ein neuer Eintrag in agent_sessions erstellt.
3. Jeder Reasoning-Schritt wird als agent_steps-Row (Input, Output, Timestamp) persistiert.
4. Externe Events (API, Fehler) landen in agent_events.
5. Die gesamte Kette kann live auditiert werden (z.B. via live.gerdennisai.com).

Dieses Muster identifiziert sofort Endlosschleifen, doppelte API-Calls oder verlorene Kontexte. Für Audits liefert es die lückenlose Historie – ein Muss für DSGVO, BSI Grundschutz oder die Vorbereitung auf den EU AI Act.

n8n node: Reasoning-Schritt speichern

{
  "operation": "insert",
  "table": "agent_steps",
  "data": {
    "step_id": $uuid(),
    "session_id": {{$json["session_id"]}},
    "input": {{$json["input"]}},
    "output": {{$json["output"]}},
    "timestamp": {{$now}}
  }
}

Operativer Effekt: Was ändert sich im Produktivbetrieb?

• Keine Endlosschleifen mehr: Sie können Limits pro Session setzen und auffälliges Verhalten automatisch markieren.
• Fehler im Reasoning sofort sichtbar: Wiederholte Aktionen oder fehlerhafte Schritte werden im Log klar erkennbar.
• DSGVO/BSI-Konformität: Kein Memory-Schritt verlässt den Kundenperimeter, selbst temporäre Logs bleiben intern.
• Erklärbarkeit für Audits: Besonders in Fintech und Logistik ist die vollständige Nachvollziehbarkeit Pflicht.

Nachteil: Der Storage-Bedarf steigt bei sehr vielen Agenten und langen Reasoning-Chains. In meinen eigenen DACH-Projekten (2024–2025) lag das Plus aber unter 15 % der bisherigen Postgres-Auslastung.

FAQ

Können Sie diesen Memory-Layer ohne Supabase bauen?

Ja, ein selbst gehostetes Postgres reicht vollkommen. Supabase vereinfacht nur das API-Onboarding.

Wie erkennen Sie Anomalien im Reasoning?

Durch Aggregation von agent_steps: Überschreitet die Schrittzahl pro Session einen Grenzwert, wird automatisch alarmiert. Auch doppelte Outputs können getrackt werden.

Verlangsamt dies die Agenten?

In meinen Produktivmessungen dauert ein Insert in Postgres 15–30 ms (DennisCraft, 2024). Für B2B-Prozesse ist das vernachlässigbar.

Wie löschen Sie Memory im Sinne der DSGVO?

Durch TTL auf agent_sessions und periodisches Löschen via cron oder n8n-Workflow.

Können Agenten Memory gemeinsam nutzen?

Über Zuordnungstabellen ja, aber mit strikter Isolationslogik für vertrauliche Daten.

In welchem Schritt Ihrer Agenten-Pipeline verlieren Sie am häufigsten Kontext – beim LLM-Call, im externen API-Step oder bei der Orchestrierung? Das interessiert mich wirklich.
Ich biete einen kostenlosen 30-min Stack-Audit für DACH-Unternehmen mit KI-Projekten in regulierten Märkten. Kontaktieren Sie mich auf LinkedIn oder bei @ger_dennis_ai.