Was ein Agent sich merkt: LLM-Memory zwischen Kontextfenster und Wissensgraph

Advanced Topics 1 · Reihe: Einstieg in n8n

In Artikel 6 habe ich den AI-Agent-Node mit angehängtem Memory bewusst nicht verwendet. Für eine reine Ticket-Klassifikation ist er das falsche Werkzeug: Ein einzelner Modellaufruf, der einem festen Schema folgt, braucht kein Gedächtnis über vergangene Tickets. Diese Entscheidung war richtig, aber sie hat eine Frage offengelassen, die sich stellt, sobald ein Agent über mehr als einen Aufruf hinweg kohärent bleiben soll: Wie merkt sich ein Sprachmodell überhaupt etwas, und welche Form von Gedächtnis braucht welche Aufgabe.

Dieser Artikel ist der erste einer Reihe von Advanced Topics, die einzelne Themen aus der n8n-Reihe vertiefen. Hier geht es ums Konzept: wie ein Sprachmodell sich etwas merkt und welche Form von Gedächtnis zu welcher Aufgabe passt. Wie das in der Praxis aussieht, zeige ich im nächsten Artikel. Dort baue ich in einen Ticket-Triage-Workflow ein, was n8n von Haus aus nicht mitbringt.

Memory wird oft als Funktion behandelt, die man dazuschaltet. In der Praxis ist es eine Architekturentscheidung mit Folgen für Skalierung, Latenz und Verlässlichkeit. Ich ziehe die Linien deshalb von Grund auf, mit den Quellen, die hinter den einzelnen Aussagen stehen.

Memory ist Architektur, kein Feature

Ein Sprachmodell hat zwei grundverschiedene Arten von Wissen. Das eine steckt in den Gewichten, eingefroren zum Zeitpunkt des Trainings. Das ist die parametrische Seite: Sie kostet keine zusätzliche Latenz, sie trägt das allgemeine Weltwissen, und sie lässt sich ohne teures Fine-Tuning nicht ändern. Vom Moment des Trainingsendes an beginnt dieses Wissen zu veralten. Wer sich für Live-Daten auf die Gewichte verlässt, bekommt selbstbewusst vorgetragene, aber möglicherweise veraltete Antworten.

Das andere Wissen wird zur Laufzeit in den Kontext injiziert. Das ist die non-parametrische Seite, und sie ist der eigentliche Hebel. Alles, was ein Agent über den aktuellen Vorgang, den Nutzer oder die Domäne weiß, ohne dass es in den Gewichten steht, wird ihm aktiv mitgegeben. Damit verschiebt sich die Rolle des Entwicklers: Statt ein zustandsloses Modell nur anzusprechen, verwaltet er den Zustand der Anwendung über mehrere Schritte hinweg. Genau das ist der Punkt, an dem Memory aufhört, ein Schalter zu sein, und zu einer Architekturentscheidung wird.

Diese erste Achse, parametrisch gegen non-parametrisch, beschreibt, wo Wissen liegt. Sie beantwortet aber noch nicht, welche Funktion ein bestimmter Gedächtnisinhalt erfüllt. Diese zweite Frage wird leicht mit der ersten vermischt, und aus der Vermischung entsteht eine unscharfe Einteilung.

Die saubere Taxonomie kennt vier Funktionen

Eine verbreitete Art, Memory zu sortieren, reiht vier Begriffe nebeneinander: in-context, external, parametric und episodic. Das ist als Einstieg griffig, vermengt aber zwei verschiedene Fragen. Drei dieser Begriffe beschreiben einen Speicherort. In-context ist das, was gerade im Prompt steht, external ist das, was per Retrieval aus einem Store kommt, parametric ist das in den Gewichten. Der vierte, episodic, beschreibt keinen Ort, sondern eine kognitive Funktion. Episodisches Gedächtnis ist deshalb kein vierter, paralleler Typ neben den dreien. Es wird in der Praxis als external memory implementiert: zusammengefasste Logs und Nutzerprofile, die anhand einer Session-ID nachgeladen werden. Ort und Funktion gehören auf zwei Achsen, nicht in eine Liste.

Trennt man die Funktion sauber heraus, steht ein etablierter Rahmen bereit. CoALA, kurz für Cognitive Architectures for Language Agents (Sumers et al., 2023, veröffentlicht in TMLR 2024), übernimmt die kognitionswissenschaftliche Gliederung und unterscheidet vier Funktionen:

