Ce que fait réellement ma pile agent

Ma pile agentique est la façon dont je dogfood Neotoma. C'est aussi mon système d'exploitation personnel. Un monorepo privé où les agents d'IA gèrent tout, du tri des e-mails aux paiements Bitcoin en passant par les déploiements de sites Web, avec Neotoma comme mémoire structurée en dessous.

Chaque fonctionnalité que je propose dans Neotoma est d'abord validée ici, principalement dans Curseur et secondairement via des agents de terminal comme Claude Code, Codex et Cursor CLI. Chaque lacune que je trouve dans la mémoire des agents apparaît ici en premier. La pile est la façon dont je gère ma vie quotidienne et mon travail. Les frictions que je rencontre, en plus des commentaires des utilisateurs, sont le moteur de la feuille de route de Neotoma.

J'ai l'intention d'ouvrir la pile en source. Mais le dépôt a accumulé des mois de données personnelles, des scripts codés en dur sur mes comptes et une configuration liée à ma configuration. Avant qu'elles puissent être rendues publiques, je dois intégrer entièrement ces données dans Neotoma et refactoriser les outils pour qu'ils soient génériques. Ce travail est en cours.

Cet article explique ce qu'est la pile, comment je l'utilise et ce qu'elle révèle sur ce que la mémoire structurée des agents doit faire.

Qu'est-ce que la pile

La pile est un monorepo avec plus d'une douzaine de serveurs MCP et CLI, chacun connectant les agents IA à un service différent : Gmail, Google Calendar, WhatsApp, un Portefeuille Bitcoin, Instagram, Asana, HomeKit, DNSimple, Google Search Console, 1Password, un web scraper, et plus encore. Certains sont des serveurs MCP que les agents appellent comme outils. D'autres sont des CLI que les agents appellent depuis le terminal. Les deux offrent aux agents la même chose : accéder à des services externes.

Au-dessus des serveurs MCP se trouvent des règles et des compétences. Les règles sont des instructions comportementales persistantes qui résident dans le dépôt, pas dans Neotoma : stockez toujours les contacts dans Neotoma avant de répondre, ne commettez jamais de secrets, utilisez la casse des phrases dans les titres, exécutez des tests après les modifications de code, préférez la CLI au tableau de bord pour les journaux et la configuration, liez la première mention des noms de produits. Les compétences sont des flux de travail en plusieurs étapes : trier ma boîte de réception, rédiger un article de blog, déployer un site Web, traiter les commentaires sur les produits, extraire une commande Amazon d'un e-mail, payer un entrepreneur en Bitcoin.

Et en dessous de tout se trouve Neotoma comme couche de mémoire structurée. Chaque agent le lit et y écrit. C'est ce qui fait que la pile se compose au fil du temps au lieu de se réinitialiser à chaque session.

Comment je travaille avec

J'habite à Cursor. Ma journée est une séquence de séances d'agents. J'ouvre un nouvel agent, décris ce que je veux faire et l'agent s'exécute à l'aide des serveurs MCP, des règles et des compétences de l'espace de travail. Certaines sessions sont rapides : « répondre à cet email ». Certains sont longs : "trier ma boîte de réception, traiter les derniers commentaires des testeurs, puis rédiger un article comparatif sur l'agent de mémoire de Google."

C'est du coworking avec des agents. Je m'assois à mon bureau et je travaille à leurs côtés toute la journée. Tâches personnelles : planifier une réparation, payer un entrepreneur, gérer les événements du calendrier. Professionnels : rédaction d'articles, traitement des retours, déploiement de sites Web, gestion de domaines. Les agents s'occupent de l'exécution. Je fournis des orientations, j'examine les résultats et j'approuve les actions qui nécessitent un humain dans la boucle.

Chaque session d'agent possède le contexte complet de l'espace de travail : chaque serveur MCP, chaque règle, chaque compétence. L'agent peut lire mon Gmail, vérifier mon calendrier, interroger Neotoma pour obtenir un contexte préalable, stocker de nouvelles données, générer des images, pousser du code et vérifier les déploiements. Mon rôle consiste de plus en plus à décrire l’intention et à examiner les résultats.

Comment Neotoma s'adapte

