Ich habe zwischen dem 26. Februar und dem 1. April 2026 elf Neotoma-Versionen ausgeliefert. Die erste [Entwicklerversion](/posts/neotoma-developer-release) war funktionsfähig, aber grob. Es funktionierte auf meinem Rechner, in meinen Arbeitsabläufen, mit meinen eingebrannten Annahmen. Nach fünf Wochen Evaluator-Feedback, täglichem Dogfooding und realer Nutzung kam ans Licht, dass es für alle anderen kaputt war. Die größte Verbesserungskategorie ist die CLI-Zuverlässigkeit, da die CLI das Erste ist, was ein neuer Benutzer berührt, und das Erste, was beim Onboarding ausfallen kann. Der zweite Punkt ist die MCP-Stabilität, da der MCP-Server hunderte Male am Tag von Agenten aufgerufen wird und stille Ausfälle dort Arbeitsabläufe ohne Vorwarnung beeinträchtigen. Der dritte Punkt ist die Datenintegrität unter realen Bedingungen. In diesem Beitrag geht es um die Änderungen im npm-Paket, nicht um die Website oder die Dokumente. Das Tempo betrug eine Veröffentlichung alle drei bis vier Tage. In einigen Versionen wurde ein einzelner Paginierungsfehler behoben. Andere bündelten wochenlange Härtung für die CLI, HTTP-Aktionen und die MCP-Laufzeit. Der rote Faden besteht darin, dass in jeder Veröffentlichung etwas angesprochen wurde, das eine reale Person, die Neotoma zum ersten Mal verwenden wollte, kaputt machte oder verwirrte. ## Die CLI ging nicht mehr davon aus, dass ich es war Die Entwickler-Release-CLI funktionierte über einen Source-Checkout auf meinem Rechner. Das war der einzige Kontext, den ich getestet hatte. Die erste Welle an Rückmeldungen machte deutlich, dass dies nicht ausreichte. Die erste Lösung war die Pfadauflösung. Wenn Sie Neotoma global über npm installieren und von einem beliebigen Verzeichnis aus ausführen, muss die CLI ihre eigenen Ressourcen finden, ohne dass ein Quell-Checkout vorhanden ist. v0.3.3 hat eine Fallback-Auflösung vom Speicherort des installierten Pakets hinzugefügt. v0.3.8 hat „openapi.yaml“ im npm-Tarball ausgeliefert, sodass die Spezifikationsdatei immer verfügbar war, nicht nur, wenn Sie das Repo geklont haben. Als nächstes kam die Umgebungserkennung. Die CLI unterscheidet jetzt zwischen der Ausführung von einem Quell-Checkout und der Ausführung von einer globalen NPM-Installation. Funktionen, die eine Quelle erfordern (wie der Tunnelmodus), werden mit eindeutigen Fehlermeldungen anstelle kryptischer Fehler geschützt. Auch die Terminologie in der CLI-Ausgabe hat sich geändert: „Neotoma-Pfad“ für den konfigurierten Laufzeitspeicherort, „Quell-Checkout“ für Entwicklungsworkflows. Die vorherige Sprache verwendete für beides „repo“, was Leute verwirrte, die über npm installierten und kein Repo hatten. Der Init-Flow wurde über mehrere Releases hinweg verbessert. Von v0.3.6 bis v0.3.9 wurde das Erstausführungserlebnis schrittweise verbessert: bessere Umgebungsausrichtung, klarere Start-UX, stärkere Handhabung des Konfigurationspfads. Ab Version 0.3.10 konnte die CLI ihren eigenen Installationskontext erkennen und das Verhalten anpassen, ohne dass der Benutzer ihr etwas mitteilen musste. v0.3.11 war die größte einzelne CLI-Version. Es wurden eine flexible Suche („Neotoma Entities Search“ mit Positionsbezeichnern, „--identifier“ und „--query“ als Aliase), ein bevorzugter strukturierter Eingabepfad für Store („--entities“ und „--file“ neben dem vorhandenen „--json=“) und „storage merge-db“ zum Kombinieren von SQLite-Datenbanken mit Konfliktlösungsmodi hinzugefügt. v0.4.0 machte die Argumentverarbeitung über Node-, Bun- und Deno-Wrapper hinweg zuverlässiger. Der Nettoeffekt: Die CLI wechselte von „Funktioniert auf meinem Computer“ zu „Funktioniert mit einer neuen NPM-Installation in einem beliebigen Verzeichnis auf dem Computer einer anderen Person“. Diese Lücke war größer als ich erwartet hatte. ## MCP wurde für den täglichen Einsatz als Agent sicher Über den MCP-Server interagieren Agenten mit Neotoma. Es muss auf andere Weise zuverlässig sein als eine CLI. Agenten lesen keine Fehlermeldungen. Sie versuchen es erneut, interpretieren den Kontext falsch oder lassen ihn stillschweigend fallen. Der erste MCP-Fix war trivial, aber wichtig. v0.3.8 hat die Informationsprotokolle der Schema-Registrierung von stdout verschoben. MCP verwendet stdio für die strukturierte Kommunikation zwischen Agent und Server. Durch die Anmeldung am selben Stream wurde das Protokoll beschädigt. Agenten würden verstümmelte Antworten erhalten oder hängen bleiben. Durch das Verschieben von Protokollen nach stderr wurde eine Klasse stiller Fehler behoben, die schwer zu diagnostizieren waren. v0.3.11 enthielt umfassendere MCP-Laufzeitaktualisierungen neben der HTTP-Aktionsschicht und der Entitätsabfrageverarbeitung. Die Abrufpfade wurden für Listenabfragen im Vergleich zu Abfragen im Bezeichnerstil zuverlässiger. Die Integration der lexikalischen Suche erhielt eine Regressionsabdeckung. Der MCP-Server und die HTTP-API haben jetzt mehr gemeinsames Verhalten, sodass Agenten und direkte API-Konsumenten konsistente Ergebnisse sehen. v0.4.0 setzte diese Arbeit mit Verbesserungen an der Zeitleistengenerierung, der Beobachtungsprojektion, der Snapshot-Berechnung und dem Schema-Registrierungsverhalten fort. Dies sind die internen Mechanismen, die bestimmen, was Agenten sehen, wenn sie den Entitätsstatus abfragen. Wenn sie richtig sind, erhalten die Agenten in allen Sitzungen konsistente, korrekte Antworten. ## Paginierung und Entitätsfilterung wurden ehrlich v0.3.4 hat einen bestimmten Fehler behoben, der ein umfassenderes Problem aufgedeckt hat. Wenn Sie Entitäten nach Typ abgefragt haben (z. B. alle Aufgaben), wurden gelöschte Entitäten in die Ergebniszählung einbezogen, aber aus den sichtbaren Ergebnissen herausgefiltert. Für Paginierungsoffsets wurde die ungefilterte Anzahl verwendet. Das Ergebnis: Seiten mit weniger Elementen als erwartet, inkonsistente Gesamtwerte und Agenten, die dachten, sie hätten alles abgerufen, obwohl dies nicht der Fall war. Die Lösung bestand darin, nach dem Filtern zu paginieren, nicht vorher. Die Gesamtsumme spiegelt nun sichtbare Entitäten wider. Das hört sich unbedeutend an, ist aber für jeden Agenten-Workflow wichtig, der Ergebnisse durchblättert, was für die meisten gilt, wenn Sie über mehr als ein paar Dutzend Entitäten jeglicher Art verfügen. ## Die Datenbankzusammenführung wurde zu einem echten Werkzeug Ich habe im März [über den Verlust und die Wiederherstellung von 6.000 Erinnerungen geschrieben](/posts/how-i-lost-and-recovered-6000-memories). Diese Erfahrung motivierte die Bereitstellung von „storage merge-db“ als richtigen CLI-Befehl in Version 0.3.11. Der Befehl führt zwei SQLite-Datenbanken mit expliziter Konfliktbehandlung zusammen. Drei Modi: „sicher“ (Standard, schlägt bei jedem Konflikt fehl), „keep-target“ (Ziel gewinnt bei Kollision), „keep-source“ (Quelle gewinnt). Im Probelaufmodus wird vor dem Commit eine Vorschau dessen angezeigt, was eingefügt werden würde und was in Konflikt geraten würde. Nach der Zusammenführung berechnet der Befehl Entitäts-Snapshots aus dem Beobachtungsprotokoll neu, sodass der abgeleitete Status korrekt bleibt. Dies ist nicht nur ein Wiederherstellungstool. Es übernimmt die Kombination von Daten aus mehreren Neotoma-Instanzen, die Migration zwischen Maschinen und die Zusammenführung von Entwicklungs- und Produktionsdatenbanken. Die beobachtungsbasierte Architektur macht alle diese Vorgänge sicher, da Beobachtungen unveränderlich sind und der Entitätsstatus bei gleichem Beobachtungssatz deterministisch ist. ## Multitool-Unterstützung erweitert Die Entwicklerversion unterstützte Cursor, Claude und ChatGPT über MCP. v0.3.11 fügte eine explizite ChatGPT-Integrationsdokumentation hinzu und lieferte „openapi_actions.yaml“, eine OpenAPI-förmige Oberfläche für benutzerdefinierte GPT- und HTTP-Aktionsworkflows. Dies bedeutet, dass ChatGPT Neotoma nicht nur über MCP nutzen kann, sondern auch über die native Aktionsschnittstelle, die benutzerdefinierte GPTs verwenden. Der OpenAPI-Vertrag selbst wurde in Version 0.3.11 und Version 0.4.0 aktualisiert, um Änderungen in der Aktionsebene widerzuspiegeln. Wenn Sie Neotoma programmgesteuert über die API nutzen, müssen bei diesen Versionen alle generierten Clients erneut überprüft werden. ## Alter Extraktionspfad entfernt v0.4.0 hat den Codepfad „llm_extraction“ entfernt. Dies war ein veralteter Ansatz, bei dem Sprachmodelle in der Speicherpipeline verwendet wurden. Das Designprinzip von Neotoma besteht darin, dass sich kein LLM im kritischen Pfad für die Speicherung oder den Abruf befindet. Die Extraktion erfolgt in der Wirkstoffschicht, nicht innerhalb von Neotoma. Durch das Entfernen des alten Pfads wird die Codebasis an diesem Prinzip ausgerichtet und die Interna vereinfacht. Dies ist die Art von Änderung, die für Benutzer unsichtbar ist, aber für die Richtung des Projekts von Bedeutung ist. Neotoma ist eine Wahrheitsschicht, keine Schlussfolgerungsschicht. Der Extraktionspfad verwischte diese Grenze. Jetzt ist es nicht so. ## Was mir das Tempo beigebracht hat Der Versand von elf Veröffentlichungen in fünf Wochen war nicht geplant. Jede Veröffentlichung reagierte auf etwas Bestimmtes: einen Fehlerbericht, ein verwirrendes Erlebnis beim ersten Start, einen Arbeitsablauf, der in der Produktion unterbrochen wurde, eine architektonische Inkonsistenz, die ich nicht ignorieren konnte. Das Muster, das sich herauskristallisierte, war: Im täglichen Gebrauch tauchen Probleme auf, das Feedback der Bewerter bestätigt die Prioritäten und kleine Veröffentlichungen beheben sie, bevor sie sich verschlimmern. Die Alternative, Änderungen in großen Releases zu stapeln, hätte dazu geführt, dass echte Benutzer wochenlang auf fehlerhaftem Verhalten feststeckten. Die Entwicklerversion wurde als „absichtlich grob“ positioniert. Das war ehrlich. Was ich unterschätzt habe, war, wie viele der Ecken und Kanten spezifisch für mein eigenes Setup waren. Pfadauflösung, Umgebungserkennung, Standardsicherheit, Paginierungskonsistenz: Keines davon war für mich ein Problem, da ich mit meinen Daten von der Quelle aus in meinem Terminal lief. Jeder einzelne von ihnen war ein Problem für jemanden, der zum ersten Mal über npm installierte. Die nächste Phase ist anders. Die ersten fünf Wochen antworteten: „Funktioniert es für jemanden, der nicht ich bin?“ Der nächste Abschnitt antwortet: „Warum sollte jemand von dem wechseln, was er bereits aufgebaut hat?“ Mindestens zehn Personen in meiner [Bewertergruppe](/posts/customer-research-through-agents) bauen ihr eigenes Agentengedächtnis auf. Markdown-Dateien, SQLite, JSON-Heartbeats, Flatfile-CRMs. Gleiches Problem, unterschiedliche Implementierungen. Mehrere von ihnen nannten die genauen Auslöser für den Ausfall ihrer Lösung: gleichzeitige Schreibvorgänge von mehreren Agenten, Herkunftsfragen, die sie nicht beantworten können, Skalierung über ein paar Dutzend aktive Entitäten hinaus. Diese Auslöser sind meine Roadmap. Die konkreten nächsten Ziele ergeben sich aus den Anforderungen der Bewerter und nicht aus einer Feature-Wunschliste. - **Einfaches Onboarding mit sofortiger Auszahlung.** Die CLI funktioniert jetzt auf anderen Computern, aber „funktioniert“ ist nicht dasselbe wie „fünf Minuten bis zur Wertschöpfung“. Ein Evaluator verbrachte eine Stunde damit, Dokumente zu lesen, bevor er mit der Einrichtung einer VM begann. Das müssen fünf Minuten sein, und das erste, was nach der Installation passiert, sollte keine leere Datenbank sein. Das agentengesteuerte Onboarding sollte Ihre lokalen Dateien scannen, Neotoma mit echten Datensätzen füllen und eine Zeitleiste oder Einblicke liefern, die Sie vorher nicht hatten. Der Aha-Moment ist nicht „es ist installiert“. Der Aha-Moment ist: „Es weiß bereits etwas Nützliches über meine Daten.“ - **Eine klare Koexistenzgeschichte.** Mehrere Bewerter fragten, ob Neotoma neben Claudes Auto-Memory oder ChatGPTs integriertem Speicher bestehen oder diese ersetzen sollte. Die Antwort steht daneben, und das Produkt muss dies deutlich machen. - **Tiefe in Bereichen, in denen die Herkunft nicht verhandelbar ist.** Gesundheitswesen, Compliance, Finanzprüfung: Gutachter in diesen Bereichen sagten, dass die Sprache bereits passt. Die Arbeit besteht darin, die Schemata und Garantien für diese Branchen zu konkretisieren. Die tiefere Architekturarbeit stammt aus meinem eigenen täglichen Gebrauch und nicht aus Anfragen von Gutachtern. Wenn ich Neotoma monatelang als meine primäre Speicherschicht laufen ließ, traten strukturelle Probleme ans Licht, die noch niemandem von außen aufgefallen wäre. - **Begrenzte Konvergenz.** Agenten sind stochastisch. The same user message can produce different entity types, field names, and relationship structures depending on model mood. Meine Instanz verfügt über 170 Entitätstypen, und ein Teil dieser Vielfalt ist Drift und keine echte Ontologie. Die nächsten Versionen fügen eine Normalisierung der Schreibzeit hinzu: Aliaszuordnungen, damit „purchase“ und „transaction“ in denselben kanonischen Typ aufgelöst werden, Fuzzy-Feldabgleich, damit „amount“ und „amount_eur“ das Schema nicht verzweigen, und abruferweiterte Speicherung, sodass das System nach Duplikaten sucht, bevor der Agent sie erstellt. - **Schema-Governance.** Derzeit kann jeder Agent beim ersten Speichern einen neuen Entitätstyp erfinden. Diese Freiheit ist zunächst nützlich, führt jedoch im großen Maßstab zu einem Bereinigungsproblem. Die geplante Governance-Ebene fügt Alias-Registrierung, veraltete Lebenszyklen und Diagnosewarnungen hinzu, wenn ein Geschäft vom kanonischen Schema abweicht. Das System bleibt beim Schreiben freizügig, gibt aber in der Antwort Feedback, damit die Agenten sich selbst korrigieren können. - **Progressive Durchsetzung.** Schemata werden heute einmal abgeleitet und nie verschärft. Der nächste Schritt ist die Konfidenzverfolgung: Nach ausreichenden Beobachtungen eines Typs kristallisiert sich das Schema heraus und das System kann bei fehlenden gemeinsamen Feldern, Typkonflikten und fehlerhaften Beziehungsmustern warnen. Keine Geschäfte blockieren, sondern nur an die Oberfläche bringen, was falsch aussieht. Der strikte Modus wird für hochriskante Datentypen wie Finanzunterlagen, bei denen es auf die Extraktionsvarianz ankommt, zum Opt-in-Modus. Neotoma ist [Open Source auf GitHub](https://github.com/markmhendrickson/neotoma). Wenn Sie die Entwicklerversion ausprobiert haben und auf Ecken und Kanten gestoßen sind, wurden viele davon in diesen Versionen behoben. Wenn Sie es noch nicht ausprobiert haben, ist der beste Ausgangspunkt, [Ihren Agenten zu fragen, ob Neotoma zu Ihrem Arbeitsablauf passt](https://neotoma.io/evaluate). Der Agent liest die Seite, prüft Ihr Setup und sagt Ihnen ehrlich, ob es passt, bevor Sie etwas installieren.