Agent Memory, das sich wirklich erinnert: Knowledge Graphs und Context Assembly

Das Problem: zustandslose Modelle, zustandsbehaftete Konversationen

Ganz direkt gesagt: Ein Sprachmodell hat kein Gedächtnis. Jeder Aufruf ist ein leeres Blatt. Die Illusion eines Systems, das "sich an dich erinnert", ist reines Engineering, das außerhalb des Modells passiert, bevor der Prompt überhaupt abgeschickt wird.

Machst du dieses Engineering falsch, bekommst du die zwei klassischen Fehlerbilder. Entweder vergisst der Agent, was der Nutzer drei Züge vorher gesagt hat, oder du stopfst die komplette Konversationshistorie in jeden Request und siehst zu, wie deine Token-Rechnung und deine Latenz explodieren, während die Relevanz sinkt. Echtes Agent Memory ist die Disziplin, pro Request zu entscheiden, was genau das Modell sehen muss und nichts darüber hinaus.

Memory ist nicht ein Ding, das man einschaltet. Es sind vier verschiedene Mechanismen mit unterschiedlichen Kosten und unterschiedlichen Aufgaben, die zur Request-Zeit in ein einziges Context Window zusammengesetzt werden.

Wir betreiben das in Produktion in Exfinity, unserer mandantenfähigen KI-Commerce-Plattform, in der acht Agenten eine Memory- und Wissensschicht über Tausende Konversationen hinweg teilen. Dieser Guide ist die echte Architektur, kein Spielzeug. Für die übergeordnete Sicht auf agentische Systeme lies unseren Guide zu agentischen KI-Systemen, und dafür, wie Retrieval hineinpasst, unseren Guide zu Enterprise-RAG-Systemen. Das ist Kernarbeit unserer KI-Services.

Wen was interessiert

Vier Arten von Memory

Vor der Architektur kommt das Vokabular. Diese vier Mechanismen erledigen unterschiedliche Jobs, und Produktionssysteme nutzen alle vier.

Der Fehler von Junioren ist, Memory als einen einzigen "Chat-History"-Klumpen zu behandeln. Der Fehler, den Seniors vermeiden, ist, für Kontext zu bezahlen, den das Modell in diesem Zug nicht braucht.

Context Assembly: die sieben Schichten

Jeder Request in Exfinity durchläuft eine Context-Assembly-Pipeline, die ein geordnetes Array von Nachrichten baut, das vor dem Text des Nutzers injiziert wird. Jede Schicht ist konditional. Das ist das Herz des Systems, hier also die komplette Pipeline.

Zwei Designentscheidungen sind hier wichtiger als die Liste selbst.

Erstens: Nicht jede Schicht feuert. Schicht 4 läuft erst, wenn der Graph eines Mandanten genug Nodes hat, um nützlich zu sein, und Schicht 5 greift erst, wenn ein Thread lang genug ist, um eine Zusammenfassung zu brauchen. Du bezahlst nicht für Kontext, den du nicht brauchst.

Zweitens, und das ist die Sicherheitsentscheidung: Schichten, die Daten tragen, die andere Nutzer erzeugt haben, werden nie als Systeminstruktionen injiziert. Plattformregeln und die eigene Nachricht des Nutzers sind die einzigen autoritativen Stimmen. Graph-Insights, kompaktierte Historie, geholte Produkte und geholte Dokumente werden alle als nicht vertrauenswürdige Daten verpackt und in der User-Rolle injiziert, wobei die Fence-Delimiter aus dem Inhalt entfernt werden, damit injizierter Text nicht ausbrechen kann. Warum, dazu kommen wir im Guardrails-Abschnitt zurück.

User message
   │
   ▼
[1] Platform rules      (system, always)
[2] Date context        (system, always)
[3] Tenant persona      (system, if configured)
[4] Graph insights      (untrusted-data, if graph is big enough)
[5] Compacted history   (untrusted-data, if thread is long)
[6] Product context     (system, if product-like query)
[7] Knowledge passages  (untrusted-data, if question-like query)
   │
   ▼
Assembled context ──▶ Agent ──▶ Model

Working Memory: das Template, in das der Agent schreibt

Aktuelle Nachrichten für immer mitzuschleppen ist teuer. Working Memory löst das mit einem strukturierten Template, das der Agent über Züge hinweg liest und beschreibt. Statt "Ich habe 200 Euro für zwei Erwachsene nächsten Samstag" jeden Zug neu aus der rohen Historie zu lesen, extrahiert der Agent das einmal in ein Template und trägt das Template weiter.

<user_context>
preferences:
budget:
travel_dates:
group_size:
interests:
viewed_products:
current_intent:
</user_context>