Sans mémoire structurée, chaque session d'agent démarre à zéro. L'agent ne sait pas qui sont vos contacts, quelles tâches vous avez en cours, ce dont vous avez discuté hier ou ce que vous avez déjà payé à quelqu'un. Vous pouvez coller du contexte dans chaque invite, mais cela ne dépasse pas quelques sessions. Mémoire de la plateforme stocke votre ambiance, pas votre travail. RAG aide avec le code, mais pas avec les faits structurés qui pilotent les flux de travail : à qui vous devez de l'argent, quels commentaires vous avez reçus la semaine dernière, quelles tâches sont encore ouvertes.

Mon instance Neotoma stocke plus de 1 000 contacts, 600 tâches, 140 conversations, 120 articles de blog et 170 types d'entités créés par les agents lorsqu'ils rencontraient de nouveaux types d'informations : transactions, règles permanentes, notes de commentaires, événements de calendrier, litiges, factures, compétences, résultats de déploiement. Lorsqu'un agent démarre une nouvelle session, il récupère ce dont il a besoin. Une fois terminé, il stocke ce qu’il a appris.

Voici les 20 principaux types d'entités dans mon instance Neotoma aujourd'hui, avec un exemple de chacun :

Aucun de ces schémas n’a été conçu à l’avance. Les agents créent et étendent des schémas selon les besoins à mesure qu'ils rencontrent de nouveaux types d'informations. Le système compte désormais 170 types d’entités au total, la plupart avec seulement une poignée d’enregistrements. C'est dans la longue traîne que la mémoire de l'agent devient intéressante : une seule entité de litige avec son historique complet de négociation, un seul engagement à assurer un suivi auprès de quelqu'un si la stratégie change, une seule préférence sur la manière de gérer un paiement spécifique.

La différence pratique est que les agents s’appuient sur des travaux antérieurs. Lorsque je demande à un agent d’envoyer un e-mail à quelqu’un, il recherche d’abord le contact dans Neotoma. Lorsque je lui demande de traiter les commentaires, il récupère les entités de commentaires existantes et en relie de nouvelles. Lorsque je lui demande de payer un entrepreneur en Bitcoin, il connaît la règle permanente (toujours payer cette personne en BTC) et inclut le lien de transaction dans la confirmation, car une autre règle permanente le demande.

Stockage et récupération de près

Le Neotoma MCP expose des outils que les agents appellent directement. Voici à quoi ressemblent les véritables stockages et récupérations dans la pratique.

Lorsqu'un agent doit conserver un tour de conversation avec des entités extraites, il appelle « store » avec une seule charge utile :

magasin({
  "entités": [
    {
      "entity_type": "conversation",
      "title": "Tri des e-mails le 9 mars"
    },
    {
      "entity_type": "agent_message",
      "rôle": "utilisateur",
      "content": "trier ma boîte de réception",
      "turn_key": "conv-42:1"
    },
    {
      "entity_type": "contact",
      "full_name": "Alex Chen",
      "email": "alex@exemple.com",
      "source": "appel de feedback du testeur"
    },
    {
      "entity_type": "tâche",
      "title": "Suivez les retours d'Alex",
      "statut": "en attente",
      "priorité": "moyen"
    }
  ],
  "relations": [
    {
      "relationship_type": "PART_OF",
      "source_index": 1,
      "index_cible": 0
    },
    {
      "relationship_type": "REFERS_TO",
      "source_index": 1,
      "index_cible": 2
    },
    {
      "relationship_type": "REFERS_TO",
      "source_index": 1,
      "index_cible": 3
    }
  ],
  "idempotency_key": "conv-42-turn-1-triage"
})

Un appel stocke la conversation, le message, un nouveau contact et une tâche, tous liés par des relations tapées. L'agent n'avait pas besoin au préalable d'une définition de schéma pour « contact » ou « tâche ». Neotoma accepte les champs arbitraires et en déduit la structure.

Lorsqu'un agent a besoin de contexte avant de répondre, il interroge par identifiant :

retrieve_entity_by_identifier({
  "identifiant": "Alex Chen"
})

Cela renvoie l'enregistrement du contact avec l'e-mail, les conversations antérieures et la provenance de chaque champ. Si l'agent a besoin d'un contexte plus large, il interroge par type :

