Mehrjährige KI-Gespräche als Timeline: Entwickler kombiniert Codex und DOT

Mehrjährige KI-Gespräche als durchsuchbare Timeline rekonstruiert

Ein Entwickler arbeitet nach eigenen Angaben seit etwa Juni mit OpenAI Codex daran, mehrere Jahre seiner KI-Konversationen zu rekonstruieren. Das System DOT habe diese Rekonstruktion erst zu einer praktischen Alltagserfahrung gemacht: Das rekonstruierte Material einschließlich Markdown werde in DOTs persistentem Speicher abgelegt und benötige wenig Platz. So lasse sich die Entwicklung von Projekten oder Beziehungen über die Zeit nachvollziehen – mit Höhen und Tiefen, was funktionierte und was nicht, und wie sich das eigene Denken veränderte. Dabei würden beide Seiten der Konversation berücksichtigt, einschließlich Ratschlägen, Fehlern und Korrekturen der KI. Der Autor könne Fragen stellen wie 'Womit war ich diesen Monat in den letzten drei Jahren beschäftigt?' und Muster in der eigenen Arbeitsweise erkennen; selbst obskure Ein-Wort-Kurzprompts würden überraschend gut verstanden. Eine frühere Version in Codex sei nur teilweise als Alltagserfahrung vorhanden gewesen, ein Standalone-Plugin weniger geeignet für diese Kontinuität.

Der Beitrag selbst macht keine Angaben zum Speicherformat oder zur Kompression von DOT. In vergleichbaren persistenten Speichersystemen wie LangGraph werden Erinnerungen als JSON-Dokumente unter benutzerdefinierten Namespaces abgelegt, was eine strukturierte und indizierbare Ablage ermöglicht. Die geringe Platzbeanspruchung könnte auf die Speicherung von reinem Text (Markdown) und möglicherweise Kompression oder Deduplizierung zurückzuführen sein; konkrete technische Details zu DOT sind jedoch nicht dokumentiert. Die Rekonstruktion erlaubt es, langfristige Entwicklungen sichtbar zu machen, die sonst in einzelnen Chatverläufen verborgen blieben.

Codex und DOT: Agentisches Coding trifft persistenten Speicher

OpenAI Codex ist ein agentisches Coding-Tool, das als Open-Source-CLI, Desktop-App für macOS und Windows, IDE-Erweiterung für VS Code und JetBrains sowie als Cloud-Agent in ChatGPT verfügbar ist. Es klont Repositories in isolierte Umgebungen, liest den Code, nimmt Änderungen vor, führt Tests aus und liefert Diff und Terminal-Logs. Für Langzeitgedächtnis in agentischen Systemen bieten LangGraph und LangMem Bausteine: LangGraph speichert Langzeiterinnerungen als JSON-Dokumente in einem Store, organisiert unter benutzerdefinierten Namespaces. Jedes Dokument ist unter einem Namespace abgelegt, der ähnlich wie ein Ordner fungiert und es erlaubt, Erinnerungen nach Anwendung, Nutzer oder Thema zu trennen. Die Dokumente enthalten typischerweise Schlüssel-Wert-Paare mit den gespeicherten Informationen; die genaue Struktur ist flexibel und anwendungsspezifisch.

LangMem stellt Werkzeuge zur Extraktion, Konsolidierung und Suche von Langzeitgedächtnis bereit. Es bietet eine Core Memory API, die mit beliebigen Speichersystemen funktioniert, sowie native Integration mit LangGraphs Langzeitgedächtnis-Store. Im „Hot Path“ kann der Agent während einer Konversation über Tools Erinnerungen aufzeichnen oder durchsuchen. Zusätzlich existiert ein Hintergrund-Manager, der automatisch aus den Interaktionen wichtige Informationen extrahiert, diese mit bestehenden Erinnerungen konsolidiert und den Store aktualisiert. Die Extraktion erfolgt durch einen LLM-Aufruf, der aus dem Gesprächsverlauf relevante Fakten identifiziert; die Konsolidierung führt diese Fakten mit vorhandenen Erinnerungen zusammen, um Duplikate zu vermeiden und Widersprüche aufzulösen. LangGraph unterstützt verschiedene Backends, etwa InMemoryStore für Tests oder PostgreSQL für Produktion. Im beschriebenen Fall dient DOT als persistenter Speicher, in dem das rekonstruierte Material abgelegt wird; wie genau dieser Speicher technisch umgesetzt ist, geht aus dem Community-Beitrag nicht hervor. Die Kombination aus Codex als Werkzeug zur Rekonstruktion und einem persistenten Speicher wie DOT zeigt, wie agentische Systeme Langzeitkontext nutzbar machen können.

Datenschutzrisiken bei persistentem Chatbot-Gedächtnis

Persistente Chatbot-Gedächtnisse werfen erhebliche Datenschutz- und Sicherheitsfragen auf. Memory Poisoning ist eine Form von Prompt Injection, die Sitzungsgrenzen überlebt: Ein Angreifer kann versuchen, über manipulierte Eingaben in einer Konversation das System dazu zu bringen, schädliche Inhalte als wichtige Erinnerung zu speichern. Dies kann direkt über den Chat erfolgen oder indirekt, indem der Agent Inhalte aus externen Quellen (z. B. Webseiten, Dokumente) verarbeitet, die bösartige Anweisungen enthalten. Sobald diese Inhalte im Speicher abgelegt sind, werden sie bei jeder zukünftigen Interaktion vom Agenten gelesen und können dessen Verhalten steuern, etwa zur Exfiltration von Daten oder zur Ausführung unerwünschter Aktionen. Dokumentierte Prompt-Injection-Angriffe haben gespeicherte Erinnerungen als dauerhafte, sitzungsübergreifende Exfiltrationskanäle genutzt.

