Kontext-Substrate für langläufige Agenten

Produktionsagenten profitieren oft mehr von zuverlässigem Context Retrieval über Sitzungen hinweg als von persistentem Memory. Das sind zwei verschiedene Produkte.

Wer in diesem Jahr Zep, Mem0 oder Letta evaluiert, kauft in einem Markt ein, der zwei verschiedene Produkte unter einem einzigen Begriff zusammengefasst hat.

Der Wunsch, dass Agenten über Sitzungen hinweg klüger werden, ist berechtigt. Das Problem: Die Hälfte der Tools auf der Shortlist wurde für ein anderes Problem entwickelt, nämlich Fact Recall in einem einzelnen Gespräch, nicht kumulatives Wissen über Monate hinweg. Dieser Artikel trennt die beiden Lager, zeigt auf, welches der Agent tatsächlich benötigt, und benennt die Marktsignale, die die meisten Käufer übersehen.

• Der Markt sind zwei Märkte. Lager 1 optimiert für *Recall*. Lager 2 optimiert für *Kumulation*. Die meisten Käufer vermischen beides.
• Zep hat sich neu positioniert. 2026 wechselte das Unternehmen seine Positionierung von "Memory" zu context engineering. Das ist das deutlichste öffentliche Signal in diesem Bereich.
• Zilliz hat MemSearch veröffentlicht. Ein Vektordatenbank-Unternehmen hat ein System ausgeliefert, bei dem Markdown-Dateien der eigenen Vektordatenbank vorgelagert sind.
• Kumulative Agenten brauchen Lager 2. Soll ein Agent seine Arbeit über Wochen und Monate verbessern, ist Recall-Infrastruktur nur eine Komponente davon.
• Beide Systeme zu stapeln ist kostspielig. Zwei Systeme mit überlappenden Schreibpfaden erzeugen widersprüchliche Memories, die sich gegenseitig korrumpieren.

Der Markt verkauft Recall. Ihre Agenten brauchen wahrscheinlich Kumulation.

Ein Blick auf GitHub: Über 450 Repositories sind mit `agent-memory` getaggt, über 460 mit `context-management`. Fast keines davon zieht eine klare Trennlinie zwischen beiden Konzepten.

Diese Unschärfe ist das Kernproblem des Marktes. Memory klingt nach einer einzigen Sache, also behandeln Käufer es als eine Sache, also verkaufen Anbieter es als eine Sache. Das Ergebnis: Entwickler zahlen für Vektor-Infrastruktur, die sie anschließend trotzdem in Markdown nachbauen müssen.

Die Unterscheidung verändert, was man kauft. Lager 1 fragt *Was soll die KI sich merken?* und liefert eine Datenbank. Lager 2 fragt *In welchem Kontext soll die KI arbeiten?* und liefert ein Substrat. Beide haben ihren Nutzen. Sie lösen unterschiedliche Probleme.

Wer Agent-Infrastruktur für ein Unternehmen auswählt, das darauf angewiesen ist, dass der Agent über Monate hinweg tatsächlich besser wird, findet bei webvise die richtige Begleitung, um die passende Schicht zu definieren, bevor ein Jahresvertrag unterzeichnet wird.

Lager 1: Memory Backends (optimiert für Recall)

Lager-1-Tools beherrschen eine Sache gut. Sie nehmen ein Gespräch, extrahieren die relevanten Fakten, speichern sie in einer Vektordatenbank und rufen sie ab, wenn das nächste Gespräch sie benötigt. Der Kreislauf ist einfach.

Das ist es, was die meisten Menschen meinen, wenn sie "Agent Memory" sagen. Dieses Lager hat die meisten GitHub-Sterne und ist das, auf das Käufer standardmäßig zurückgreifen, weil das Versprechen eingängig ist: Der Chatbot merkt sich, dass der Nutzer in San Francisco lebt.

Lager 1 ist die richtige Wahl für Chatbots, Persistenz von Nutzerpräferenzen und Fact Recall mit sub-200ms Latenz. Es ist die falsche Wahl für Agenten, die den *Zustand* laufender Arbeiten über fünf Projekte, drei Tools und zwei Monate hinweg verstehen müssen.

Die Grenze ist architektonischer Natur, kein Implementierungsproblem. Eine Vektordatenbank liefert den nächsten Treffer zu einer Abfrage. Sie sagt nicht, was sich seit letzter Woche verändert hat, warum, oder wie das die bevorstehende Entscheidung beeinflusst.

Lager 2: Kontext-Substrate (optimiert für Kumulation)

