J'ai travaillé sur quelque chose appelé **[Neotoma](/posts/truth-layer-agent-memory)**.[^1] Il n'y a rien à essayer pour l'instant. Ceci n'est pas un article de lancement, et je n'annonce pas de produit ni ne demande d'inscription. Le problème me dérange depuis un certain temps et, plus important encore, il gêne activement le travail que j'essaie de faire. Au cours de la dernière année, j'ai passé beaucoup de temps à expérimenter les systèmes agentiques : automatiser les flux de travail, déléguer des tâches aux agents, laisser les systèmes fonctionner sur plusieurs sessions au lieu de repartir de zéro à chaque fois. Encore et encore, je me suis heurté au même mur. Les systèmes étaient performants, souvent de manière impressionnante, mais je ne pouvais pas leur faire confiance avec un état réel et continu. Cette limitation n’est pas seulement théorique. Cela constitue un obstacle pratique à l’automatisation. ## Les systèmes d'IA changent discrètement de rôle Avant, c'était quelque chose que l'on consultait simplement : on posait une question, on obtenait une réponse et on passait à autre chose. De plus en plus, ils agissent. Ils écrivent des fichiers et des documents, appellent des outils et des API, font référence à des conversations passées au fil des sessions et enchaînent les décisions au fil du temps sans être explicitement invités à chaque étape. À ce stade, les données personnelles cessent d’être un matériau de référence et commencent à devenir un *état*. Et l’État a des exigences différentes. ## Ce qui ne cesse de se briser, ce n'est pas l'intelligence, mais la confiance Les systèmes de mémoire IA actuels sont construits autour de la commodité. Ils optimisent le rappel, la vitesse et la fluidité, et déterminent si le système *a l'impression* de se souvenir de vous. Aucun n’est construit autour de la provenance, de l’inspectabilité, de la rediffusion ou d’une causalité claire. En pratique, cela signifie que je peux demander à un agent de faire quelque chose une fois, mais j'hésite à le laisser faire *à nouveau*. La mémoire change implicitement. Le contexte dérive. Les hypothèses s’accumulent. Et quand quelque chose ne va pas, je ne peux pas dire ce qui a changé, pourquoi cela a changé ou si le système prendrait la même décision si je le réexécutais à partir de zéro. Ceci est tolérable lorsque l’IA est consultative mais pas lorsqu’elle est opérationnelle. ## Une partie du problème réside dans une inadéquation des catégories Nous traitons toujours les données personnelles telles que les notes, les blobs de texte ou le contexte vague. Les agents, quant à eux, traitent ces mêmes données comme des entrées, des contraintes, des déclencheurs et un état de longue durée. Vous ne pouvez pas automatiser en toute sécurité des données que vous ne pouvez pas inspecter, comparer, auditer ou relire. Ce n'est pas un problème UX. C'est un problème de système. ## Ce qui semble manquer, c'est une primitive de base État personnel explicite, inspectable et rejouable. D'autres domaines ont résolu ce problème il y a longtemps. Les bases de données ont rendu l’état des applications fiable. Les journaux d'événements ont rendu les systèmes distribués compréhensibles. Les grands livres ont rendu l’historique financier vérifiable. Les données personnelles n’avaient jamais eu besoin d’un tel niveau de rigueur auparavant, car les humains pouvaient avoir un contexte dans leur tête ou le reconstruire en examinant manuellement les enregistrements. Les agents changent cette hypothèse. ## L'implication inconfortable est que faire cela correctement ajoute de la friction Les changements d'état ne peuvent pas être implicites. Les mises à jour de mémoire doivent être nommées opérations plutôt que effets secondaires. Les entrées doivent être visibles plutôt que déduites. L’histoire doit être reconstructible plutôt que agitée à la main. Vous abandonnez un peu de magie et acceptez plus de cérémonie. Sinon, vous et vos agents finirez par vivre ensemble de manière peu fiable à travers des lentilles divergentes de la réalité. Il n’existe pas de raccourci pour contourner ce compromis. Les systèmes axés sur la commodité et les systèmes sécurisés pour les agents tirent dans des directions opposées. ## Je traite les données personnelles de la même manière que les systèmes de production traitent l'état Cela entraîne des conséquences inévitables. Le comportement doit être axé sur le contrat : les changements d'état sont des opérations explicites et typées, et non des mises à jour ad hoc. Les mutations doivent être explicites. Rien "ne fait que mettre à jour la mémoire". Si les agents veulent agir, ils ont besoin d’interfaces contraintes et auditables plutôt que d’invites ou d’intégrations opaques. La relecture compte autant que la réponse actuelle : être capable d'expliquer comment vous êtes arrivé ici fait partie de la vérité. La même entrée produit toujours la même sortie puisque la couche mémoire est déterministe et que les agents disposent d'un substrat fiable. Les modifications sont immuables et interrogeables afin que vous puissiez voir l'état de l'entité à tout moment. La mémoire provient à la fois des documents que vous téléchargez et des données que les agents écrivent pendant les conversations, un graphique structuré unifiant les entités et les événements afin que les agents puissent raisonner sur l'ensemble de ceux-ci. Ce ne sont pas des préférences esthétiques. Ils échouent directement en essayant, et en échouant à plusieurs reprises, d'automatiser de véritables flux de travail sans perdre confiance dans le système qui effectue le travail. ## Pourquoi je le conçois de cette façon Je le garde MCP et CLI en premier. Il n'y a pas d'interface utilisateur Web ni de mémoire cachée. Il est local d'abord par défaut, avec des interfaces explicites pour les agents. J'ingère uniquement ce que je fournis explicitement, sans analyse automatique ni ingestion en arrière-plan. Ce ne sont pas des omissions, ce sont des garde-fous. Ils rendent plus difficile, accidentellement ou non, de mentir sur ce que le système sait et comment il y est parvenu. Je le rends également multiplateforme et axé sur la confidentialité dès la conception. Il fonctionne avec ChatGPT, Claude et Cursor via MCP, sans être verrouillé sur un seul fournisseur. Vos données restent les vôtres, contrôlées par l'utilisateur, jamais utilisées à des fins de formation. Ce ne sont pas des commodités ; ce sont des conditions préalables à la confiance. ## Ce que ce n'est pas Ce n'est pas une application de prise de notes ou un « deuxième cerveau » ; c'est un substrat de mémoire structuré pour les agents. Il ne s'agit pas de mémoire ChatGPT ou de projets Claude contrôlés par le fournisseur ; c'est votre propre substrat, exposé via MCP afin que n'importe quel agent puisse l'utiliser. Ce n'est pas un magasin de vecteurs ou une couche RAG ; c'est une mémoire structurée et axée sur le schéma avec provenance. Il ne s'agit pas d'un agent autonome, d'un moteur de workflow ou d'un assistant IA avec une mémoire invisible ; ce sont les agents de couche mémoire qui lisent et écrivent, et vous contrôlez. Et ce n’est pas encore quelque chose que je qualifierais de fiable. J'essaie de construire la couche de base avant de prétendre que des garanties existent. ## Pourquoi maintenant Nous normalisons les systèmes qui prennent des mesures en notre nom, persistent dans leurs croyances et accumulent des décisions au fil du temps. Lorsque ces systèmes échouent, et ce sera le cas, la première question sera : « Comment cela est-il arrivé ? » À l’heure actuelle, la plupart des outils ne sont pas en mesure de répondre à cette question. Et au cours de la dernière année, cette incapacité a été la principale chose qui m'a empêché de faire confiance aux agents pour tout ce qui compte. Ce problème est sur le point de prendre de l’ampleur. Le Web agent est en train d’émerger. Nous avons besoin d’un système dans lequel les utilisateurs gardent le contrôle de la mémoire, et non d’un système dans lequel nous la confions à des plates-formes centralisées et où des agents agissent en notre nom en utilisant des méthodes opaques et peu fiables. Je construis Neotoma pour fournir cela : un substrat inspectable, rejouable et contrôlé par l'utilisateur à mesure que le Web agent se développe. ## Prochain aperçu du développeur Je travaille sur la publication d'un aperçu du développeur pour mon propre usage et mes tests publics. Ce sera approximatif et explicitement peu fiable (par exemple, les API peuvent changer). Son objectif sera de tester ces idées dans des conditions réelles, et non de vendre quoi que ce soit. Comment j'aborde la construction : je la teste d'abord dans ma propre pile agent afin de voir où le déterminisme et la provenance aident réellement et où ils gênent. Les cas d'utilisation incluent : - **Tâches et exécution** — Tâches, plans, projets et résultats avec dates d'échéance et rappels de suivi - **Contacts et relations** — Enregistrements de contacts et graphique des relations liés aux communications, tâches et événements - **Communications** — Tri des e-mails, traitement déclenché par le flux de travail et suivi des conversations - **Finance** — Transactions, flux, revenus, avoirs, transfert et enregistrement des coûts - **Tenue de dossiers** — Rapports d'achats, de comptes, de biens et d'analyses ponctuelles - **Contenu** — Publications, historique personnel, médias préférés et sources de consommation - **Santé** — Habitudes, exercices et suivi continu Je donne la priorité à la stabilité MCP et à une CLI minimale avant d'ajouter plus de surface, de tests de contrainte, de résolution d'entités et de relations et de requêtes de chronologie à mesure que l'utilisation évolue. Si ce cadrage résonne, le travail se déroule à ciel ouvert ici : [https://github.com/markmhendrickson/neotoma](https://github.com/markmhendrickson/neotoma) Mettre le dépôt en vedette est le moyen le plus simple de le suivre à mesure qu'il évolue. Les contributions de personnes qui réfléchissent aux systèmes agents et aux états évolutifs sont toujours les bienvenues. [^1] : Nommé d'après le genre *Neotoma* (packrats), connu pour la collecte et la conservation du matériel.