Zwei dieser Funktionen fallen aus der griffigen Vierer-Reihe heraus: semantic und procedural. Gerade die semantische Schicht ist für persönliche Assistenten der dominante Typ, die prozedurale für Coding-Agenten. Wichtiger noch ist der Schritt, der episodic und semantic verbindet: die Konsolidierung von konkreten Erfahrungen zu generalisierten Fakten. Ein Agent, der nur Episoden sammelt, ohne sie je zu verdichten, häuft eine Chronik an, aber er lernt nichts. Dieser Verdichtungsschritt, in der Literatur als Reflection bekannt, ist der eigentliche Übergang von „hat es erlebt" zu „weiß es".

Das ist kein akademisches Detail. Memory ist als Forschungsfeld jung und umkämpft. Systeme wie MemGPT/Letta, Mem0 oder Zep/Graphiti konkurrieren offen um den besten Ansatz, und selbst der De-facto-Benchmark LoCoMo ist Gegenstand öffentlicher Methodenstreitigkeiten. MemPalace, über das ich im April geschrieben habe, setzt genau bei der episodischen Schicht an: Es speichert die Gesprächsverläufe als Rohtext, statt sie von einer KI zusammenfassen zu lassen, und beansprucht damit im LongMemEval einen Vorsprung vor Mem0 und Zep. Wer Memory in vier saubere Schubladen sortiert, suggeriert eine Geschlossenheit, die es in der Sache nicht gibt.

Das Kontextfenster ist kein Gedächtnis

Eine häufige und naheliegende Annahme lautet: Wenn das Kontextfenster groß genug ist, brauche ich kein Memory, dann packe ich einfach alles hinein. Diese Annahme ist empirisch nicht belegt. Im Gegenteil, drei Studien widersprechen ihr, und das auf unterschiedliche Weise, weshalb es sich lohnt, sie auseinanderzuhalten.

Die erste Arbeit ist Lost in the Middle (Liu et al., 2023). Modelle nutzen Information am Anfang und am Ende eines langen Prompts zuverlässig, in der Mitte schlechter. Die Trefferkurve über die Position bildet ein U. Liegt die relevante Stelle in der Mitte, fällt die Genauigkeit deutlich ab. Daher die verbreitete Kurzform, Transformer ignorierten die Mitte eines dichten Prompts.

Die zweite Arbeit ist Chromas Context Rot (2025), und sie sagt etwas Allgemeineres. Über 18 Modelle hinweg zeigt die Studie, dass die Leistung mit zunehmender Eingabelänge unzuverlässiger wird, unabhängig von der reinen Position und schon bei trivialen Aufgaben. Reine Längenzunahme kostete im Mittel rund 8 Prozent Genauigkeit (Quelle: Chroma 2025). Das relativiert das saubere U: Die Degradation ist in erster Linie längengetrieben, nicht primär ein Mitte-Effekt. Beide Studien werden oft im gleichen Kontext gesehen, als wäre die Mitte-Vernachlässigung der Grund für die Längen-Degradation. Aber es sind zwei verschiedene Beobachtungen, und nur die zweite trägt die Schlussfolgerung, dass mehr Token an sich schaden.

Eine dritte Arbeit schärft das Bild. NoLiMa (Adobe Research, ICML 2025) entfernt gezielt die wörtliche Überlappung zwischen Frage und gesuchter Stelle, sodass das Modell wirklich verstehen statt nur Stichwörter abgleichen muss. Unter dieser Bedingung fällt die effektive nutzbare Kontextlänge weit unter die beworbenen Fenster, in vielen Fällen auf wenige Tausend Token (Quelle: NoLiMa 2025). Die Schlussfolgerung über alle drei Studien hinweg ist robust: Mehr Token sind nicht automatisch besser, und ein großes Kontextfenster ersetzt kein durchdachtes Gedächtnis. Wenn der Speicher im Prompt also nicht beliebig wächst, muss das Wissen nach außen wandern.

RAG als das externe Gedächtnis

Sobald die Daten zu groß für den Prompt werden, verlagert man sie in einen Retrieval-Layer. Die Dokumente liegen als Embeddings in einem Vektor-Store, zur Laufzeit holt eine Ähnlichkeitssuche die passenden Stücke und legt sie in den Kontext. Das ist Retrieval-Augmented Generation, der Standardweg, um Antworten ohne Fine-Tuning an belegbare Fakten zu binden (Grounding). Der Speicher ist praktisch unbegrenzt, und die Token-Kosten bleiben kalkulierbar, weil nur die relevanten Stücke ins Modell gehen.

