Un seul endroit où un fait est établi

Lorsque plusieurs agents travaillent à partir des mêmes faits, ces faits changent et les agents n'apprennent pas tous le changement au même moment. Une date d'échéance illustre clairement le problème.

Supposons que la facture INV-2041 indique un paiement dû le 22 octobre, puis qu'un courriel ultérieur du fournisseur reporte l'échéance au 29 octobre. Un agent lit la facture, un autre le courriel, et un troisième prépare les paiements de la semaine à partir de ce qu'il trouve. Le premier répond « 22 octobre », le deuxième « 29 octobre » et le troisième donne la première date qu'il a trouvée. Rien dans cette organisation ne dit quelle date fait foi : la personne qui dirige les agents doit donc vérifier.

J'ai inventé cet exemple précis de facture, mais l'organisation qui le sous-tend est réelle. J'utilise des agents dans trois outils avec une seule instance de Neotoma. Un processus qui relève le courrier enregistre les messages reçus avec leur source et transforme ceux qui nécessitent une action en tâches ; des sessions dans Claude Code, Codex et Cursor reprennent les mêmes tâches et les mêmes plans. Cette configuration, ainsi que mon travail sur Neotoma comme système d'enregistrement complet, sont à l'origine de cet essai.

Le rappel sert à autre chose

La recherche d'information retrouve des éléments qui semblent liés à une question. Un index vectoriel ou un long historique de conversation le font bien et, pour beaucoup de tâches, cela suffit. Mais ils ne tranchent pas ce qui est en vigueur. À une question sur la date d'échéance, la recherche renvoie la facture et le courriel classés selon leur proximité avec la question, et non selon celui qui reflète l'état actuel.

Multiplier les outils et les environnements d'agents complique les choses. Un agent conserve des notes dans un fichier Markdown, un autre garde ce qu'il a appris dans son application de conversation, un troisième lit un dossier partagé. Chaque copie était correcte au moment où elle a été écrite. Quand le fait change, les copies évoluent à des moments différents, ou pas du tout. Aucun agent ne peut demander laquelle prévaut, car aucun endroit ne fournit de réponse. Le système d'enregistrement doit se trouver hors de chacun de ces outils, à un endroit qu'ils peuvent tous atteindre.

Au début de l'année, j'appelais Neotoma une couche de mémoire et une couche de vérité. J'ai cessé de le faire parce que j'en suis venu à penser que la mémoire n'est pas la bonne catégorie pour Neotoma : elle prête à confusion, et les gens continuaient à comparer Neotoma à des produits de mémoire. Ce que j'ai besoin qu'un agent conserve, ce sont des données exactes sur de nombreuses sortes de choses, sous une forme vérifiable. Le terme simple pour le lieu qui les contient est « système d'enregistrement ».

C'est ce que j'entends par système d'enregistrement : il indique ce qui est en vigueur, d'où cela vient et ce que cela a remplacé. Une recherche par similarité ne peut répondre à ces questions, car la similarité ne dit rien du temps ni de la source.

Ce que Neotoma fait aujourd'hui

Je développe Neotoma, le système d'enregistrement pour les agents d'IA. Il est open source sous licence MIT et fonctionne localement, dans le répertoire de données de votre choix. Ce qui suit décrit ce que fait aujourd'hui le paquet publié (0.25.0 sur npm).

Chaque écriture est enregistrée comme une nouvelle observation liée à sa source. Une nouvelle valeur est ajoutée à côté de l'ancienne plutôt que de l'écraser. Neotoma peut conserver le PDF ou le courriel d'origine à côté des entités structurées qui en sont tirées, en gardant les observations liées à leur source.

Les observations appartiennent à des entités. L'identifiant d'une entité est dérivé du type d'entité et de ses champs d'identification. Dans une même instance et avec les mêmes règles d'identité, les mêmes valeurs d'identification produisent toujours le même identifiant ; deux agents qui enregistrent la même facture écrivent donc dans la même entité.

Les entités peuvent aussi être reliées entre elles : la facture à son fournisseur, ou une tâche de suivi à la facture qu'elle concerne. L'agent crée explicitement ces relations. Elles décrivent comment les enregistrements s'articulent, tandis que les liens vers les sources montrent le PDF ou le courriel à l'origine d'une observation.