Zu den Schutzmechanismen gehören die Sanitisierung von Eingaben, der Ausschluss von System- und Entwicklernachrichten aus der Extraktion (wie bei Codex CLI), die Überwachung des Speichers auf ungewöhnliche Einträge, Zugriffskontrollen auf den Speicher, regelmäßige Audits und die Implementierung eines Rechts auf Löschung, das auch abgeleitete Daten wie Embeddings und Zusammenfassungen umfasst. Die DSGVO klassifiziert persistente Verhaltensprofile als zustimmungspflichtig, doch das Recht auf Löschung kollidiert mit Speicherarchitekturen, die Daten über Embeddings, Vektordatenbanken und abgeleitete Zusammenfassungen verteilen – viele Anbieter können eine Löschung nicht nachweisen. Das Löschen einer Konversation in der Benutzeroberfläche garantiert nicht die Löschung im System; gesetzliche Aufbewahrungspflichten und technische Undurchsichtigkeit können dem entgegenstehen. In den USA gibt es kein Bundesgesetz zu KI-Datenschutz, sondern einen Flickenteppich aus Landesgesetzen; in der EU traten Transparenzpflichten des AI Act Anfang August dieses Jahres in Kraft. Machine Unlearning, der vorgeschlagene technische Ausweg, ist auf produktiven LLMs bislang nicht nachgewiesen. Für Entwickler bedeutet das: Wer persistente Speicher einsetzt, muss Löschkonzepte, Zugriffskontrollen und Schutz gegen Injection von Anfang an mitdenken.

Forschung: Memory-Systeme nicht immer besser als native Harness

Die Forschung zeigt, dass zusätzliche Memory-Systeme nicht immer besser sind als das native Gedächtnis des Harness. Das System SCLATE, ein Substrat für kontinuierliches Lernen von Agenten, verwendet einen gemeinsamen Event-Scheduler, in den sowohl Benchmarks als auch Agenten ihre Ereignisse über einen Adapter einfügen. Eine hybride simulierte Uhr lässt die Zeit in Echtzeit vergehen, während der Agent arbeitet, überspringt aber Leerlaufphasen, sodass ein Monatsszenario in Stunden komprimiert wird. SCLATE dient auch als Rollout-Engine, die Harness und Memory unverändert ausführt und dabei die Tokens und Log-Wahrscheinlichkeiten jedes Modellaufrufs über einen In-Container-Proxy aufzeichnet. Für die Evaluierung wurden sieben Benchmarks auf SCLATE portiert und zehn unveränderte Harness- und Memory-Konfigurationen auf zehn Modellen direkt verglichen. Die Leistung wird anhand der Benchmark-Ergebnisse gemessen; die Autoren stellen fest, dass ein hinzugefügtes Memory-System das native Memory des Harness nicht zuverlässig schlägt und dass Modelle sich stark darin unterscheiden, wie sie dasselbe Harness und Memory nutzen. Als Grund wird vermutet, dass das native Memory bereits eng in die Abläufe des Harness integriert ist und daher weniger Overhead verursacht, während externe Systeme zusätzliche Latenz und Integrationsaufwand mit sich bringen. Für die Bewertung von Langzeitgedächtnis gibt es Benchmarks wie LongMemEval-V2, das 451 manuell kuratierte Fragen zu fünf Kernfähigkeiten von Web-Agenten enthält – statischer Zustandsabruf, dynamische Zustandsverfolgung, Workflow-Wissen, Umgebungsfallen und Prämissenbewusstsein – gepaart mit Historien von bis zu 500 Trajektorien und 115 Millionen Token. Die Ergebnisse deuten darauf hin, dass einfache native Speicher oft ausreichen und die Wahl des Memory-Systems vom Anwendungsfall abhängt. Bevor Entwickler komplexe Memory-Architekturen einführen, sollten sie prüfen, ob das eingebaute Gedächtnis des verwendeten Frameworks nicht bereits genügt.

Nutzer uneins: Von 'beeindruckend' bis 'enttäuschend'

Die Nutzerbewertungen des Tools fallen widersprüchlich aus. In einem Reddit-Beitrag von vor wenigen Tagen beschreibt ein Nutzer den ganztägigen Einsatz als enttäuschend: Aktionen und Antworten seien träge, Fortschrittsupdates fehlten, sodass er ständig nachfragen müsse; das Tool nutze seine Rechenfähigkeiten nur minimal. Ein anderer Nutzer bezeichnet die aktuelle Version dagegen als die beeindruckendste Iteration des Always-on-Agent-Modells, die er je gesehen habe, und hebt Vorteile bei der Nutzung über den Browser mit Pro-Abfragen hervor. Die Diskrepanz lässt sich auf mehrere Faktoren zurückführen: Der negative Beitrag erwähnt träge Aktionen und fehlende Fortschrittsupdates, was auf eine möglicherweise langsamere Verarbeitung oder eine andere Version (z. B. CLI statt Browser) hindeuten könnte. Der positive Beitrag betont die Vorteile der Browser-Nutzung mit Pro-Abfragen, die möglicherweise eine höhere Rechenleistung oder bessere Integration bietet. Auch die Erwartungshaltung unterscheidet sich: Während der eine eine schnelle, interaktive Arbeitsweise erwartet, schätzt der andere die Möglichkeit, den Agenten im Hintergrund laufen zu lassen. Ohne Angabe von Version, Setup und konkretem Anwendungsfall sind die Bewertungen daher nur bedingt vergleichbar. Solche gegensätzlichen Urteile sind bei agentischen Tools nicht ungewöhnlich, da die Wahrnehmung stark von der individuellen Aufgabe und der Geduld mit asynchronen Abläufen abhängt.