J'ai expédié onze versions de Neotoma entre le 26 février et le 1er avril 2026. La [version développeur] initiale (/posts/neotoma-developer-release) était fonctionnelle mais approximative. Cela a fonctionné sur ma machine, dans mes flux de travail, avec mes hypothèses intégrées. Cinq semaines de commentaires des évaluateurs, de dogfooding quotidien et d'utilisation dans le monde réel ont fait surface là où cela s'est brisé pour tout le monde.

La plus grande catégorie d'améliorations concerne la fiabilité de la CLI, car la CLI est la première chose qu'un nouvel utilisateur touche et la première chose qui peut échouer lors de l'intégration.

Le deuxième est la stabilité de MCP, car le serveur MCP est ce que les agents appellent des centaines de fois par jour et ses pannes silencieuses corrompent les flux de travail sans avertissement.

Le troisième est l’intégrité des données dans des conditions réelles. Cet article couvre ce qui a changé dans le package npm, pas dans le site ou la documentation.

Le rythme était d'une sortie tous les trois à quatre jours. Certaines versions ont corrigé un seul bug de pagination. D'autres ont regroupé des semaines de renforcement de la CLI, des actions HTTP et du runtime MCP. Le fil conducteur est que chaque version corrigeait quelque chose qui cassait ou dérouta une personne réelle essayant d'utiliser Neotoma pour la première fois.

## La CLI a arrêté de supposer que c'était moi

La CLI de la version développeur fonctionnait à partir d’une extraction de source sur ma machine. C'était le seul contexte que j'avais testé. La première vague de retours a clairement montré que cela n’était pas suffisant.

Le premier correctif était la résolution du chemin. Lorsque vous installez Neotoma globalement via npm et que vous l'exécutez à partir d'un répertoire arbitraire, la CLI doit trouver ses propres ressources sans qu'une extraction de source soit présente. La v0.3.3 a ajouté une résolution de secours à partir de l'emplacement du package installé. La v0.3.8 a livré « openapi.yaml » dans l'archive tar npm afin que le fichier de spécifications soit toujours disponible, pas seulement lorsque vous avez cloné le dépôt.

La détection de l'environnement est venue ensuite. La CLI fait désormais la distinction entre l’exécution à partir d’une extraction source et l’exécution à partir d’une installation npm globale. Les fonctionnalités qui nécessitent une source (comme le mode tunnel) sont soumises à des messages d'erreur clairs au lieu d'échecs énigmatiques. La terminologie dans la sortie CLI a également changé : "Chemin Neotoma" pour l'emplacement d'exécution configuré, "extraction de source" pour les workflows de développement. Le langage précédent utilisait « repo » pour les deux, ce qui confondait les personnes qui installaient via npm et n'avaient pas de dépôt.

Le flux d'initialisation s'est amélioré au fil de plusieurs versions. Les versions 0.3.6 à 0.3.9 ont progressivement renforcé l'expérience de première exécution : meilleur ciblage de l'environnement, UX de démarrage plus claire, gestion plus solide du chemin de configuration. Depuis la version 0.3.10, la CLI pouvait détecter son propre contexte d'installation et ajuster son comportement sans que l'utilisateur ait à lui dire quoi que ce soit.

La v0.3.11 était la plus grande version CLI. Il a ajouté une recherche flexible (`recherche d'entités neotoma` avec des identifiants de position, `--identifier` et `--query` comme alias), un chemin d'entrée structuré préféré pour le magasin (`--entities` et `--file` aux côtés du `--json=` existant) et `storage merge-db` pour combiner les bases de données SQLite avec les modes de résolution de conflits. La version 0.4.0 a rendu la gestion des arguments plus fiable dans les wrappers de nœuds, de chignons et deno.

L'effet net : la CLI est passée de "fonctionne sur ma machine" à "fonctionne sur une nouvelle installation de npm dans un répertoire arbitraire sur la machine de quelqu'un d'autre". Cet écart était plus grand que ce à quoi je m’attendais.

## MCP est devenu sûr pour une utilisation quotidienne des agents

Le serveur MCP permet aux agents d'interagir avec Neotoma. Il doit être fiable d’une manière différente d’une CLI. Les agents ne lisent pas les messages d'erreur. Ils réessayent, interprètent mal ou abandonnent silencieusement le contexte.

Le premier correctif MCP était trivial mais important. La version 0.3.8 a déplacé les journaux d'information du registre de schéma hors de la sortie standard. MCP utilise stdio pour la communication structurée entre l'agent et le serveur. La connexion au même flux a corrompu le protocole. Les agents recevaient des réponses tronquées ou se bloquaient. Le déplacement des journaux vers stderr a corrigé une classe de pannes silencieuses difficiles à diagnostiquer.