Neotoma applique automatiquement la règle de fusion prévue par le schéma pour chaque champ afin de calculer sa valeur en vigueur à partir des observations. Pour la plupart des champs, l'observation la plus récente l'emporte. Avec les mêmes observations et les mêmes règles de fusion, la réduction produit le même instantané, sans demander à un modèle de refaire le choix à chaque lecture.

Chaque champ en vigueur désigne l'observation qui l'a établi, et une observation enregistrée désigne sa source. C'est une piste vers les éléments probants, pas une preuve qu'un agent les a lus correctement. Une correction constitue une observation supplémentaire, pas une modification, et l'ancienne valeur reste visible. On peut aussi lire une entité telle que Neotoma l'avait enregistrée à une date antérieure.

Revenons à la facture. Les écritures des deux agents aboutissent à une seule entité. La date d'échéance est désormais le 29 octobre et désigne l'observation issue du courriel. Le montant désigne toujours la première observation, puisqu'il n'a pas changé. L'agent chargé des paiements lit le 29 octobre ; l'observation du 22 octobre reste visible avec sa source.

Les agents accèdent à Neotoma par un serveur MCP, une API REST et une interface en ligne de commande. Le guide d'installation explique comment connecter les outils et les environnements pris en charge. Pour partager des enregistrements, faites pointer chaque outil vers la même instance et le même profil de données, ou vers la même entrée MCP ; des entrées distinctes peuvent utiliser des bases de données distinctes.

Les personnes peuvent consulter leurs enregistrements dans l'application Neotoma fournie avec le paquet.

Une requête signée admise peut établir une identité d'agent vérifiée. Les autorisations actives et limitées à leur périmètre déterminent les actions permises ; une signature seule ne constitue pas une autorisation.

La direction envisagée

J'ai décrit jusqu'ici un système d'enregistrement qui établit les faits en vigueur pour les agents. La direction visée est un système d'enregistrement entretenu conjointement par des personnes et des agents, où chacun pourra demander quelle valeur est en vigueur, quelle source l'a introduite, si elle a été observée, déduite ou décidée, qui avait le pouvoir de la corriger et quels agents se sont appuyés sur la version précédente. Les capacités de gouvernance prévues dépassent l'identité signée, les autorisations limitées et l'application qui existent aujourd'hui :

• Donner à chaque domaine un responsable clairement identifié, dont le pouvoir de correction est limité aux enregistrements de ce domaine.
• Représenter explicitement les affirmations concurrentes, les différends non résolus et les positions officielles.
• Montrer pourquoi une valeur fait foi, de quelle autorité elle dépend et ce qu'un changement pourrait affecter.

Ateles prolonge cette direction sur le plan opérationnel. Dans la conception des adaptateurs d'Ateles, les adaptateurs acheminent vers Neotoma des informations provenant notamment du courrier, des calendriers et des hébergeurs de code, puis portent les actions autorisées vers ces systèmes. Neotoma conserve les enregistrements ; les outils connectés exécutent le travail.

La vision d'ensemble, avec l'état actuel de chaque élément, figure dans le README.

Un système d'enregistrement, pas seulement du rappel

La réponse n'est pas un meilleur index. La recherche aide un agent à retrouver ce qui a été dit. Un système d'enregistrement lui indique ce qui est en vigueur. Les agents qui travaillent dans plusieurs outils ont besoin de cette seconde fonction, à un endroit qu'ils peuvent tous atteindre ; et un système d'enregistrement n'aide que si les agents y écrivent et y lisent.

Si vous utilisez des agents dans plusieurs outils ou environnements, commencez par un flux de travail dont les faits et les entités vont ensemble :

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

Utilisez l'option de configuration adaptée à votre outil ou environnement ; le guide d'installation couvre les autres intégrations prises en charge. Enregistrez ensuite les faits et les entités liés à ce flux depuis un agent, puis lisez-les depuis un autre connecté à la même instance configurée et au même profil de données ou à la même entrée MCP.

Le guide d'installation se trouve sur neotoma.io/install. Le code et le suivi des problèmes se trouvent sur GitHub à github.com/markmhendrickson/neotoma.