Retrieval wird oft als der simple, statische Vorläufer der klugen Agenten-Ansätze dargestellt. Das unterschätzt, wie weit der Stand der Technik ist. Die offene Stelle bei RAG ist das Zerteilen der Dokumente in Textblöcke (Chunking): Schneidet man zu klein, geht Kontext verloren, schneidet man zu groß, sprengt man das Token-Budget und holt Rauschen mit. Anthropics Contextual Retrieval setzt genau hier an und stellt jedem Block vor dem Einbetten einen kurzen, vom Modell erzeugten Kontextsatz voran. Die Wirkung ist messbar: Die Fehlerrate beim Abruf sinkt um 35 Prozent allein durch kontextualisierte Embeddings, um 49 Prozent zusammen mit BM25 und um 67 Prozent, wenn zusätzlich ein Re-Ranker dahintergeschaltet wird (Quelle: Anthropic 2024). Hybride Suche aus dichten Vektoren und klassischem Stichwort-Abgleich (Keyword-Matching), gefolgt von einem Re-Ranker, der die Treffer nach tatsächlicher Relevanz neu ordnet, ist heute Lehrbuch. Gut gebautes RAG löst damit viele Probleme, die man sonst erst der nächsten Komplexitätsstufe zuschreibt.

Agentic RAG verschiebt die Kontrolle ins Modell

Bei Agentic RAG entscheidet nicht mehr eine fest verdrahtete Pipeline, was abgerufen wird, sondern das Modell selbst. Der Agent bekommt Retrieval-Werkzeuge und wählt, ob er sucht, wo er sucht und ob er nach einem unzureichenden Treffer eine verfeinerte zweite Suche startet. Für mehrstufige Recherche, bei der eine einzelne Anfrage nicht reicht und mehrere Quellen verglichen werden müssen, ist das die passende Flexibilität.

Diese Flexibilität ist nicht umsonst. Der Pfad durch das Retrieval ist nicht mehr deterministisch, dieselbe Frage kann zwei verschiedene Wege nehmen. Jeder zusätzliche Reasoning-Schritt kostet einen weiteren Modellaufruf, was Latenz und Token-Verbrauch nach oben treibt. Die Fehlersuche wird schwerer, weil ein falsch gewählter Suchpfad nicht im Code steht, sondern in einer Modellentscheidung. Anthropics Linie für solche Systeme ist deshalb, mit der einfachsten Lösung zu beginnen und Komplexität nur dann hinzuzufügen, wenn sie sich nachweislich auszahlt (Quelle: Anthropic, Building Effective Agents). Agentic RAG ist nicht der Standard, sondern eine Antwort auf Aufgaben, die der lineare Pfad nicht löst. In n8n hat dieser Ansatz einen praktischen Vorteil: Jeder Retrieval-Schritt des Agenten ist in der Ausführungsansicht (Executions) sichtbar, also welches Werkzeug mit welcher Anfrage aufgerufen wurde und was zurückkam. Das macht einen sonst undurchsichtigen Mehrschritt-Lauf nachvollziehbar.

GraphRAG ist ein Spezialwerkzeug, kein Upgrade

GraphRAG ersetzt den flachen Vektor-Store durch einen Wissensgraphen. Statt ähnlich klingende Textstücke zu finden, bildet der Ansatz Entitäten und ihre Beziehungen ab und erlaubt es, das Datennetz zu traversieren. Microsofts Umsetzung lässt ein Modell aus dem Rohtext Entitäten und Relationen extrahieren, gruppiert sie über Community Detection und erzeugt vorab Zusammenfassungen je Cluster. Die Stärke liegt bei globalen Fragen, etwa nach übergreifenden Themen quer durch hunderte Dokumente, die eine reine Ähnlichkeitssuche nicht zusammenführen kann.