La version 0.3.11 incluait des mises à jour plus larges du runtime MCP ainsi que la couche d'action HTTP et la gestion des requêtes d'entité. Les chemins de récupération sont devenus plus fiables pour les requêtes de type liste plutôt que de type identifiant. L'intégration de la recherche lexicale a bénéficié d'une couverture de régression. Le serveur MCP et l'API HTTP partagent désormais davantage de comportements, de sorte que les agents et les consommateurs directs de l'API voient des résultats cohérents.

La version 0.4.0 a poursuivi ce travail en améliorant la génération de chronologies, la projection d'observations, le calcul d'instantanés et le comportement du registre de schémas. Ce sont les mécanismes internes qui déterminent ce que les agents voient lorsqu'ils interrogent l'état de l'entité. En répondant correctement, les agents obtiennent des réponses cohérentes et correctes au fil des sessions.

## La pagination et le filtrage des entités sont devenus honnêtes

La v0.3.4 a corrigé un bug spécifique qui exposait un problème plus large. Lorsque vous avez interrogé des entités par type (par exemple, toutes les tâches), les entités supprimées étaient incluses dans le nombre de résultats mais filtrées des résultats visibles. Les décalages de pagination utilisaient le nombre non filtré. Résultat : des pages contenant moins d'éléments que prévu, des totaux incohérents et des agents qui pensaient avoir tout récupéré alors qu'ils ne l'avaient pas fait.

Le correctif consistait à paginer après le filtrage, pas avant. Le total reflète désormais les entités visibles. Cela semble mineur, mais cela est important pour tout flux de travail d'agent qui parcourt les résultats, ce qui représente la plupart d'entre eux une fois que vous avez plus de quelques dizaines d'entités de tout type.

## La fusion de bases de données est devenue un véritable outil

J'ai [écrit sur la perte et la récupération de 6 000 souvenirs](/posts/how-i-lost-and-recovered-6000-memories) en mars. Cette expérience a motivé l'envoi de « storage merge-db » en tant que commande CLI appropriée dans la v0.3.11.

La commande fusionne deux bases de données SQLite avec une gestion explicite des conflits. Trois modes : « sûr » (par défaut, échoue en cas de conflit), « keep-target » (la cible gagne en cas de collision), « keep-source » (la source gagne). Le mode d'exécution à sec affiche un aperçu de ce qui serait inséré et de ce qui serait en conflit avant que vous ne validiez. Après la fusion, la commande recalcule les instantanés d'entités à partir du journal d'observation afin que l'état dérivé reste correct.

Ce n'est pas seulement un outil de récupération. Il gère la combinaison des données de plusieurs instances Neotoma, la migration entre les machines et la fusion des bases de données de développement et de production. L'architecture basée sur l'observation sécurise toutes ces opérations car les observations sont immuables et l'état de l'entité est déterministe étant donné le même ensemble d'observations.

## Prise en charge multi-outils étendue

La version développeur prenait en charge Cursor, Claude et ChatGPT via MCP. La v0.3.11 a ajouté une documentation explicite sur l'intégration de ChatGPT et a livré « openapi_actions.yaml », une surface en forme d'OpenAPI pour les workflows d'actions GPT et HTTP personnalisées. Cela signifie que ChatGPT peut consommer Neotoma non seulement via MCP, mais également via l'interface d'actions native utilisée par les GPT personnalisés.

Le contrat OpenAPI lui-même a été mis à jour dans les versions 0.3.11 et 0.4.0 pour refléter les modifications apportées à la couche d'action. Si vous consommez Neotoma par programme via l'API, ces versions nécessitent de revérifier tous les clients générés.

## Ancien chemin d'extraction supprimé

La v0.4.0 a supprimé le chemin de code `llm_extraction`. Il s’agissait d’une approche héritée qui utilisait des modèles de langage dans le pipeline de stockage. Le principe de conception de Neotoma est qu'aucun LLM ne se trouve sur le chemin critique du stockage ou de la récupération. L'extraction se produit au niveau de la couche d'agent, pas à l'intérieur de Neotoma. La suppression de l'ancien chemin aligne la base de code sur ce principe et simplifie les composants internes.

C'est le genre de changement qui est invisible pour les utilisateurs mais qui est important pour l'orientation du projet. Neotoma est une couche de vérité, pas une couche d'inférence. Le chemin d’extraction a brouillé cette ligne. Ce n’est plus le cas aujourd’hui.

## Ce que le rythme m'a appris

L'expédition de onze versions en cinq semaines n'était pas prévue. Chaque version répondait à quelque chose de spécifique : un rapport de bug, une première expérience déroutante, un flux de travail qui s'est interrompu en production, une incohérence architecturale que je ne pouvais pas ignorer.

Le modèle qui a émergé était le suivant : l'utilisation quotidienne fait ressortir les problèmes, les commentaires des évaluateurs confirment les priorités et les petites versions les résolvent avant qu'ils ne s'aggravent. L’alternative, consistant à regrouper les modifications dans des versions volumineuses, aurait laissé les vrais utilisateurs bloqués sur un comportement défectueux pendant des semaines.

