Ich habe letzte Woche den Thread von Sarah Wooders gesehen und war sofort mit der Hälfte davon einverstanden.

Wooders, Mitschöpfer von MemGPT (jetzt Letta), [argumentierte, dass Speicher kein Plugin, sondern der Kabelbaum ist](https://x.com/sarahwooders/status/2040121230473457921). Der Harness trifft unsichtbare Entscheidungen, die kein externes Tool kontrollieren kann: Was übersteht die Komprimierung, wie wird der Kontext geladen, ob der Agent seine eigenen Anweisungen ändern kann. „Die Bitte, den Speicher an einen Agentenkabelbaum anzuschließen, ist so, als würde man darum bitten, beim Fahren ein Auto anzuschließen.“

Der Rahmen lässt sich gut weitergeben. Ich höre die Wiederholung der Kabelbaumleine immer wieder als festen Hintergrund und nicht als Anspruch auf Inspektion. Das liegt zum Teil daran, dass die Hälfte, der ich zustimme, richtig ist.

## Die unsichtbaren Entscheidungen sind real

[Claude Code verfügt über eine in den Kabelbaum integrierte mehrstufige Speicherhierarchie](https://docs.anthropic.com/en/docs/claude-code/memory): CLAUDE.md, Sitzungsstatus, Komprimierungsregeln, Systemnachrichteninjektion. Wenn [Claude Code](https://docs.anthropic.com/en/docs/claude-code/best-practices) eine 100.000-Token-Konversation auf 20.000 komprimiert, entscheidet der Kabelbaum, was überlebt. Kein externes Tool kann diese Entscheidung replizieren oder außer Kraft setzen.

Ahmed Kidwai, der [Virtual Context](https://github.com/virtual-context/virtual-context) erstellt, beschrieb die gleiche Struktur vom Benutzersitz aus in [KI verbringt den größten Teil ihres Lebens damit, über ihr Leben zu lesen](https://open.substack.com/pub/virtualcontext/p/ai-spends-most-of-its-life-reading). In jeder Runde kann der gesamte Thread erneut abgespielt werden, sodass die meisten Eingabetoken dazu verwendet werden, noch einmal zu lesen, was bereits passiert ist. Wenn das Fenster gefüllt ist, ersetzt die Komprimierung den Rohverlauf durch eine Zusammenfassung. Sie erhalten keine Einzelpostenquittung darüber, was verschwunden ist.

Innerhalb einer einzelnen Sitzung bilden die Entscheidungen des Harness darüber, was in das Kontextfenster gelangt, was zusammengefasst wird und was gelöscht wird, das effektive Gedächtnissystem. Wooders hat da recht.

## Das Argument geht von einem Kabelbaum aus

Der Thread kommt zu dem Schluss, dass Sie einen Memory-First-Kabelbaum verwenden sollten. Diese Schlussfolgerung erfordert, dass Sie in einem solchen Fall agieren.

Ich tu nicht. Ich verwende Cursor als meine primäre Schnittstelle, Claude Code für bestimmte Aufgaben, ChatGPT für Konversationen und benutzerdefinierte Skripte für die Automatisierung. Das sind vier Geschirre, von denen jedes seine eigenen unsichtbaren Entscheidungen darüber trifft, woran man sich erinnert.

Die Leute, mit denen ich spreche und die mit Agenten bauen, verwenden drei bis fünf Tools. Jeder komprimiert sich anders, lädt den Kontext anders, speichert den Zustand anders. Der Benutzer wird zur menschlichen Synchronisierungsebene zwischen allen.

Das Hinzufügen von mehr im Kabelbaum eingebettetem Speicher macht dies schlimmer, nicht besser. Jedes Tool erhält einen besseren internen Speicher. Keiner von ihnen stimmt zu.

## Drei Bedenken, nicht eines

Wooders fasst Kontextfensterverwaltung, Sitzungsstatus und dauerhaften Zustand in einem Konzept zusammen, das sie „Speicher“ nennt. Diese sind architektonisch unterschiedlich.

**Kontextfensterverwaltung**: Was passt gerade in die Eingabeaufforderung, was wird komprimiert, was das Modell in diesem Zug sieht. Dies ist ein Problem mit dem Kabelbaum. Wooders hat recht.

**Sitzungsstatus**: Bleibt innerhalb einer Konversation bestehen. Dies ist auch ein Problem mit dem Kabelbaum.

**Dauerhafter Zustand**: Bleibt über Sitzungen, Tools und Agenten hinweg bestehen, mit Herkunft und Versionierung. Das ist Infrastruktur, kein Kabelbaum.

Kein Kabelbaum bietet einen deterministischen, schemagebundenen, nur anfügbaren, plattformübergreifenden Zustand mit Herkunft. Kontextmanagement ist treibend. Dauerhafter Zustand sind die Navigationsdaten. Es informiert über das Fahren, gehört aber nicht in den Antriebsstrang.

## Sogar der Kontext kann externalisiert werden

Kidwais [Virtual Context](https://github.com/virtual-context/virtual-context) ist ein Proxy, der zwischen Ihrem Client und der Upstream-LLM-API sitzt. Der Client legt ein 20-Millionen-Token-Kontextfenster fest. Das tatsächliche Fenster des Modells beträgt 200 KB. Virtual Context komprimiert, indiziert und blättert zwischen ihnen. Eine 937.000-Token-Claude-Code-Nutzlast mit 52 Toolketten reduziert sich auf etwa 65.000 kuratierte Signale.

Bei [LongMemEval](https://github.com/virtual-context/virtual-context#benchmark-results) erzielte Virtual Context eine Genauigkeit von 95 % gegenüber 33 % für Claude Sonnet 4.5 mit vollständigem Rohkontext und zum halben Preis. Der Proxy funktioniert mit Claude Code, Cursor, OpenClaw oder jedem Client, der eine Basis-URL akzeptiert. Mit VCATTACH können zwei Clients plattformübergreifend dieselbe komprimierte Wissensdatenbank gemeinsam nutzen.

Der Mechanismus ist wichtig. VC umgeht den Kabelbaum nicht. Der Harness trifft weiterhin seine eigenen Entscheidungen zur Komprimierung und Kürzung und erstellt die API-Anfrage. VC fängt diese Anfrage stromabwärts über eine Basis-URL-Umleitung ab. Wenn der Harness den Konversationsverlauf kürzt, erkennt VC die Kürzung und stellt die Daten aus seinem eigenen dauerhaften Speicher wieder her. Was das Modell erreicht, ist das kuratierte Fenster von VC, nicht die Rohausgabe des Kabelbaums.

Wooders hat Recht, dass kein externes Tool die internen Entscheidungen des Kabelbaums kontrollieren kann. Aber ein Proxy, der zwischen dem Kabelbaum und der API sitzt, kann diese Entscheidungen beobachten und sie teilweise rückgängig machen. Der Harness sendet nach seiner eigenen Verdichtung 937.000 Token. VC sendet 65.000 kuratierte Signale an das Modell. Der Kabelbaum führt weiterhin die Werkzeugschleife und den Agenten aus. Die Schicht, die darüber entscheidet, was das Modell tatsächlich sieht, liegt draußen.

Damit bleiben drei Schichten übrig, nicht zwei. Der Harness führt den Agenten aus. Zwischen dem Harness und der API kann eine optionale Kontextverwaltungsschicht liegen. Und unter allem liegt eine dauerhafte Zustandsschicht, die das Wahre beibehält, unabhängig davon, wie der Kontext einer Sitzung verwaltet wird.

## Kontrolle versus Wert

Ein externes Tool kann die Verdichtungsentscheidungen des Kabelbaums nicht steuern. WAHR. Die Frage ist jedoch nicht, ob eine Zustandsschicht die Verdichtung steuert. Es geht darum, ob es einen Mehrwert bietet, den der native Speicher des Kabelbaums nicht bietet.

Das meiste kabelbaumeigene Gedächtnis ist kurzlebig. Letta ist die Ausnahme: Es behält den Speicher sitzungsübergreifend bei. Aber selbst Lettas Gedächtnis ist werkzeugspezifisch, nicht portierbar und nicht deterministisch. Der Agent entscheidet über LLM-gesteuerte Toolaufrufe, was wann gespeichert werden soll, sodass dieselbe Konversation unterschiedliche Speicherzustände erzeugen kann. Der Cursor kann es nicht lesen. Claude Code kann es nicht lesen. Eine dauerhafte Zustandsschicht ist plattformübergreifend, deterministisch, versioniert und bis zur Quelle rückverfolgbar.

Sie müssen das Geschirr nicht kontrollieren, um wertvoll zu sein. Sie müssen die Entscheidungen des Geschirrs überleben. Der dauerhafte Status „Nur anhängen“ bleibt konstruktionsbedingt bestehen. Wenn ein Kabelbaum den Kontext komprimiert, enthält die Statusebene den vollständigen Datensatz. Wenn Sie morgen ein anderes Tool öffnen, enthält die Statusebene das, was Sie gestern gespeichert haben.

## Auslösen versus Transport

Nicolò Boschi (Hindsight/Vectorize) [stimmte mit Wooders überein](https://x.com/nicoloboschi/status/2042145292632379598): „Die Verwendung des Speichers über MCP und die Hoffnung, dass das Modell Informationen aus dem Speicher speichert und durchsucht, ist hoffnungslos.“ Die Sorge ist real. Wenn das Modell entscheiden muss, wann gespeichert und abgerufen werden soll, kann es das Speichern vergessen. Es kann den Abruf überspringen, wenn es darauf ankommt.

Anstelle von MCP verwendet Hindsight [Hooks](https://docs.anthropic.com/en/docs/claude-code/hooks): Skripte, die automatisch bei Lebenszyklusereignissen wie Sitzungsstart, Eingabeaufforderungsübermittlung oder Tool-Abschluss ausgeführt werden. Kein LLM entscheidet, ob sie entlassen werden. Das Claude Code-Plugin von Hindsight verwendet vier Lifecycle-Hooks, um jede Konversation automatisch aufzubewahren und bei jeder Eingabeaufforderung automatisch abzurufen. Es funktioniert.

Bei diesem Argument werden jedoch zwei Dinge miteinander vermengt: wie das Gedächtnis ausgelöst wird und wo es lebt.

Die Hooks von Hindsight rufen die Hindsight-API auf. Sie schreiben nicht in den integrierten Speicher des Kabelbaums. Die Haken sind der Auslöser. Der externe Server ist der Speicher. Diese Trennung ist die gesamte Architektur. Ein Hook, der in den nativen Speicher von Claude Code schreibt, würde dieselben Einschränkungen erben: kurzlebig, nicht portierbar, morgen für Cursor unsichtbar.

Haken lösen das Auslöseproblem. Sie lösen das Speicherproblem nicht. Jedes langlebige Speichersystem benötigt beides.

Haken sind weit verbreitet, jedoch nicht überall erhältlich. Claude Code verfügt über ein Plugin-System mit mehr als 12 Ereignissen. Cursor verfügt über Hooks.json mit mehr als 14 Ereignissen in der Betaversion. OpenCode verfügt über mehr als 20 Ereignisse, einschließlich Komprimierungskontrolle und System-Prompt-Injection. Codex verfügt über Sitzungs-Hooks mit Hooks auf Tool-Ebene in der Entwicklung. ChatGPT und die Claude-Web-App bleiben nur MCP. Für genau diese Fälle stellt Hindsight selbst einen MCP-Server bereit.

Die Antwort lautet: Hooks, wo verfügbar, MCP, wo nicht, wobei beide auf die gleiche dauerhafte Zustandsschicht unter jedem Kabelbaum schreiben. „MCP ist hoffnungslos“ ist eine Aussage über die Auslösezuverlässigkeit, nicht darüber, wo die Erinnerung leben sollte.

## Die Schichten ergänzen sich

Fünf Kabelbäume, die fünf verschiedene Komprimierungs- und Kontextentscheidungen treffen, erzeugen fünf verschiedene Versionen dessen, was der Agent weiß. Die „Fahr“-Analogie funktioniert für das Kontextmanagement. Es geht kaputt, wenn Sie fünf Autos fahren und für alle Autos konsistente Navigationsdaten benötigen.

Kontextmanagement und dauerhafter Zustand stehen nicht im Wettbewerb. Ein Kabelbaum betreibt den Agenten und die Werkzeugschleife. Eine integrierte oder externe Kontextebene verwaltet, was das Modell in jeder Runde sieht. Eine Statusebene verwaltet, was über Sitzungen und Tools hinweg wahr ist. Kein Kabelbaum oder Kontext-Proxy bietet überprüfbare Wahrheit, Herkunft, Determinismus, Schemavalidierung oder werkzeugübergreifenden Zugriff. Das Argument für einen in Kabelbäume eingebetteten Speicher ist gleichzeitig das Argument für eine gemeinsame Zustandsschicht unter jedem Kabelbaum.

## Was ich baue

Ich baue [Neotoma](https://neotoma.io), eine strukturierte Speicherschicht, die unter jedem Kabelbaum lebt: Entitätsauflösung, Zeitpläne, Herkunft, Determinismus, plattformübergreifender Zugriff.

Diese Threads haben das, was ich als nächstes baue, verändert. Ich hatte MCP als einzige Integrationsoberfläche behandelt. Jetzt füge ich Hooks als Lebenszyklus-Erweiterungsebene hinzu. MCP bleibt die primäre Agentenschnittstelle.

Die Trennung ist bewusst. MCP ist Eigentümer des Agentenvertrags: Anweisungen, die einmal zu Beginn der Sitzung geladen werden, strukturierte Speichertools, die der Agent mit vollem Kontextbewusstsein aufruft. Hooks besitzen den Harness-Vertrag: Lebenszyklusereignisse, die der Agent nicht kontrolliert. Ein „UserPromptSubmit“-Hook ruft relevante Entitäten automatisch ab, bevor der Agent jede Eingabeaufforderung sieht. „PostToolUse“-Hooks erfassen alle Dateibearbeitungs- und Shell-Befehle als Beobachtungen. Ein „Stop“-Hook hält die Rohkonversation bestehen, wenn der eigene Abschlussspeicher des Agenten übersehen wurde. Ein „PreCompact“-Haken beobachtet, was das Geschirr entsorgen wird.

Das Ergebnis ist eine Zuverlässigkeit, die unterhalb der MCP-Qualitätsobergrenze liegt. Ohne Haken funktioniert MCP wie heute. Ohne MCP bieten Hooks eine Rohbeobachtungserfassung, aber keine strukturierte Entitätsextraktion. Beides zusammen sorgt für deterministisches Abrufen, passive Beobachtung, Verdichtungsbewusstsein und Unfallwiederherstellung.

Dies unterscheidet sich vom Ansatz von Hindsight. Hindsight erfasst Rohtranskripte über Hooks und führt dann einen separaten serverseitigen LLM aus, um Entitäten zu extrahieren. Das bedeutet, dass ein zweites Modell beurteilt, worauf es ankommt, mit zusätzlichen Kosten und Latenz pro Vorgang. Neotoma behält die agentengesteuerte Entitätsextraktion bei: Dasselbe Modell, das die Konversation versteht, führt die Extraktion ohne LLM-Grenzkosten durch. Hooks stellen die darunter liegende Zuverlässigkeitsschicht dar, nicht die Intelligenz.

Als nächstes folgen Plugins für Claude Code, Cursor, OpenCode und Codex. Die Haken schreiben an Neotoma, nicht an den eingebauten Speicher des Gurtzeugs. Sie alle erreichen dieselbe dauerhafte Zustandsschicht, wo verfügbar über Hooks und wo nicht über MCP.

Wooders hat Recht, dass das Geschirr den Kontext besitzt. Boschi hat recht, wenn es darum geht, dass Haken MCP hinsichtlich der Auslösezuverlässigkeit schlagen. Kidwai zeigt, dass sogar Kontextmanagement externalisiert werden kann. Die Frage, die keiner von ihnen beantwortet, ist, wem die Wahrheit gehört, wenn man fünf Kabelbäume nutzt. Diese Antwort muss ihnen allen zugrunde liegen.