Diese Stärke hat einen Preis, der selten genannt wird. Die Extraktion ist modellgetrieben und teuer, sowohl in der Erstindizierung als auch bei jeder Aktualisierung, weil sich Communities neu berechnen. Im Vergleich kostet eine Abfrage über den Graphen ein Vielfaches an Token gegenüber einfachem RAG, in einem Benchmark rund das Dreihundertsiebenundsiebzigfache (Quelle: GraphRAG-Bench 2025). Der Nutzen ist nicht universal: Bei einfacher Faktensuche schneidet GraphRAG messbar schlechter ab als ein simpler Vektor-Store, weil der Umweg über den Graphen dort nichts beiträgt. Leichtere Varianten wie LightRAG oder temporale Ansätze wie Graphiti senken die Kosten, ändern aber nichts am Grundsatz. Wie hoch der Preis ausfällt, hängt allerdings an den Daten. Graphify, das ein Code-Repository lokal in einen Wissensgraphen übersetzt, zieht die Struktur deterministisch über einen Tree-sitter-Parser und braucht das teure Modell nur noch für unstrukturiertes Material wie PDFs. Bei klar strukturierten Daten lässt sich ein Graph also deutlich günstiger bauen, als es die modellgetriebene Extraktion nahelegt. Die Abwägung bleibt dieselbe, ein Aufbau-Schritt gegen bessere strukturelle Fragen, nur die Rechnung fällt anders aus. Der Konsens für 2026 lautet deshalb nicht „Graph schlägt Vektor", sondern adaptives Routing: einfache Anfragen an den Vektor-Store, komplexe und globale an den Graphen. GraphRAG ist ein Werkzeug für eine bestimmte Klasse von Fragen, nicht die nächsthöhere Stufe für alle.

Wo Memory unter Last versagt

Ein sauber gewähltes Memory-Konzept reicht nicht, wenn der Betrieb es unter Last aushöhlt. Vier Bruchstellen lohnen die Aufmerksamkeit, drei davon betreffen das Lesen, eine das Schreiben.

Die erste ist Context Rot über lange Vorgänge. Je länger eine Konversation läuft, desto mehr verliert das Modell die zentralen Anforderungen aus dem Blick, während es die Begrüßung am Anfang noch parat hat. Die Gegenmaßnahme ist Kompression: Ältere Abschnitte werden regelmäßig zu einer knappen Zustandszusammenfassung verdichtet, damit die wichtigen Informationen in den verlässlichen Zonen des Kontexts bleiben.

Die zweite sind Retrieval-Fehler im großen Maßstab. Semantische Ähnlichkeit ist nicht dasselbe wie Relevanz, und mit wachsendem Bestand zieht eine Suche nach den k ähnlichsten Treffern (Top-k) zunehmend Stücke heran, die Stichwörter teilen, aber den nötigen Kontext nicht tragen. Sie lenken das Modell ab und blähen das Budget. Die Gegenmaßnahme ist die schon genannte Kombination aus hybrider Suche und einem Re-Ranker, der Relevanz bewertet, bevor etwas ins Kontextfenster gelangt.

Die dritte ist Relevanz-Drift in Agenten-Schleifen. Wenn ein Agent seine eigenen Suchanfragen formuliert, kann ein einzelner knapper Fehlgriff eine Kette auslösen: Der Agent nutzt das Rauschen, um die nächste Suche zu formen, und entfernt sich mit jedem Schritt weiter von der ursprünglichen Absicht. Die Gegenmaßnahme ist ein Wächter, der die Konfidenz der abgerufenen Daten prüft und den Agenten bei zu schwachen Treffern nicht weiterziehen lässt, sondern die Suche zurücksetzt oder rückfragt. Dieser Wächter sitzt auf dem Lesepfad, er filtert, was aus dem Speicher zurückkommt.

Die vierte Bruchstelle wird selten genannt und ist die gefährlichste, sobald ein Agent selbst in den Speicher schreibt. Biegt ein Lauf falsch ab und legt einen erfundenen Fakt im Store ab, holen ihn spätere Anfragen als Wahrheit zurück. Der Fehler verschwindet nicht von allein, er verstärkt sich, weil jede Abfrage ihn bestätigt und der Agent auf seiner Basis weiterarbeitet. Das ist Schreib-Kontamination, im Englischen Memory Poisoning, und es ist die Schreibpfad-Variante der kompoundierenden Fehler, vor denen die Agenten-Literatur warnt. Der Lese-Wächter aus dem vorigen Absatz hilft hier nicht, denn der Quatsch ist zu dem Zeitpunkt längst persistent. Was fehlt, ist ein zweiter Wächter auf dem Schreibpfad. Vor dem Festschreiben prüft eine unabhängige Instanz, ob der Eintrag dem erwarteten Schema entspricht, ob er durch eine Quelle gedeckt ist und ob die Konfidenz über der Schwelle liegt. Fällt er durch, geht er in Quarantäne oder in einen Dead-Letter-Zweig, nicht in den Store. Die etablierten Muster dafür heißen Self-RAG, wo das Modell seine Ausgabe vor dem Festschreiben selbst kritisiert, und Corrective RAG, wo ein eigener Evaluator schwache Ergebnisse abfängt. Die Grundregel ist einfach: Eine KI schreibt nie unvalidiert in das Langzeitgedächtnis, und zu jedem Eintrag gehört seine Herkunft.