Wenn der Nutzer Budget und Termine nennt, schreibt der Agent diese Werte in die Felder. Im nächsten Zug wird das Template zurück in den Kontext geladen, sodass sich der Agent erinnert, ohne dass die Originalnachrichten vorhanden sind. Das ist dramatisch günstiger als volle Historie mitzuführen, und es überlebt die Kompaktierung. Agenten, die kein starres Schema brauchen, halten stattdessen einen freien Working-Memory-Block.

Die Designregel: Dauerhafte, strukturierte Fakten gehören in Working Memory, das rohe Nachrichtenfenster übernimmt das unmittelbare Hin und Her. Unser Guide zum KI-Workflow-Design behandelt, wie du entscheidest, was wohin gehört.

Semantic Recall versus Recent Window

Zwei Mechanismen decken die Konversationshistorie ab, getunt pro Agent.

Das Recent Window sind die letzten N Nachrichten, wortwörtlich geladen. Günstig und für den unmittelbaren Austausch immer relevant.

Semantic Recall embeddet die aktuelle Nachricht und durchsucht die ältere Historie des Threads nach semantisch ähnlichen früheren Nachrichten, holt ein paar Treffer plus die Nachrichten drumherum zurück. So erinnert sich ein Agent an etwas, das der Nutzer vor zwanzig Zügen gesagt hat, wenn es wieder relevant wird, ohne alle zwanzig Züge mitzutragen.

Jeder Agent tunt beides unabhängig. Ein Buchungs-Agent hält vielleicht ein kurzes Recent Window und flachen Recall, weil Buchungen kurzfristig sind. Ein Empfehlungs-Agent hält tieferen Recall, weil sich Geschmack über einen längeren Bogen ausdrückt. Der Punkt: Memory-Einstellungen sind pro Rolle, nicht global. Unser Guide zur Multi-Agent-Architektur behandelt, wie spezialisierte Agenten in der Konfiguration auseinanderlaufen.

// Memory-Konfiguration pro Agent: Recent Window + Semantic Recall
const bookingAgent = {
  memory: {
    lastMessages: 15,                       // wortwörtliches Recent Window
    semanticRecall: { topK: 3, messageRange: 2 }, // ähnliche Vergangenheit + Nachbarn
    workingMemory: { enabled: true },
  },
};

const recommendationAgent = {
  memory: {
    lastMessages: 15,
    semanticRecall: { topK: 5, messageRange: 3 }, // tieferer Recall
    workingMemory: { enabled: true },
  },
};

Der Knowledge Graph: Memory über Sitzungen hinweg

Alles bisher ist auf eine Konversation begrenzt. Der Knowledge Graph ist Memory, das die Sitzung überlebt und Muster über jede Interaktion eines Mandanten hinweg hält. Das ist die Schicht, die die meisten Teams überspringen, und hier hört Kontext auf, "was du gerade gesagt hast" zu sein, und wird zu "was hier tendenziell gilt".

Der Graph ist pro Mandant, mit typisierten Nodes und typisierten Edges.

Node-Typen sind unter anderem product, query, response, user, document, tool call, booking und competitor price. Edge-Typen sind unter anderem searched-for, answered-by, booked, viewed, cited, similar-to, asked-about, used-tool und priced-against.

query ──searched_for──▶ product
query ──answered_by──▶ response ──cited──▶ document
user  ──booked──▶ product
user  ──viewed──▶ product
product ──similar_to──▶ product

Write Path. Nach jeder Agent-Antwort zeichnet ein Fire-and-Forget-Job die Interaktion auf: ein Query-Node mit der von personenbezogenen Daten bereinigten Nutzernachricht, ein Response-Node mit der bereinigten Antwort, eine Answered-by-Edge, gewichtet nach Feedback (ein Daumen hoch stärkt sie, ein Daumen runter schwächt sie), und pro erwähntem Produkt ein Product-Node plus eine Searched-for-Edge. Er läuft asynchron, fügt der Antwort also nie Latenz hinzu.

Read Path. Während der Context Assembly (Schicht 4) produziert der Graph Insights erst, wenn er genug Nodes hat, um aussagekräftig zu sein. Zwei Queries laufen parallel: die meistgesuchten Produkte und jüngste Fragen ohne gute Antwort. Daraus wird ein kompakter Untrusted-Data-Block, der dem Agenten sagt, was die Nutzer dieses Mandanten wirklich interessiert.

