Ich habe an etwas gearbeitet, das **[Neotoma](/posts/truth-layer-agent-memory)** heißt.[^1]

Es gibt noch nichts zu versuchen. Dies ist kein Einführungsbeitrag und ich kündige kein Produkt an oder bitte um Anmeldungen. Das Problem beschäftigt mich schon seit einiger Zeit und, was noch wichtiger ist, es behindert meine Arbeit aktiv.

Im letzten Jahr habe ich viel Zeit damit verbracht, mit Agentensystemen zu experimentieren: Arbeitsabläufe zu automatisieren, Aufgaben an Agenten zu delegieren, Systeme sitzungsübergreifend arbeiten zu lassen, anstatt jedes Mal bei Null anzufangen. Immer wieder bin ich gegen die gleiche Wand gestoßen. Die Systeme waren oft beeindruckend leistungsfähig, aber ich konnte ihnen keinen echten, dauerhaften Zustand anvertrauen.

Diese Einschränkung war nicht nur theoretisch. Es war ein praktischer Blocker für die Automatisierung.

## KI-Systeme wechseln still und leise ihre Rollen

Früher waren sie etwas, das man einfach konsultierte: Man stellte eine Frage, bekam eine Antwort und ging weiter. Sie handeln zunehmend. Sie schreiben Dateien und Dokumente, rufen Tools und APIs auf, verweisen sitzungsübergreifend auf vergangene Gespräche und verketten Entscheidungen über die Zeit, ohne für jeden Schritt explizit aufgefordert zu werden.

Ab diesem Zeitpunkt sind personenbezogene Daten kein Referenzmaterial mehr, sondern werden zu „Staatsdaten“.

Und der Staat hat andere Anforderungen.

## Was immer wieder kaputt geht, ist nicht Intelligenz, sondern Vertrauen

Aktuelle KI-Speichersysteme sind auf Komfort ausgelegt. Sie optimieren die Erinnerung, die Geschwindigkeit und die Sprachverständlichkeit sowie die Frage, ob das System das Gefühl hat, dass es sich an Sie erinnert. Keine davon basiert auf Herkunft, Prüfbarkeit, Wiederholbarkeit oder klarer Kausalität.

In der Praxis bedeutet das, dass ich einen Agenten einmal damit beauftragen kann, etwas zu tun, aber ich zögere, ihn *noch einmal* etwas tun zu lassen. Das Gedächtnis verändert sich implizit. Kontextabweichungen. Annahmen häufen sich. Und wenn etwas schief geht, kann ich nicht beantworten, was sich geändert hat, warum es sich geändert hat oder ob das System die gleiche Entscheidung treffen würde, wenn ich es von Grund auf neu ausführen würde.

Dies ist tolerierbar, wenn die KI eine beratende Funktion hat, aber nicht, wenn sie operativ ist.

## Ein Teil des Problems ist eine Nichtübereinstimmung der Kategorien

Wir behandeln weiterhin personenbezogene Daten wie Notizen, Textblöcke oder losen Kontext. Agenten hingegen behandeln dieselben Daten wie Eingaben, Einschränkungen, Auslöser und langlebige Zustände. Sie können keine sichere Automatisierung für Daten durchführen, die Sie nicht prüfen, vergleichen, prüfen oder wiedergeben können.

Dies ist kein UX-Problem. Es ist ein Systemproblem.

## Was fehlt, ist ein grundlegendes Primitiv

Expliziter, inspizierbarer, wiederholbarer persönlicher Zustand.

Andere Domänen haben dies schon vor langer Zeit gelöst. Datenbanken machten den Anwendungsstatus zuverlässig. Ereignisprotokolle machten verteilte Systeme verständlich. Ledger machten die Finanzgeschichte überprüfbar. Persönliche Daten erforderten noch nie zuvor ein derart strenges Maß an Genauigkeit, da Menschen den Kontext im Kopf tragen oder ihn durch manuelle Überprüfung von Aufzeichnungen rekonstruieren konnten.

