Ein Ort, an dem ein Fakt festgelegt wird

Wenn mehrere Agenten mit denselben Fakten arbeiten, ändern sich diese Fakten, und nicht alle Agenten erfahren gleichzeitig von der Änderung. An einem Fälligkeitsdatum lässt sich das Problem gut erkennen.

Angenommen, auf der Rechnung INV-2041 steht, dass die Zahlung am 22. Oktober fällig ist. Eine spätere E-Mail des Lieferanten verschiebt den Termin auf den 29. Oktober. Ein Agent liest die Rechnung, ein anderer die E-Mail, und ein dritter bereitet die Zahlungen der Woche anhand dessen vor, was er findet. Der erste nennt den 22. Oktober, der zweite den 29. Oktober, und der dritte nennt das Datum, auf das er zuerst gestoßen ist. In diesem Ablauf ist nicht festgelegt, welches Datum gilt. Die Person, die die Agenten steuert, muss daher selbst nachprüfen.

Dieses konkrete Rechnungsbeispiel habe ich erfunden, aber die Struktur dahinter ist real. Ich betreibe Agenten in drei Werkzeugen mit einer gemeinsamen Neotoma-Instanz. Ein E-Mail-Prozess speichert eingehende Nachrichten mit ihrer Quelle und macht aus Nachrichten, die eine Handlung erfordern, Aufgaben. Sitzungen in Claude Code, Codex und Cursor greifen dieselben Aufgaben und Pläne auf. Aus dieser Einrichtung und meiner Arbeit an Neotoma als umfassendem Aufzeichnungssystem entstand dieser Essay.

Erinnerung erfüllt eine andere Aufgabe

Abrufwerkzeuge finden Material, das zu einer Frage zu passen scheint. Ein Vektorindex oder ein langer Chatverlauf kann das gut leisten, und für viele Aufgaben reicht es aus. Damit ist aber noch nichts als gültig festgelegt. Fragt man nach dem Fälligkeitsdatum, liefern solche Werkzeuge die Rechnung und die E-Mail, geordnet nach ihrer Ähnlichkeit mit der Frage und nicht danach, welche Angabe aktuell ist.

Mehr Werkzeuge und Agentenumgebungen machen es schwieriger. Ein Agent führt Notizen in einer Markdown-Datei, ein anderer behält Gelerntes in seinem Chatprodukt, und ein dritter liest einen gemeinsamen Ordner. Jede Kopie war zum Zeitpunkt ihrer Erstellung richtig. Wenn sich ein Fakt ändert, ändern sich die Kopien zu unterschiedlichen Zeiten oder gar nicht. Kein Agent kann fragen, welche Kopie maßgeblich ist, weil es keinen Ort gibt, an dem diese Frage beantwortet wird. Das Aufzeichnungssystem muss außerhalb jedes einzelnen Werkzeugs liegen, an einem Ort, den alle erreichen können.

Anfang des Jahres bezeichnete ich Neotoma als Gedächtnisschicht und Wahrheitsschicht. Damit habe ich aufgehört, weil ich zu dem Schluss kam, dass »Gedächtnis« die falsche Kategorie für Neotoma ist: Der Begriff führt zu Verwechslungen, und Menschen verglichen Neotoma immer wieder mit Gedächtnisprodukten. Ein Agent soll für mich genaue Daten über viele Arten von Dingen in prüfbarer Form aufbewahren. Die einfache Bezeichnung für den Ort, an dem sie liegen, ist Aufzeichnungssystem.

Damit meine ich ein System, das angibt, was aktuell gilt, woher diese Angabe stammt und was sie ersetzt hat. Eine Ähnlichkeitssuche kann diese Fragen nicht beantworten, denn Ähnlichkeit sagt weder etwas über den Zeitpunkt noch über die Quelle aus.

Was Neotoma heute leistet

Ich entwickle Neotoma, das Aufzeichnungssystem für KI-Agenten. Es ist unter der MIT-Lizenz quelloffen und läuft lokal in einem Datenverzeichnis, das man selbst wählt. Im Folgenden beschreibe ich, was das veröffentlichte Paket (0.25.0 auf npm) heute leistet.

Jeder Schreibvorgang wird als neue Beobachtung gespeichert und mit seiner Quelle verknüpft. Ein neuer Wert wird neben dem alten hinzugefügt, statt ihn zu überschreiben. Neotoma kann das ursprüngliche PDF oder die ursprüngliche E-Mail zusammen mit den daraus abgeleiteten strukturierten Entitäten speichern und die Beobachtungen mit ihrer Quelle verbunden halten.

Beobachtungen gehören zu Entitäten. Die ID einer Entität wird aus dem Entitätstyp und ihren identifizierenden Feldern abgeleitet. Innerhalb derselben Instanz und unter denselben Identitätsregeln ergeben dieselben identifizierenden Werte deterministisch dieselbe ID. Speichern also zwei Agenten dieselbe Rechnung, schreiben sie in dieselbe Entität.

Entitäten können auch miteinander verknüpft werden: etwa eine Rechnung mit ihrem Lieferanten oder eine Folgeaufgabe mit der Rechnung, auf die sie sich bezieht. Ein Agent erstellt diese Beziehungen ausdrücklich. Sie beschreiben, wie die Datensätze zusammenhängen; Quellenlinks zeigen dagegen das PDF oder die E-Mail hinter einer Beobachtung.