// Read Path: Insights erst zeigen, wenn der Graph substanziell ist
async function buildGraphInsights(tenantId) {
  const stats = await graph.getStats(tenantId);
  if (stats.totalNodes < GRAPH_MIN_NODES_FOR_INSIGHTS) return null;

  const [popular, unanswered] = await Promise.all([
    graph.getPopularProducts(tenantId, 5),      // meistgesucht
    graph.getUnansweredQuestions(tenantId, 3),  // Lücken zum Schließen
  ]);
  return fenceUntrusted(formatInsights(popular, unanswered));
}

Damit er nicht ewig wächst. Zwei Wartungsjobs sind entscheidend. Edge Decay wendet altersbasierten exponentiellen Zerfall auf Edge-Gewichte an, sodass alte Interaktionen in der Relevanz verblassen, und rechnet bei jedem Lauf vom Initialgewicht neu, ist also idempotent statt kumulativ. Node Purge löscht transiente Nodes jenseits eines Cutoffs und kaskadiert zu verwaisten Edges, während dauerhafte Nodes wie Produkte bestehen bleiben.

weight = initial_weight * exp(-ln(2) / halfLifeDays * ageDays)   # floored at 0.1

Löschung. Bei einem DSGVO-Löschantrag löst der Graph die Query-Nodes eines Nutzers über den Thread auf, folgt den Answered-by-Edges zu deren Response-Nodes und löscht diese Nodes plus jede Edge, die sie berührt. Geteilte Product-Nodes werden nie gelöscht. Gezielte Löschung über alle Memory-Stores ist eine harte Anforderung, kein Nice-to-have, und die Compliance-Seite behandeln wir in unserem Guide zu GDPR und KI.

Confidence und Auto-Learn: Memory, das besser wird

Memory, das nur akkumuliert, ist eine Last. Memory, das besser wird, ist ein Asset. Die Brücke ist ein Confidence Score auf jeder Antwort und ein menschlicher Review-Loop, der Antworten mit niedriger Confidence in neues Wissen verwandelt.

Confidence ist ein gewichteter Verbund aus vier Faktoren.

const composite =
  retrieval * 0.4 + policy * 0.2 + completeness * 0.2 + memory * 0.2;

Wenn eine Antwort unter einem mandantenspezifischen Schwellwert liegt, wird sie als Lernkandidat erfasst und in eine Fehlerklasse eingeordnet: Retrieval Miss, Policy Block, ein Halluzinationssignal wie ein vergangenes Datum, das als Zukunft präsentiert wird, negatives Feedback und so weiter. Ein Mensch prüft den Kandidaten in einem Dashboard. Bei Freigabe wird die Antwort zu einem Wissensdokument formatiert, embeddet und zurück in die Wissensbasis publiziert, sodass dieselbe Frage nächstes Mal eine gute Antwort holt. Der Schwellwert tunt sich sogar selbst: Wenn Reviewer fast alles freigeben, sinkt er, um mehr zu erfassen; wenn sie viel ablehnen, steigt er, um Rauschen zu reduzieren.

Das ist das Human-in-the-Loop-Muster, angewandt auf die Memory-Schicht selbst, und es ist das, was ein degradierendes System von einem trennt, das sich aufbaut. Unser Guide zu KI-Observability behandelt die Metriken, an denen du erkennst, welches von beiden gerade passiert.

Guardrails: Prompt Injection und nicht vertrauenswürdige Daten

Hier ist das Fehlerbild, das Memory einführt: Text, den ein Nutzer gespeichert hat oder der die Kompaktierung überlebt hat, kann versuchen, die Session eines anderen Nutzers zu kapern. Würden geholte Inhalte oder Graph-Insights als Systeminstruktionen injiziert, könnte ein bösartiges Dokument "ignoriere deine Regeln" sagen und würde befolgt.

Die Verteidigung ist eine strikte Trennung. Nur die Plattformregeln und der eigene Request des Endnutzers sind autoritativ. Alles andere, geholte Passagen, Produktdaten, Graph-Insights, kompaktierte Historie, wird als nicht vertrauenswürdige Daten deklariert und in der User-Rolle innerhalb eines Fence injiziert, wobei die Fence-Delimiter aus dem Inhalt entfernt werden, damit der injizierte Text den Block nicht vorzeitig schließen und scheinbar entkommen kann. Er wird als Information zum Abwägen behandelt, nie als Befehle zum Befolgen.

Das wird wichtiger, je mehr Memory wächst, denn die Angriffsfläche von "Text, den andere Leute verursacht haben" wächst mit. Unser Guide zu KI-Governance und unser Guide zu KI-Fehlermodi gehen tiefer auf die Verteidigung agentischer Systeme ein.

Kosten: Memory ist nicht gratis