Hinter diesen vier Punkten steht ein größeres Bild, das in der reinen Retrieval-Hygiene oft fehlt. Memory ist nicht nur additiv. Was nie vergessen wird, verstopft den Speicher und lenkt ab, deshalb gehören Strategien fürs Vergessen und Verfallen (Forgetting, Decay) zum Entwurf wie das Speichern selbst. Die Konsolidierung von episodic zu semantic, der Reflection-Schritt aus dem Taxonomie-Abschnitt, ist das, was aus gesammelten Vorgängen nutzbares Wissen macht. Unter dem Begriff Context Engineering haben sich vier Aufgaben herausgebildet, die das zusammenfassen: schreiben, auswählen, komprimieren und isolieren. Retrieval deckt davon nur das Auswählen ab.

n8ns native Grundausstattung und ihre Grenzen

Vor diesem Hintergrund lässt sich präzise sagen, was n8n von Haus aus mitbringt. Der AI-Agent-Node nimmt einen Memory-Sub-Node an. Simple Memory hält die letzten N Interaktionen als gleitendes Fenster im Workflow-Speicher, die Varianten Redis Chat Memory, Postgres Chat Memory und MongoDB Chat Memory legen dieselbe Historie persistent ab. Der Chat Memory Manager erlaubt darüber hinaus, Nachrichten gezielt einzufügen, zu lesen oder zu löschen. Auf der Retrieval-Seite stehen Vektor-Store-Nodes für Pinecone, Qdrant, Supabase, PGVector, Milvus, Weaviate, Chroma und weitere bereit, dazu Embedding-Nodes inklusive lokaler Modelle über Ollama. Ein Vektor-Store lässt sich direkt als Werkzeug an den Agenten hängen. Für die Praxis der Reihe ist das eine solide Grundausstattung.

Gemessen an diesem Überblick werden die Lücken aber genauso deutlich. „Memory" heißt bei n8n Konversations-Historie, nicht Langzeitgedächtnis mit Konsolidierung. Es gibt keinen nativen Knoten, der ältere Verläufe zusammenfasst, das Fenster schneidet hart ab, statt zu verdichten. Es gibt keine Logik fürs Vergessen oder Verfallen (Forgetting, Decay), nur das harte Abschneiden oder vollständige Persistieren. Re-Ranking ist nativ vorhanden, aber auf Cohere beschränkt. GraphRAG fehlt vollständig, n8n macht klassisches Vektor-Retrieval. n8ns In-Memory-Vektorspeicher (der Simple Vector Store) hält die Embeddings nur im Arbeitsspeicher des Prozesses, ohne sie wegzuschreiben. Das genügt, um einen RAG-Ablauf ohne externe Infrastruktur auszuprobieren oder um frisch geholte Dokumente einmalig abzufragen und danach zu verwerfen. Als bleibende Wissensbasis taugt er nicht, denn die Daten gehen bei einem Neustart verloren und können unter Speicherdruck verworfen werden. Simple Memory funktioniert nicht im Queue-Mode, weil nicht garantiert ist, dass jeder Aufruf denselben Worker trifft. Einen Wächter auf dem Schreibpfad, der prüft, was eine KI in den Store ablegt, gibt es ebenfalls nicht.

Keine dieser Lücken ist ein Ausschlusskriterium. Jede lässt sich schließen, mit Bordmitteln oder einem externen Dienst. Genau das ist das Thema des nächsten Artikels.

Nächster Schritt

Damit ist der Überblick komplett: Memory ist eine Architekturentscheidung über vier kognitive Funktionen, das Kontextfenster ist kein Speicher, Retrieval reicht von einfachem RAG bis zum teuren Wissensgraphen, und unter Last zeigen sich vier Schwachstellen, von denen die Schreib-Kontamination am wenigsten beachtet wird. n8n deckt davon die Grundlagen ab und lässt die anspruchsvollen Teile offen. Der nächste Advanced Topic nimmt den Ticket-Triage-Workflow aus Artikel 6 und schließt diese Lücken eine nach der anderen: ein zusammenfassendes Gedächtnis, eine Regel fürs Vergessen, ein eigener Re-Ranker und ein Schreib-Wächter vor dem Store.

← Artikel 6: AI-Klassifikation ohne Cloud