Lager 2 dreht den Kreislauf um. Anstatt Fakten aus Gesprächen in eine Datenbank zu extrahieren, liest der Agent strukturierte, menschenlesbare Kontextdateien, arbeitet darin und schreibt zurück. In der nächsten Sitzung ist der Kontext reicher. Nichts wird "extrahiert".

Das ist das Muster, das Andrej Karpathy als LLM Wiki beschrieben hat: eine persönliche Wissensbasis, die das Modell einmal aufbaut und aktuell hält, anstatt bei jeder Abfrage Antworten aus Chunks neu abzuleiten. Die entscheidende Eigenschaft ist Kumulation. Der Kontext wird durch Nutzung besser.

Lager 2 ist die richtige Wahl, wenn ein Agent kontinuierlich läuft, wenn mehrere Tools oder Agenten in dieselbe Wissensbasis schreiben, oder wenn das System über Wochen und Monate nachweislich besser werden soll, ohne die Pipeline jedes Mal neu aufzubauen.

Der einfachste Test: Muss der Agent wissen, was letzten Dienstag passiert ist, oder muss er die *Struktur* des aktuellen Geschäfts kennen? Letzteres ist ein Lager-2-Problem.

Das Rebranding, das alles erklärt

Die Marktsignale sind eindeutig. Zwei öffentliche Schritte, beide von Unternehmen, die Memory verkaufen, zeigen, welches Lager die Oberhand gewinnt.

Zep bezeichnete sich früher als Memory-Unternehmen. 2026 wechselte es seine Positionierung zu context engineering. Ein finanziertes Unternehmen in diesem Bereich ändert seine Positionierung nicht zum Spaß. Der Grund: Die zahlungskräftigsten Käufer hatten aufgehört, nach Memory zu fragen, und begannen, nach Kontext zu fragen, der sich kumulativ aufbaut.

Zilliz, das Unternehmen hinter Milvus, hat MemSearch veröffentlicht. MemSearch ist ein System, bei dem Markdown-Dateien die Quelle der Wahrheit sind und die eigene Vektordatenbank von Zilliz nachgelagert als Zugriffsschicht sitzt. Das ist ein Vektordatenbank-Unternehmen, das öffentlich einräumt, dass Markdown den Vektoren vorgelagert gehört.

"Context engineering" wird sich voraussichtlich im kommenden Jahr als Standardbegriff für diese Schicht der Agent-Infrastruktur durchsetzen. Wer Produktseiten mit dieser Substitution liest, erkennt die tatsächliche Positionierung sofort.

Welches Lager wird tatsächlich benötigt

Hier ist der Entscheidungsrahmen, auf praktische Regeln reduziert.

Die meisten geschäftsorientierten Agenten landen in Lager 2. Wer einen Agenten für Sales-Recherche, Kundenbetreuung, Content-Operations oder andere Bereiche einsetzt, in denen der Output über die Zeit schärfer werden soll, kauft Lager 1 bestenfalls als Komponente, nicht als System.

Der teure Fehler ist die umgekehrte Variante. Ein Customer-Support-Bot auf einem schweren Lager-2-Substrat wirkt langsam und überdimensioniert. Das Lager muss zur Aufgabe passen, nicht umgekehrt.

Kaufkriterien

Drei konkrete Empfehlungen vor der Vertragsunterzeichnung.

• Zuerst mit Markdown prototypisieren. Vor dem Kauf eines Memory-Produkts sollte der Use Case auf einem einfachen Markdown-Substrat plus Retrieval-Schicht erprobt werden. Löst dieser Prototyp das Problem, war Lager 1 von Anfang an überflüssig.
• Anbieter auf Kumulation bewerten, nicht auf Recall. Recall-Benchmarks wie LongMemEval beschreiben Lager 1. Sie sagen nicht, ob das System in Woche 12 klüger ist als in Woche 1. Evaluierungen sollten genau das direkt messen.
• Einen einzigen Schreibpfad wählen. Wer Lager 1 und Lager 2 stapelt, muss definieren, welche Schicht die Schreibrechte besitzt. Zwei Systeme mit überlappenden Schreibzugriffen führen zu widersprüchlichen Fakten, die sich gegenseitig korrumpieren.

Die KI-Wissensschicht ist die Infrastruktur, auf der das aufbaut, und die meisten Unternehmen brauchen keine neue Vektordatenbank, um eine zu bekommen. Sie brauchen das richtige Substrat, das richtige Schema und die Disziplin, es sich kumulieren zu lassen.

Wer Agent-Infrastruktur plant und vor der Entscheidung eine zweite Meinung sucht: webvise hilft Unternehmen, Agent-Wissensschichten zu definieren, die sich kumulativ aufbauen. Kontakt aufnehmen, bevor ein Lager gewählt wird.