récupérer_entités({
  "entity_type": "feedback_note",
  "search": "version développeur",
  "limite": 10
})

Cela renvoie les dix notes de commentaires les plus pertinentes sur la version du développeur, chacune avec son instantané complet et son historique d'observation.

Pour les règles permanentes, l'agent les récupère une fois au début d'un workflow :

récupérer_entités({
  "entity_type": "standing_rule"
})

Mon instance renvoie des règles telles que « toujours payer Carlos en Bitcoin » et « fournir des messages rédigés dans des blocs de démarque ». L'agent les applique automatiquement pour le reste de la session.

Lorsque les workflows touchent des fichiers (reçus, captures d'écran, documents), l'agent les stocke aux côtés des entités dans le même appel en utilisant file_path :

magasin({
  "entités": [
    {
      "entity_type": "transaction",
      "fournisseur": "Amazon",
      "montant" : 47,99,
      "devise": "EUR"
    }
  ],
  "file_path": "/chemin/vers/receipt.pdf",
  "idempotency_key": "amazon-order-mars-9"
})

Le chemin de stockage non structuré de Neotoma gère le fichier à partir de là. Les octets bruts sont adressés par contenu (SHA-256), de sorte que le même fichier n'est jamais stocké deux fois. L'agent transmet le fichier tel quel via file_path (environnements locaux comme Cursor) ou file_content (base64, pour les environnements Web) ; il n'interprète ni n'extrait les données avant de les stocker. Par défaut, Neotoma exécute automatiquement l'interprétation de l'IA sur le fichier stocké, extrayant les entités structurées et les reliant à la source avec une relation EMBEDS. La restauration du même fichier avec « interpret : true » déclenche la réinterprétation sans créer de doublon. Le reçu devient des données structurées interrogeables avec le PDF original conservé pour la provenance. L'interprétation peut également être différée (« interpret : false ») pour le traitement par lots ou la gestion des quotas, puis exécutée ultérieurement avec une configuration différente.

Workflows en pratique

Quelques flux de travail montrent le modèle.

Triage des e-mails. L'agent lit les e-mails non lus via Gmail MCP, vérifie Neotoma pour les enregistrements de contacts existants et le contexte antérieur avec chaque expéditeur, rédige les réponses en utilisant mes règles de style de communication, stocke les nouveaux contacts et tâches et archive les messages traités. Une seule opération de tri peut stocker cinq nouveaux contacts, trois tâches et une douzaine de tours de conversation.

Rédaction d'un article de blog. La compétence elle-même vit dans Neotoma en tant qu'entité structurée. L'agent le récupère avec retrieve_entity_snapshot. Il interroge ensuite les publications existantes pour l'étalonnage du style, rédige le brouillon, stocke l'entité de publication avec toutes les métadonnées, génère des images de héros, crée une copie de partage pour Twitter et LinkedIn, régénère le cache du site Web à partir de l'exportation Neotoma et déploie. Ce message a été écrit de cette façon.

Paiements Bitcoin. Je paie un entrepreneur en Bitcoin en utilisant un serveur MCP de portefeuille BTC. Neotoma stocke la règle permanente, l'enregistrement des contacts et l'historique des transactions. L'agent récupère les trois, exécute le paiement, stocke la nouvelle transaction avec le lien en chaîne et confirme.

Traitement des commentaires. Lorsque les testeurs donnent leur avis sur la version du développeur Neotoma, les agents extraient les entités de commentaires structurées, les lient à l'enregistrement de contact du testeur, classent les commentaires par compartiment et les évaluent par rapport aux contraintes de l'étape de publication. Les commentaires antérieurs peuvent être récupérés par testeur, par compartiment ou par date.

Déploiement de site Web. La compétence de déploiement synchronise les modifications de démarques locales avec Neotoma, exporte l'ensemble de données complet du site Web, régénère le cache, pousse le dépôt du site Web et surveille les Actions GitHub jusqu'à ce que la construction réussisse. Si la génération échoue, l'agent lit les journaux, corrige le problème et réexécute.

Vers les agents qui courent sans moi

Chaque flux de travail commence par l'ouverture d'un agent Cursor et la saisie d'une instruction. Je suis au courant de chaque tâche. C’est bien pour l’étape actuelle, mais ce n’est pas l’état final.

Je mets en place des processus automatisés afin que les agents puissent gérer les flux de travail sans mon implication directe. Les éléments sont déjà là : les compétences définissent toutes les étapes du flux de travail, Neotoma stocke le contexte et les règles, les serveurs MCP fournissent la portée. Ce qui manque, c'est l'orchestration qui déclenche les flux de travail selon un calendrier ou en réponse à des événements, ainsi qu'une interface d'approbation légère qui me permet de réviser et d'autoriser des actions sans rester assis devant mon ordinateur portable.

L'architecture en couches de Neotoma est conçue exactement pour cela. Il distingue trois préoccupations :

1. Couche de vérité (Neotoma). Source d'événements, pilotée par un réducteur, déterministe. Tous les agents l'ont lu. Les mises à jour d'état circulent uniquement via les événements de domaine traités par les réducteurs. Aucun agent ne fait muter directement la vérité.
2. Couche de stratégie. Lit l'état actuel du monde à partir de Neotoma. Évalue les priorités, les contraintes, les risques, les engagements et le temps. Produit des décisions et des commandes. Cognition pure : état entrant, décisions sortantes. Aucun effet secondaire.
3. Couche d'exécution. Prend les commandes de la couche de stratégie. Effectue des effets secondaires via des adaptateurs externes (API de messagerie, services de paiement, calendrier, messagerie). Émet des événements de domaine décrivant ce qui s'est passé. Ces événements reviennent via les réducteurs pour mettre à jour l’état. Effet pur : commandes entrantes, événements sortants.

La boucle est bouclée :

Signaux entrants (e-mail, WhatsApp, calendrier, données financières)
  -> Normalisation -> État Neotoma (journal des événements + réducteurs)
  -> Coche de stratégie (évaluer les priorités, les décisions de sortie)
  -> Agents d'exécution (effectuer des effets secondaires, émettre des événements)
  -> Réducteurs -> État mis à jour
  -> Coche suivante

Aujourd’hui, je suis la couche stratégique. J'observe l'état, je décide quoi faire et je dis à un agent d'exécuter. L'architecture rend ce rôle remplaçable par un logiciel. Un moteur de stratégie lit Neotoma, évalue ce qui nécessite une attention particulière en fonction des règles et priorités en vigueur et émet des commandes aux agents d'exécution. Ces agents appellent les serveurs MCP, stockent les résultats et le cycle se répète.

L'invariant critique est qu'aucune couche n'écrit directement dans le magasin de données sous-jacent de Neotoma. Les mises à jour transitent uniquement par les événements de domaine et les réducteurs. Cela rend le système auditable et réversible. Si un agent autonome prend une mauvaise décision, je peux retracer l'événement qui l'a provoquée, annuler la mise à jour de l'état et corriger la règle qui y a conduit.

L’objectif est de réduire mon temps quotidien devant l’ordinateur. Pas l’éliminer. Passez de l’exécution pratique à l’examen et à l’approbation. Je veux me réveiller avec un résumé de ce que mes agents ont traité pendant la nuit : les e-mails triés, les messages rédigés, les déploiements vérifiés, les paiements en file d'attente. Je souhaite approuver un paiement Bitcoin depuis mon Apple Watch. Je souhaite consulter un e-mail rédigé sur mon téléphone tout en marchant et appuyer pour l'envoyer. Les agents gèrent les 80 % qui sont reproductibles. Je gère les 20 % qui nécessitent du jugement.

C'est là que la question du matériel devient intéressante. Les téléphones et les montres d'aujourd'hui ne sont pas conçus pour ce modèle d'interaction. Vous avez besoin d’un appareil optimisé pour de brefs gestes de révision et d’approbation, et non pour la saisie ou la navigation.

Parmi les appareils qui existent aujourd'hui, l'Apple Watch se rapproche le plus du bon facteur de forme : toujours à votre poignet, visible, capable d'interactions simples en appuyant pour approuver. Mais la couche logicielle n’est pas encore là. Il n’existe aucun moyen de transmettre les résumés des agents et les demandes d’approbation à la montre d’une manière qui semble native.

Cela pourrait être un domaine dans lequel je pourrais expérimenter à un moment donné, en créant une application compagnon légère qui relie l'état de Neotoma à une interface au niveau du poignet. Que la bonne surface soit une application de montre, un appareil d'IA dédié ou quelque chose qui n'existe pas encore, le modèle d'interaction est clair : les agents font le travail, la mémoire structurée détient l'état et l'humain donne la direction au rythme de l'intention plutôt qu'au rythme de l'exécution.

Open-sourcer la pile

La pile est aujourd’hui privée car elle contient ma vie : contacts, finances, données de santé, communications personnelles, règles en vigueur sur la façon dont je gère mon foyer. Avant de pouvoir l'ouvrir en source, je dois démêler tout cela.

Le chemin est simple. Les données personnelles sont entièrement transférées dans Neotoma, qui est déjà pour la plupart la source de vérité. Les scripts qui font référence à mes comptes et chemins spécifiques sont refactorisés pour être lus à partir de la configuration. Les wrappers de serveur MCP deviennent génériques. Les compétences perdent leurs hypothèses codées en dur.

Ce qui reste est une pile agent réutilisable : un modèle monorepo avec un échafaudage de serveur MCP, un cadre de règles et de compétences, une intégration Neotoma pour la mémoire structurée et des exemples de flux de travail que chacun peut adapter. L'architecture est la partie intéressante. Mes données personnelles ne le sont pas.

Je n'ai pas de calendrier pour cela. La refactorisation s'effectue parallèlement à l'utilisation quotidienne. Chaque fois que je touche à un script, je le rends plus générique. Chaque fois que je déplace des données vers Neotoma, je les supprime du dépôt. La pile devient plus portable à chaque session.

Ce que cela prouve sur Neotoma

J'ai construit cette pile avant que Neotoma n'existe. La première version utilisait des fichiers plats et des tables Parquet. Cela a fonctionné jusqu'à ce que ce ne soit plus le cas.

Les modes d'échec étaient spécifiques : un agent stockait un contact sous le nom de "Sarah Kim" dans une session et "S. Kim" dans une autre, créant des doublons sans aucun moyen de les fusionner. Il n'y avait aucune provenance, donc je ne pouvais pas dire quel agent avait écrit un champ ni quand.

Les requêtes étaient limitées aux correspondances exactes sur des colonnes uniques, donc demander « quels commentaires ai-je reçus la semaine dernière ? signifiait analyser chaque fichier manuellement. Parfois, les enregistrements étaient mal écrasés ou entièrement supprimés, sans aucun journal des événements à partir duquel récupérer. Et rien n'est lié entre les types, donc sachant qu'une tâche liée à un contact lié à une transaction m'obligeait à garder ce graphique en tête.

Neotoma a remplacé cette couche. Il a donné aux agents une mémoire structurée, interrogeable et sensible aux relations qui fonctionne dans tous les flux de travail. La pile compte désormais 170 types d'entités dans Neotoma, non pas parce que j'ai conçu 170 schémas à l'avance, mais parce que les agents créent des types d'entités lorsqu'ils rencontrent de nouveaux types d'informations. Une note de feedback est différente d’une transaction d’une règle permanente, et le système les gère toutes.

C'est le dogfooding qui maintient Neotoma honnête. Lorsque la récupération est lente, je le ressens à chaque session d'agent. Lorsque la résolution d'entité échoue, j'obtiens des contacts en double. Lorsque le stockage n'est pas fiable, les flux de travail s'interrompent. Chaque bug et chaque lacune apparaît dans mon travail quotidien avant d'apparaître dans celui de quelqu'un d'autre.

Le problème de la mémoire est universel. Tous les développeurs qui créent des flux de travail agents se heurteront au même mur : des agents incapables de se souvenir, de ne pas interroger et de s'appuyer sur des travaux antérieurs. La récupération seule ne suffit pas; la structure et la provenance sont ce qui rend la mémoire digne de confiance. Cette pile est la preuve que la mémoire structurée modifie ce que les agents peuvent faire. Neotoma est la façon dont je mets cela à la disposition de tout le monde.

La version développeur est ouverte aux tests. Si vous créez des flux de travail agents et souhaitez une mémoire structurée en dessous, c'est par là qu'il faut commencer.