Memory in Agenten: Simple/Postgres Memory, Session-Keys, "warum vergisst der Chat"

Wenn ein n8n-Chatbot sich nach der ersten Antwort nicht mehr an den Namen des Nutzers oder frühere Fragen erinnert, liegt das fast immer an der Memory-Konfiguration des AI Agent Node und nicht am Sprachmodell selbst. n8n speichert einen Gesprächsverlauf nicht automatisch: Erst wenn Sie eine Memory-Node wie Simple Memory oder Postgres Chat Memory mit dem Agenten verbinden und diese Node über einen eindeutigen Session-Key pro Konversation verfügt, kann der Agent frühere Nachrichten wiederfinden. Fehlt der Session-Key, ist er bei jedem Lauf identisch, oder ist der Chat Trigger nicht auf „From Memory" gestellt, verhält sich der Agent so, als würde jede Nachricht ein neues Gespräch beginnen. Stand: Juli 2026.

Warum der Chat „vergisst": die häufigsten Ursachen

Bevor Sie an der Memory-Node selbst schrauben, lohnt sich ein Blick auf die typischen Fehlerquellen, die in der Praxis immer wieder zum selben Symptom führen.

• Kein Memory-Node verbunden: Ohne verbundene Memory-Sub-Node hat der AI Agent Node kein Gedächtnis, jede Anfrage wird isoliert verarbeitet.
• Session-Key ist konstant oder leer: Hat der Session-Key bei jeder Anfrage denselben festen Wert oder fehlt er, landen alle Unterhaltungen im selben Speicher-Topf oder werden gar nicht zugeordnet.
• Chat Trigger nicht auf „From Memory" gestellt: Laut der n8n-Dokumentation zum Chat Trigger Node müssen Sie die Option „Load Previous Session" auf „From Memory" setzen und Trigger sowie Agent mit derselben Memory-Node verbinden, sonst lädt der Agent keine vorherige Historie.
• Simple Memory im Queue-Modus: Wer n8n im Queue-Modus mit mehreren Workern betreibt, kann sich laut Dokumentation zur Simple Memory Node nicht auf diese verlassen, weil n8n nicht garantiert, dass aufeinanderfolgende Aufrufe vom selben Worker verarbeitet werden.

Der Session-Key: das Herzstück der Speicherzuordnung

Der Session-Key ist der Schlüssel, unter dem n8n eine bestimmte Unterhaltung im Speicher ablegt. Sowohl Simple Memory als auch Postgres Chat Memory verlangen laut n8n-Dokumentation genau diesen einen Pflichtparameter, um „the key to use to store the memory in the workflow data" beziehungsweise, bei Postgres, in der Datenbanktabelle festzulegen. Praktisch bedeutet das: Jede Konversation braucht einen eigenen, stabilen Wert, zum Beispiel die Chat-ID aus dem Chat Trigger, eine Rufnummer bei Telefonie-Szenarien oder eine Kunden-ID aus Ihrem CRM. Nutzen Sie stattdessen einen Ausdruck, der sich bei jedem Lauf ändert, entsteht bei jeder Nachricht eine neue, leere Erinnerung. Ein Detail, das leicht übersehen wird: Sub-Nodes wie Memory-Nodes lösen Ausdrücke laut Dokumentation immer nur für das erste Element auf, nicht für jedes Element einzeln wie reguläre Nodes. Verarbeiten Sie mehrere Chat-Nachrichten in einem Batch, kann das zu einem falschen oder vermischten Session-Key führen.

Simple Memory vs. Postgres Memory: der zentrale Unterschied

