Memory und Kontext: Agenten mit Gedächtnis

🔄 In der letzten Lektion hast du einen KI-Agenten gebaut, der eigenständig Tools aufruft und Recherche-Aufgaben löst. Aber frag ihn nach 5 Minuten „Was war nochmal das Ergebnis?" — und er hat keine Ahnung. Jede Nachricht startet bei null.

Das ist so, als würdest du mit jemandem telefonieren, der nach jedem Satz alles vergisst. Funktioniert für Einmal-Anfragen. Für echte Konversationen? Unbrauchbar.

Was du lernst

Am Ende dieser Lektion baust du einen Chatbot mit persistentem Memory — einen Agenten, der sich an vorherige Nachrichten erinnert, auch nach Server-Neustarts.

Warum Memory?

Ohne Memory:

Du: Wie heißt der Gründer von n8n? Agent: Jan Oberhauser, gegründet 2019 in Berlin. Du: Wann hat er die Series C gemacht? Agent: Ich weiß nicht, über wen du sprichst.

Mit Memory:

Du: Wie heißt der Gründer von n8n? Agent: Jan Oberhauser, gegründet 2019 in Berlin. Du: Wann hat er die Series C gemacht? Agent: n8n (Jan Oberhausers Firma) hat im Oktober 2025 eine Series C über $180M abgeschlossen.

Der Unterschied? Der Agent kennt den Kontext. Er weiß, dass „er" sich auf Jan Oberhauser bezieht und „die Series C" auf n8n. Das macht Memory möglich.

✅ Quick Check: Was genau speichert Memory? (Den Konversationsverlauf — deine Nachrichten und die Antworten des Agenten. Bei jeder neuen Nachricht bekommt das LLM die bisherige Konversation als Kontext mitgeschickt. Mehr Nachrichten = mehr Kontext = höhere Kosten.)

Die drei Memory-Typen in n8n

Window Buffer Memory: Der Einstieg

Der einfachste Memory-Typ. Speichert die letzten N Nachrichten im RAM.

Einrichten:

1. Öffne deinen AI Agent Node
2. Klicke auf „Memory" → „Window Buffer Memory"
3. Konfiguriere: Context Window Length = 10 (speichert die letzten 10 Nachrichten-Paare)

Das war’s. Dein Agent erinnert sich jetzt an die letzten 10 Nachrichten. Simpel, schnell — aber eben nicht persistent. Neustart = weg.

Wann nutzen:

• Beim Entwickeln und Testen
• Für kurzlebige Chats ohne Login
• Wenn Persistenz nicht wichtig ist

PostgreSQL Chat Memory: Für Produktion

Für echte Anwendungen brauchst du persistenten Speicher. PostgreSQL Chat Memory schreibt den Konversationsverlauf in eine Datenbank.

Einrichten:

1. PostgreSQL bereitstellen (falls noch nicht vorhanden):

   • n8n Cloud: Nutzt interne DB — kein Setup nötig
   • Self-Hosted: PostgreSQL ist sowieso empfohlen als n8n-Datenbank

2. Memory-Node konfigurieren:

   • AI Agent → Memory → „Postgres Chat Memory"
   • Credential: Deine PostgreSQL-Verbindung
   • Table Name: chat_history (wird automatisch erstellt)
   • Session ID: {{ $json.sessionId }} (dazu gleich mehr)

3. Session-ID definieren — das ist der wichtige Teil:

# Für Chat-Interface:
{{ $('Chat Trigger').item.json.sessionId }}

# Für Webhook mit User-ID:
{{ $json.userId }}

# Für E-Mail-basierte Konversationen:
{{ $json.from }}

✅ Quick Check: Warum brauchst du eine Session-ID? (Damit verschiedene Nutzer getrennte Konversationsverläufe haben. Ohne Session-ID teilen sich alle denselben Memory — Nutzer A sieht den Kontext von Nutzer B. Die Session-ID isoliert jede Konversation.)

Redis Chat Memory: Speed + TTL

Redis speichert im Arbeitsspeicher — aber persistent (mit Disk-Snapshots). Ideal für:

• Hohe Geschwindigkeit — Redis ist schneller als PostgreSQL für einfache Key-Value-Lookups
• TTL (Time to Live) — Konversationen löschen sich automatisch nach X Minuten
• Session-Management — perfekt für temporäre Chat-Sessions

Einrichten:

1. AI Agent → Memory → „Redis Chat Memory"
2. Credential: Redis-Verbindung (Host, Port, Passwort)
3. Session ID: Wie bei PostgreSQL
4. Session TTL: z.B. 3600 Sekunden (1 Stunde)

Na ja, Redis ist eher was für fortgeschrittene Setups. Für die meisten Anwendungsfälle reicht PostgreSQL völlig. Redis wird relevant, wenn du tausende gleichzeitige Sessions brauchst oder automatisches Aufräumen willst.

Praxis: Chatbot mit Gedächtnis

Lass uns den Recherche-Agenten aus Lektion 4 um Memory erweitern:

Bestehender Workflow:

Chat Trigger → AI Agent (mit Tools)

Erweitert mit Memory:

Chat Trigger → AI Agent (mit Tools + PostgreSQL Memory)

Schritte:

1. Öffne deinen Recherche-Agent-Workflow
2. Klicke auf den AI Agent Node
3. Füge unter „Memory" → „Postgres Chat Memory" hinzu
4. Session ID: {{ $('Chat Trigger').item.json.sessionId }}
5. Teste:

Du: Recherchiere die n8n GmbH. Agent: [Recherche-Ergebnis mit Funding, Gründer, etc.] Du: Wie viel war die letzte Finanzierungsrunde? Agent: Die Series C von n8n betrug $180M bei einer Bewertung von $2,5 Mrd.

Der Agent erinnert sich — er weiß, dass du über n8n sprichst, ohne dass du es wiederholen musst.

Memory-Kosten: Was du wissen musst

Memory ist nicht kostenlos. Jede gespeicherte Nachricht wird bei der nächsten Anfrage als Kontext ans LLM geschickt.

Best Practice: Begrenze den Context Window auf 10-20 Nachrichten. Für die meisten Chats reicht das. Bei langen Konversationen wird’s sonst teuer — und das LLM verliert den Fokus in zu langen Kontexten.

Memory-Strategien

n8n unterstützt aktuell hauptsächlich Window-Memory. Für Summary-Memory kannst du einen separaten LLM-Chain-Node einbauen, der alte Nachrichten zusammenfasst, bevor sie ins Memory gehen — etwas Mehraufwand, aber effektiv.

Wichtigste Erkenntnisse

• Ohne Memory vergisst der Agent nach jeder Nachricht alles — jede Interaktion startet bei null
• Window Buffer Memory ist einfach, aber nicht persistent — nur für Prototyping
• PostgreSQL Chat Memory ist der Standard für Produktion — persistent, durchsuchbar, zuverlässig
• Session-IDs isolieren Konversationen verschiedener Nutzer — Pflicht in Mehrbenutzer-Szenarien
• Memory kostet Extra-Tokens — begrenze den Context Window auf 10-20 Nachrichten
• Redis ist für High-Performance-Sessions mit automatischem Ablaufdatum

Nächste Lektion

Dein Agent hat jetzt ein Gedächtnis und kann Tools nutzen. Aber er kennt nur öffentliche Informationen — Web-Suche und Wikipedia. In der nächsten Lektion baust du RAG-Workflows: Der Agent greift auf deine eigenen Dokumente zu und beantwortet Fragen basierend auf deinem Wissen.