Agenten ändern diese Annahme.

## Die unangenehme Folgerung ist, dass die richtige Vorgehensweise zu Reibungen führt

Zustandsänderungen können nicht implizit sein.

Speicheraktualisierungen müssen benannte Vorgänge und keine Nebenwirkungen sein. Eingaben müssen sichtbar sein und dürfen nicht abgeleitet werden. Geschichte muss rekonstruierbar sein und darf nicht von Hand geschwenkt werden.

Du gibst etwas Magie auf und akzeptierst mehr Zeremoniell. Andernfalls werden Sie und Ihre Agenten am Ende ein unzuverlässiges Zusammenleben durch unterschiedliche Realitäten erleben.

Es gibt keine Abkürzung, um diesen Kompromiss zu umgehen. Komfortorientierte Systeme und agentensichere Systeme wirken in entgegengesetzte Richtungen.

## Ich behandle personenbezogene Daten so, wie Produktionssysteme den Status behandeln

Das führt zu einigen unvermeidbaren Konsequenzen. Das Verhalten muss vertragsorientiert sein: Statusänderungen sind explizite, typisierte Vorgänge, keine Ad-hoc-Aktualisierungen. Mutationen müssen explizit sein. Nichts aktualisiert nur den Speicher.

Wenn Agenten handeln wollen, benötigen sie eingeschränkte, überprüfbare Schnittstellen und keine undurchsichtigen Eingabeaufforderungen oder Einbettungen. Die Wiederholung ist genauso wichtig wie die aktuelle Antwort: Erklären zu können, wie Sie hierher gekommen sind, ist Teil der Wahrheit.

Die gleiche Eingabe erzeugt immer die gleiche Ausgabe, da die Speicherschicht deterministisch ist und Agenten über ein zuverlässiges Substrat verfügen. Änderungen sind unveränderlich und abfragbar, sodass Sie den Entitätsstatus jederzeit sehen können.

Das Gedächtnis entsteht sowohl aus Dokumenten, die Sie hochladen, als auch aus Daten, die Agenten während Gesprächen schreiben. Ein strukturiertes Diagramm vereint Entitäten und Ereignisse, sodass Agenten über alles nachdenken können.

Das sind keine ästhetischen Vorlieben. Sie scheitern direkt daran, dass sie immer wieder versuchen, echte Arbeitsabläufe zu automatisieren, ohne das Vertrauen in das System zu verlieren, das die Arbeit erledigt.

## Warum ich es so gestalte

Ich behalte es MCP und CLI-first bei. Es gibt keine Web-Benutzeroberfläche und keinen versteckten Speicher. Standardmäßig ist es lokal und verfügt über explizite Schnittstellen für Agenten. Ich nehme nur das auf, was ich explizit bereitstelle, ohne automatisches Scannen oder Hintergrundaufnahme. Das sind keine Auslassungen, das sind Leitplanken. Sie machen es schwieriger, versehentlich oder unabsichtlich darüber zu lügen, was das System weiß und wie es dorthin gelangt ist.

Ich mache es auch plattformübergreifend und datenschutzorientiert. Es funktioniert mit ChatGPT, Claude und Cursor über MCP und ist nicht an einen einzelnen Anbieter gebunden. Ihre Daten bleiben Ihr Eigentum, unterliegen der Kontrolle des Benutzers und werden niemals für Schulungen verwendet. Das sind keine Annehmlichkeiten; Sie sind Voraussetzungen für Vertrauen.

## Was es nicht ist

Es handelt sich nicht um eine Notiz-App oder ein „zweites Gehirn“; Es ist ein strukturiertes Gedächtnissubstrat für Agenten.

Es handelt sich nicht um vom Anbieter kontrollierten ChatGPT-Speicher oder Claude Projects; Es handelt sich um Ihr eigenes Substrat, das über MCP freigelegt wird, sodass jeder Agent es verwenden kann.