Simple Memory, in der Node-Liste als Window Buffer Memory geführt, hält den Gesprächsverlauf laut Dokumentation direkt in den Workflow-Daten der laufenden n8n-Instanz vor und ist damit der schnellste Weg, einem Agenten überhaupt ein Gedächtnis zu geben. Der Haken: Dieser Speicher ist nicht dauerhaft an eine Datenbank gebunden und funktioniert laut n8n ausdrücklich nicht zuverlässig in einem produktiven Workflow, der im Queue-Modus läuft. Postgres Chat Memory schreibt dagegen jede Nachricht in eine Tabelle Ihrer eigenen Postgres-Datenbank, die n8n bei Bedarf automatisch anlegt. Der Verlauf übersteht damit Neustarts, Deployments und mehrere Worker-Prozesse. Beide Node-Typen teilen den Parameter „Context Window Length", der festlegt, wie viele vorherige Interaktionen der Agent als Kontext berücksichtigt: Ein zu hoher Wert treibt Tokenverbrauch und Antwortzeit unnötig in die Höhe. Wichtig bei Postgres: Verbinden Sie mehrere Postgres-Chat-Memory-Nodes im selben Workflow, greifen sie laut Dokumentation standardmäßig auf dieselbe Speicherinstanz zu. Getrennte Unterhaltungen brauchen also unterschiedliche Session-Keys, nicht unterschiedliche Nodes.

Chat Trigger und Agent richtig verbinden

Ein häufig übersehener Schritt betrifft den Chat Trigger Node selbst. Nur wenn Sie dort „Load Previous Session" von „Off" auf „From Memory" umstellen, erscheint überhaupt die Möglichkeit, eine Memory-Node anzubinden, und n8n lädt beim Start einer Sitzung die bisherige Historie. n8n empfiehlt außerdem ausdrücklich, Chat Trigger und Agent an dieselbe Memory-Node anzuschließen, damit beide Komponenten dieselbe Quelle der Wahrheit nutzen. Zwei getrennte Memory-Nodes mit unterschiedlichen Session-Keys erzeugen sonst zwei parallele, inkonsistente Gedächtnisse für ein und dieselbe Unterhaltung, was sich als sprunghaftes oder widersprüchliches Antwortverhalten zeigt.

Praxis: wann sich der Aufwand lohnt

Für einen internen Testbot oder einen Proof of Concept reicht Simple Memory meist aus. Sobald ein Agent produktiv mit echten Kundendaten arbeitet, mehrere gleichzeitige Nutzer bedient oder nachvollziehbar sein muss, wer wann was zum Agenten gesagt hat, ist eine dauerhafte Speicherung in einer eigenen Datenbank wie Postgres Chat Memory die robustere Wahl, auch weil sich der Verlauf dort exportieren, prüfen und bei Bedarf löschen lässt. Wer eine solche Architektur zusammen mit einem sauberen Session-Key-Konzept aufbauen möchte, findet bei den KI-Agenten-Leistungen von NordFlux einen Ansatzpunkt, ebenso wie in der allgemeinen n8n-Automatisierung.

Häufige Fragen zu Memory in n8n-Agenten

Was ist ein Session-Key in n8n genau?

Der Session-Key ist der Bezeichner, unter dem eine Memory-Node einen Gesprächsverlauf ablegt und wiederfindet. Er muss pro Unterhaltung stabil und eindeutig sein, etwa die Chat-ID aus dem Chat Trigger, sonst kann der Agent frühere Nachrichten nicht mehr zuordnen.

Warum reicht Simple Memory manchmal nicht aus?

Simple Memory hält den Verlauf laut n8n-Dokumentation in den Workflow-Daten der laufenden Instanz vor und ist damit nicht an eine Datenbank gebunden. In produktiven Workflows im Queue-Modus mit mehreren Workern funktioniert die Node deshalb ausdrücklich nicht zuverlässig, weil nicht garantiert ist, dass folgende Aufrufe denselben Worker erreichen.

Kann ich mehrere Memory-Nodes in einem Workflow nutzen?

Ja, aber mehrere Postgres-Chat-Memory-Nodes greifen laut Dokumentation standardmäßig auf dieselbe Speicherinstanz zu. Für getrennte Unterhaltungen brauchen Sie unterschiedliche Session-Keys, nicht zwingend unterschiedliche Nodes.

Muss ich am Chat Trigger extra etwas einstellen, damit Memory funktioniert?

Ja. Die Option „Load Previous Session" muss auf „From Memory" stehen, sonst verbindet n8n den Trigger nicht mit einer Memory-Node und lädt keine vorherige Historie. Zusätzlich sollten Chat Trigger und Agent an dieselbe Memory-Node angeschlossen sein.