Neotoma wendet für jedes Feld automatisch die Zusammenführungsregel des Schemas an, um aus den Beobachtungen den aktuellen Wert zu berechnen. Bei den meisten Feldern setzt sich die neueste Beobachtung durch. Bei gleichen Beobachtungen und gleichen Zusammenführungsregeln ergibt die Reduktion denselben Snapshot, ohne bei jedem Lesen erneut ein Modell entscheiden zu lassen.

Jedes aktuelle Feld benennt die Beobachtung, die seinen Wert festgelegt hat; eine gespeicherte Beobachtung benennt ihre Quelle. Das ist eine Spur zu den Belegen, kein Beweis dafür, dass ein Agent die Belege richtig gelesen hat. Eine Korrektur ist eine weitere Beobachtung und keine Bearbeitung; der frühere Wert bleibt aufgeführt. Außerdem kann man eine Entität so lesen, wie Neotoma sie zu einem früheren Zeitpunkt aufgezeichnet hatte.

Zurück zur Rechnung: Die Schreibvorgänge beider Agenten landen in einer Entität. Als Fälligkeitsdatum erscheint nun der 29. Oktober, mit Verweis auf die Beobachtung aus der E-Mail. Der Betrag verweist weiter auf die erste Beobachtung, denn er hat sich nicht geändert. Der Zahlungsagent liest den 29. Oktober, und die Beobachtung zum 22. Oktober bleibt mit ihrer Quelle aufgelistet.

Agenten erreichen Neotoma über einen MCP-Server, eine REST-API und eine Kommandozeile. Die Installationsanleitung erklärt, wie unterstützte Werkzeuge und Agentenumgebungen verbunden werden. Für gemeinsame Datensätze verbindet man jedes Werkzeug mit derselben Instanz und demselben Datenprofil oder demselben MCP-Eintrag. Getrennte Einträge können getrennte Datenbanken nutzen.

Menschen können ihre Datensätze in der mitgelieferten Neotoma-App einsehen.

Eine zugelassene signierte Anfrage kann eine verifizierte Agentenidentität feststellen. Aktive, auf einen Umfang begrenzte Berechtigungen bestimmen die zulässigen Handlungen; eine Signatur allein erteilt keine Berechtigung.

Wohin die Entwicklung führen soll

Bisher habe ich ein Aufzeichnungssystem beschrieben, das für Agenten festhält, welche Fakten aktuell gelten. Die Richtung ist ein System, das Menschen und Agenten gemeinsam pflegen. Jeder soll fragen können, welcher Wert aktuell ist, welche Quelle ihn eingeführt hat, ob er beobachtet, abgeleitet oder entschieden wurde, wer ihn korrigieren durfte und welche Agenten sich auf die vorherige Version verlassen haben. Die geplanten Governance-Funktionen gehen über die heutige signierte Identität, die begrenzten Berechtigungen und die App hinaus:

• Jedem Bereich eine klare verantwortliche Person zuordnen, deren Befugnis zur Korrektur auf die Datensätze dieses Bereichs beschränkt ist.
• Konkurrierende Behauptungen, offene Streitfälle und offizielle Positionen ausdrücklich darstellen.
• Zeigen, warum ein Wert gilt, wessen Autorität dahintersteht und was eine Änderung betreffen würde.

Ateles führt diese Richtung auf der operativen Seite fort. Im Adapterentwurf von Ateles bringen Adapter Informationen aus Systemen wie E-Mail, Kalendern und Codeplattformen nach Neotoma und übertragen autorisierte Handlungen zurück in diese Systeme. Neotoma speichert die Datensätze; die verbundenen Werkzeuge erledigen die Arbeit.

Die vollständige Vision mit dem aktuellen Stand ihrer Teile steht in der README.

Ein Aufzeichnungssystem statt bloßem Abruf

Die Antwort ist kein besserer Index. Der Abruf hilft einem Agenten zu finden, was gesagt wurde. Ein Aufzeichnungssystem sagt ihm, was aktuell gilt. Agenten, die mit mehreren Werkzeugen arbeiten, brauchen diese zweite Funktion an einem Ort, den alle erreichen können. Ein Aufzeichnungssystem hilft aber nur, wenn die Agenten darin schreiben und daraus lesen.

Wer Agenten in mehr als einem Werkzeug oder einer Agentenumgebung einsetzt, kann mit einem Arbeitsablauf beginnen, dessen Fakten und Entitäten zusammengehören:

npm install -g neotoma
neotoma init
neotoma setup --tool claude-code

Verwenden Sie die Einrichtungsoption für Ihr Werkzeug oder Ihre Umgebung; die Installationsanleitung beschreibt weitere unterstützte Integrationen. Speichern Sie dann die zusammengehörigen Fakten und Entitäten mit einem Agenten und lesen Sie sie mit einem anderen, der mit derselben konfigurierten Instanz und demselben Datenprofil oder MCP-Eintrag verbunden ist.

Die Installationsanleitung steht unter neotoma.io/install. Code und Issue-Tracker finden sich auf GitHub unter github.com/markmhendrickson/neotoma.