Es handelt sich nicht um einen Vektorspeicher oder eine RAG-Ebene. Es handelt sich um ein schemaorientiertes, strukturiertes Gedächtnis mit Provenienz.

Es handelt sich nicht um einen autonomen Agenten, keine Workflow-Engine oder einen KI-Assistenten mit unsichtbarem Gedächtnis; Es sind die Agenten der Speicherschicht, die lesen und schreiben und die Sie steuern.


Und ich würde es noch nicht als zuverlässig bezeichnen. Ich versuche, die Grundschicht aufzubauen, bevor ich vorgebe, dass es Garantien gibt.

## Warum jetzt

Wir normalisieren Systeme, die in unserem Namen handeln, Überzeugungen beibehalten und im Laufe der Zeit Entscheidungen anhäufen. Wenn diese Systeme ausfallen, und das wird der Fall sein, lautet die erste Frage: „Wie ist das passiert?“

Im Moment werden die meisten Tools das nicht beantworten können. Und im letzten Jahr war es diese Unfähigkeit, die mich hauptsächlich daran hinderte, Agenten alles Wichtige anzuvertrauen. Dieses Problem wird bald zunehmen.

Das Agentennetz entsteht. Wir brauchen einen Speicher, bei dem die Benutzer die Kontrolle über den Speicher behalten, und keinen Speicher, bei dem wir ihn zentralen Plattformen überlassen und Agenten in unserem Namen mit undurchsichtigen, unzuverlässigen Methoden handeln. Ich baue Neotoma, um dies bereitzustellen: ein Substrat, das inspizierbar, wiederholbar und vom Benutzer kontrollierbar ist, während das Agentennetz wächst.

## Kommende Entwicklervorschau

Ich arbeite an der Veröffentlichung einer Entwicklervorschau für meinen eigenen Gebrauch und öffentliche Tests. Es wird grob und explizit unzuverlässig sein (z. B. können sich APIs ändern). Sein Zweck wird darin bestehen, diese Ideen im realen Einsatz unter Druck zu testen, und nicht darin, etwas zu verkaufen.

So gehe ich an den Build heran: Ich überführe ihn zunächst in meinem eigenen Agentenstapel, damit ich sehen kann, wo Determinismus und Herkunft tatsächlich helfen und wo sie im Weg stehen. Zu den Anwendungsfällen gehören:

- **Aufgaben und Ausführung** – Aufgaben, Pläne, Projekte und Ergebnisse mit Fälligkeitsterminen und Folgeerinnerungen
- **Kontakte und Beziehungen** – Kontaktdatensätze und Beziehungsdiagramm, verknüpft mit Kommunikation, Aufgaben und Ereignissen
- **Kommunikation** – E-Mail-Triage, durch den Workflow ausgelöste Verarbeitung und Konversationsverfolgung
- **Finanzen** – Transaktionen, Ströme, Einnahmen, Bestände, Überweisungen und Kostenerfassung
- **Aufbewahrung von Aufzeichnungen** – Käufe, Konten, Immobilien und einmalige Analyseberichte
- **Inhalt** – Beiträge, persönlicher Verlauf, Lieblingsmedien und Konsumquellen
- **Gesundheit** – Gewohnheiten, Übungen und laufende Verfolgung

Ich priorisiere MCP-Stabilität und eine minimale CLI, bevor ich mehr Oberfläche hinzufüge, Entitäts- und Beziehungsauflösungen und Zeitachsenabfragen bei steigender Nutzung einem Stresstest unterziehe.

Wenn dieser Rahmen Anklang findet, findet die Arbeit hier im Freien statt:
[https://github.com/markmhendrickson/neotoma](https://github.com/markmhendrickson/neotoma)

Das Markieren des Repos ist die einfachste Möglichkeit, den Überblick über seine Entwicklung zu behalten. Beiträge von Leuten, die über Agentensysteme und skalierbare Zustände nachdenken, sind immer willkommen.

[^1]: Benannt nach der Gattung *Neotoma* (Packratten), die für das Sammeln und Konservieren von Material bekannt ist.