La version destinée aux développeurs a été positionnée comme « grossière à dessein ». C'était honnête. Ce que j’ai sous-estimé, c’est le nombre d’aspérités spécifiques à ma propre configuration. Résolution du chemin, détection de l'environnement, sécurité du stdio, cohérence de la pagination : aucun de ces problèmes ne m'a posé de problèmes car j'ai exécuté depuis les sources, dans mon terminal, avec mes données. Chacun d'entre eux était un problème pour quelqu'un qui installait via npm pour la première fois.

La phase suivante est différente. The first five weeks answered "does it work for someone who is not me." The next stretch answers "why would someone switch from what they already built."

At least ten people in my [evaluator group](/posts/customer-research-through-agents) are building their own agent memory. Markdown files, SQLite, JSON heartbeats, flat-file CRMs. Même problème, implémentations différentes. Plusieurs d'entre eux ont cité les déclencheurs exacts du moment où leur solution tomberait en panne : écritures simultanées de plusieurs agents, questions de provenance auxquelles ils ne peuvent pas répondre, échelle au-delà de quelques dizaines d'entités actives. Ces déclencheurs sont ma feuille de route.

The concrete next goals come from what evaluators asked for, not from a feature wishlist.

- **Trivial onboarding with an immediate payoff.** The CLI works on other machines now, but "works" is not the same as "five minutes to value." One evaluator spent an hour reading docs before getting set up on a VM. That needs to be five minutes, and the first thing that happens after install should not be an empty database. L'intégration pilotée par l'agent doit analyser vos fichiers locaux, remplir Neotoma avec de vrais enregistrements et faire apparaître une chronologie ou des informations que vous n'aviez pas auparavant. Le moment aha n'est pas "il est installé". Le moment aha est "il sait déjà quelque chose d'utile sur mes données".
- **Une histoire claire de coexistence.** Plusieurs évaluateurs ont demandé si Neotoma devait vivre aux côtés de la mémoire automatique de Claude ou de la mémoire intégrée de ChatGPT, ou les remplacer. The answer is alongside, and the product needs to make that obvious.
- **Profondeur dans les domaines dont la provenance n'est pas négociable.** Santé, conformité, audit financier : les évaluateurs de ces domaines ont déclaré que le langage convenait déjà. The work is making the schemas and guarantees concrete for those verticals.

The deeper architectural work comes from my own daily use, not evaluator requests. Utiliser Neotoma comme couche de mémoire principale pendant des mois a fait apparaître des problèmes structurels que personne de l'extérieur n'aurait encore remarqué.

- **Convergence limitée.** Les agents sont stochastiques. Le même message utilisateur peut produire différents types d'entités, noms de champs et structures de relation en fonction de l'ambiance du modèle. My instance has 170 entity types, and some of that variety is drift, not real ontology. Les prochaines versions ajoutent une normalisation du temps d'écriture : des mappages d'alias pour que "achat" et "transaction" soient résolus selon le même type canonique, une correspondance de champ floue pour que "montant" et "montant_eur" ne bifurquent pas le schéma, et un stockage augmenté par récupération afin que le système vérifie les doublons avant que l'agent ne les crée.
- **Gouvernance des schémas.** À l'heure actuelle, n'importe quel agent peut inventer un nouveau type d'entité sur le premier magasin. Cette liberté est utile au début mais crée un problème de nettoyage à grande échelle. La couche de gouvernance prévue ajoute l'enregistrement des alias, les cycles de vie de dépréciation et les avertissements de diagnostic lorsqu'un magasin s'écarte du schéma canonique. Le système reste permissif lors de l'écriture mais donne un retour dans la réponse afin que les agents se corrigent eux-mêmes.
- **Application progressive.** Aujourd'hui, les schémas sont déduits une seule fois et jamais renforcés. L'étape suivante est le suivi de la confiance : après suffisamment d'observations d'un type, le schéma se cristallise et le système peut avertir des champs communs manquants, des incompatibilités de types et des modèles de relations rompus. Ne pas bloquer les magasins, mais simplement faire apparaître ce qui ne va pas. Le mode strict devient opt-in pour les types à enjeux élevés comme les documents financiers où la variance d'extraction est importante.

Neotoma est [open source sur GitHub](https://github.com/markmhendrickson/neotoma). Si vous avez essayé la version développeur et que vous avez rencontré des difficultés, bon nombre d'entre elles ont été corrigées dans ces versions. Si vous ne l'avez pas encore essayé, le meilleur point de départ est de [demander à votre agent d'évaluer si Neotoma correspond à votre flux de travail](https://neotoma.io/evaluate). L'agent lit la page, inspecte votre configuration et vous dit honnêtement si elle vous convient avant d'installer quoi que ce soit.