Jede Schicht, die du hinzufügst, sind Tokens, und Tokens sind Latenz und Geld. Drei Kontrollen halten es im Rahmen.

Kompaktierung fasst ältere Nachrichten zusammen, sobald ein Thread lang wird, ersetzt rohe Historie durch eine kompakte strukturierte Zusammenfassung und hält das Token-Budget flach, während Konversationen wachsen. Prompt Caching liefert den statischen System-Prefix bei wiederholten Aufrufen aus dem Provider-Cache, du zahlst also nicht jeden Zug neu für dieselben Regeln. Und harte Obergrenzen pro Zug für Reasoning-Schritte, Tool-Aufrufe und Output-Tokens verhindern, dass ein einzelner Zug davonläuft.

Kosten- und Latenz-Trade-offs über den ganzen Stack behandeln wir in unserem Guide zu KI-Latenz und -Genauigkeit.

Loslegen

Memory zu einem Agenten hinzufügen, geordnet nach Ertrag:

1. Recent Window zuerst. Trage die letzten N Nachrichten mit. Das allein lässt einen Agenten kohärent wirken.
2. Working Memory als Nächstes. Füge ein strukturiertes Template für dauerhafte Fakten hinzu. Günstig, hohe Wirkung.
3. Semantic Recall, wenn Threads lang werden. Hole relevante ältere Nachrichten zurück statt alle.
4. Kompaktierung, wenn die Kosten beißen. Fasse alte Historie zusammen, sobald Threads lang sind.
5. Ein Knowledge Graph, wenn du Volumen hast. Lohnt sich erst, wenn genug Interaktionen da sind, damit Muster entstehen.

Bau den Graph nicht zuerst. Er verdient seinen Platz erst bei Volumen. Unsere Methodik ist um genau diese Art gestufter Lieferung gebaut, und unsere Teams für Individualsoftware und Consulting bauen diese Schichten mit Kunden. Starte über Kontakt oder hol dir ein Angebot.

Wie das typischerweise schiefgeht

1. Volle Historie jeden Zug dumpen. Kosten und Latenz explodieren, Relevanz sinkt. Assemblieren, nicht dumpen.
2. Globale Memory-Einstellungen. Verschiedene Agenten brauchen verschiedene Windows und Recall. Pro Rolle tunen.
3. Geholten Text als Systeminstruktionen injizieren. Das ist ein Prompt-Injection-Loch. Als nicht vertrauenswürdige Daten fencen.
4. Ein Graph ohne Decay oder Purge. Er wächst unbegrenzt, und altes Rauschen ertränkt das Signal. Wartungsjobs hinzufügen.
5. Kein Löschpfad. Wenn du das Gedächtnis eines Nutzers nicht löschen kannst, kannst du keine GDPR-Anfrage erfüllen. Löschung von Anfang an einplanen.
6. Akkumulieren ohne Verbessern. Füge einen Confidence Score und einen Review-Loop hinzu, sonst wird das System nur größer, nicht besser.

Wer das baut

Oronts ist ein gründergeführtes Softwareunternehmen in München. Refaat Al Ktifan, unser Gründer und Solution Architect, führt ein Senior-Team über Backend, Data und KI hinweg. Die Architektur in diesem Guide ist die echte Memory-Schicht hinter Exfinity, die wir gegen uns selbst betreiben, bevor wir diese Muster zu Kunden bringen. Wir designen die Kontext-Pipeline, bauen die Memory- und Graph-Schichten und übergeben dir ein System, das du betreiben und auditieren kannst. Das ganze Bild findest du auf unseren Seiten zu Services und Lösungen.

Takeaways

• Ein Modell hat kein Gedächtnis. Alles ist Assembly, die vor dem Prompt passiert.
• Nutze alle vier Mechanismen: Recent Window, Semantic Recall, Working Memory und einen Knowledge Graph.
• Assembliere Kontext in konditionalen Schichten und injiziere Daten anderer Nutzer nie als Systeminstruktionen.
• Ein Knowledge Graph gibt dir Memory über Sitzungen hinweg, braucht aber Decay, Purge und einen Löschpfad.
• Füge einen Confidence Score und einen menschlichen Review-Loop hinzu, damit Memory besser wird statt nur zu wachsen.

Das beste Agent Memory ist unsichtbar. Der Nutzer fühlt sich verstanden, die Token-Rechnung bleibt flach, und ein Regulator kann zusehen, wie die Daten eines Nutzers auf Anfrage gelöscht werden. Das ist Engineering, keine Magie.

Du baust einen Agenten, der sich erinnern muss, sicher und günstig? Erzähl uns davon über Kontakt oder hol dir ein kalkuliertes Angebot.