Speicher für KI-Tools: So sichern Sie Wissen über Sessions und Agenten hinweg

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. Bei DennisCraft AI Studio entwickle ich produktive KI-Systeme für DACH-B2B-Kunden in Logistik, Fintech und industrieller Automatisierung – mit Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. Die kritischste Schwachstelle in realen Projekten ist der Verlust von Wissen: Agenten "vergessen" Kontexte zwischen Sessions oder beim Zusammenspiel. Das führt zu Fehlern, die keine Demo zeigt, aber im Produktivbetrieb gravierend sind – insbesondere unter DSGVO und EU AI Act.

Warum KI-Agenten im Betrieb Wissen verlieren

Produktive KI-Agenten arbeiten selten isoliert. In praktisch jedem n8n-Workflow mit Claude gibt es Übergaben, Neustarts oder parallele Agenten. Wenn ein Agent eine Anfrage bearbeitet und ein anderer später übernehmen soll, fehlt oft die persistente Speicherung – alles, was nicht explizit abgelegt wird, verschwindet nach Container-Neustart oder bei Skalierung. Gerade in regulierten Branchen (Fintech, Logistik) kann dies zu Compliance-Problemen und Datenverlust führen.

Speichertypen: Was hält im Produktivbetrieb stand?

In meiner Praxis haben sich nur zwei Typen als stabil erwiesen: relationale Datenbanken (Postgres/Supabase) für strukturierte Zustände und pgvector für Embedding-basiertes Retrieval. Alles andere ist fehleranfällig, sobald mehrere Agenten involviert sind oder Skalierung hinzukommt.

Architektur: Wie Agenten stabil auf Wissen zugreifen

1. Datenmodell: Was speichern?

Ich definiere in jedem Projekt diese Kerntabellen: Context (Aufgabenkontext), AgentState (aktueller Zustand je Agent), ConversationHistory und KnowledgeBase. Jeder Eintrag erhält ein session_id für schnelle Wiederherstellung und nachvollziehbare Ketten.

CREATE TABLE agent_state (
  id SERIAL PRIMARY KEY,
  agent_id VARCHAR(64),
  session_id VARCHAR(64),
  state JSONB,
  updated_at TIMESTAMP DEFAULT now()
);

CREATE TABLE conversation_history (
  id SERIAL PRIMARY KEY,
  session_id VARCHAR(64),
  message TEXT,
  sender VARCHAR(64),
  ts TIMESTAMP DEFAULT now()
);

2. Integration mit Supabase und n8n

In 11 von 14 produktiven Agenten nutze ich Supabase (Postgres mit API). n8n bindet Supabase über das offizielle Node ein. Jeder Workflow-Schritt schreibt den aktuellen Zustand in agent_state, alle Nachrichten landen in conversation_history.

// Beispiel: Zustand in Supabase speichern
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY);

async function saveAgentState(agentId, sessionId, state) {
  await supabase
    .from('agent_state')
    .upsert([{ agent_id: agentId, session_id: sessionId, state }]);
}

3. Vektorspeicher für RAG-Szenarien

Für Retrieval Augmented Generation setze ich pgvector ein. Embeddings aus Dokumentation oder Chatverläufen landen in einer eigenen Tabelle. Entscheidend: Jede Zeile enthält Metadaten zu Agent und Session.

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE embeddings (
  id SERIAL PRIMARY KEY,
  session_id VARCHAR(64),
  content TEXT,
  embedding VECTOR(1536)
);

Sicherheit: Wie der Speicher unter DSGVO/EU AI Act geschützt bleibt

In drei aktuellen Projekten identifizierte ich die gleiche Schwachstelle: LLM-generierter DB-Code zeigt klassische SQL-Injection-Muster (vgl. OWASP 2021 Top 10). Ich setze bandit und semgrep für statische Codeanalyse ein, Supabase-Zugriff erfolgt strikt über Service Roles und eigene Tokens pro Agent. Zusätzlich gilt: Aktivierung von Query-Logging und Alerts bei Anomalien, z.B. Zugriff eines Agenten auf fremde session_id.

# Statische Sicherheitsprüfungen
semgrep --config=auto ./src/
bandit -r ./src/

Fortgeschritten: Agentenübergreifender Wissensaustausch

Müssen mehrere Agenten gemeinsam einen Task bearbeiten (z.B. Parser- und Validator-Agent), lege ich eine gemeinsame Tabelle shared_memory an, referenziert über task_id. So bleibt Wissen und Fortschritt auch bei asynchronen Aufrufen nachvollziehbar und auditierbar.

CREATE TABLE shared_memory (
  id SERIAL PRIMARY KEY,
  task_id VARCHAR(64),
  key VARCHAR(64),
  value JSONB,
  updated_at TIMESTAMP DEFAULT now()
);

Wichtig: Zugriff per Rollen differenzieren und alle Änderungen protokollieren. Ein einzelner Bug darf niemals den Speicher für alle Ketten löschen – hier entscheidet sich Betriebssicherheit gemäß BSI Grundschutz und DSGVO.

FAQ

Wie kann ich schnell Sessionspeicher für bestehende Agenten einführen?

Mindestens eine session_state-Tabelle in Postgres anlegen und nach jedem wichtigen Schritt JSON-Status sichern. Synchronisation lieber zu oft als zu selten – besser überschreiben als verlieren.

Brauche ich pgvector für typische Geschäftsprozesse?

Nur für RAG- oder Embedding-Suchen. Für Status oder Workflow-Flags ist klassischer Postgres schneller und wartungsärmer.

Welcher Speicher-Stack ist am stabilsten?

Erprobt im Produktivbetrieb: Supabase (Postgres) plus pgvector. Lokale Dateien oder Redis führen zu zu vielen Ausfällen bei Skalierung und Neustarts.

Wie verhindere ich Speicherlecks oder Datenabfluss?

Service Roles und Agent-spezifische Tokens nutzen, Row-Level Security aktivieren und regelmäßig bandit/semgrep laufen lassen. Niemals direkte DB-Zugriffe für LLMs freigeben.

Geht Agenten-Memory ohne Datenbank?

Nur bei trivialen Kurzzeit-Agenten. Für produktive, regulierte Workflows ist persistenten, agentenübergreifenden Speicher zwingend.

Gab es bei Ihnen schon produktive Fehler durch „vergessliche“ Agenten? Welche Speicherstrategie funktioniert unter DSGVO für Ihre KI-Pipeline am zuverlässigsten? Ich biete einen kostenfreien 30-min Stack-Check für DACH-Unternehmen mit KI-Projekten – kontaktieren Sie mich auf LinkedIn oder via @ger_dennis_ai.