Le cerveau de mes agents est un dépôt Git

Ce que tu vas en retirer : Tu découvriras les sept règles et la structure simple de Vault qui me permettent de garantir que les connaissances des agents restent lisibles, gérées par versions et indépendantes des outils.

Pour moi, un agent IA n'a pas besoin d'une mémoire mystique. Il a besoin de fichiers que je puisse lire, vérifier et réutiliser.

C’est pourquoi le « cerveau » de mes agents se trouve dans un dépôt Git privé. Le Markdown y est la source de vérité. Git consigne chaque modification. Obsidian est mon interface pratique pour la recherche, les liens et la vue d’ensemble, mais ce n’est pas une condition indispensable pour accéder au contenu.

Si Obsidian n'est pas disponible, j'ouvre les fichiers dans un éditeur de texte. Lorsqu'un outil d'agent est supprimé, son adaptateur pointe vers le même dossier. Lorsqu'un moteur de mémoire supplémentaire est ajouté, il peut indexer le contenu existant, mais ne doit pas le remplacer.

Cela semble simple. Pour éviter que cela ne redevienne au quotidien un tas de documents en désordre, sept règles strictes s'imposent.

Règle n° 1 : le Markdown est la source de la vérité

Les personas, les règles de travail et les connaissances sélectionnées sont disponibles au format Markdown. Une recherche sémantique, un index vectoriel ou un moteur de mémoire peuvent permettre d'en générer une vue plus rapide. Cependant, cette dérivation ne constitue jamais la seule source d'information.

Cela permet non seulement d'éviter la dépendance vis-à-vis d'un outil, mais aussi de rendre les corrections vérifiables. Je peux voir dans le diff quelle phrase a été modifiée, au lieu de me fier à un processus de mémoire invisible qui aurait déjà enregistré la bonne version.

Règle n° 2 : un persona n'a qu'un seul « cerveau »

Un même agent ne doit pas se voir attribuer une version légèrement différente de son identité dans chaque outil. Claude, Codex, Gemini et Hermes doivent accéder aux mêmes fichiers canoniques.

Sinon, on assiste à un « glissement de persona » : une nouvelle règle de validation s'applique dans un outil, tandis que l'ancien outil continue d'utiliser l'ancienne règle. Ou bien une correction n'apparaît que dans une invite du système et est perdue lors du prochain changement de compte.

Une source empêche ces dérivations silencieuses.

Règle n° 3 : les adaptateurs doivent rester fins

Un « harness » est l'outil dans lequel un agent travaille. Pour cela, chaque système a besoin d'une passerelle adaptée : un fichier de configuration, un briefing de projet ou une invite système.

Ces adaptateurs ne doivent remplir que trois fonctions : trouver le dossier d'agent approprié, indiquer l'ordre de lecture et demander la réécriture en mémoire. La persona, l'expertise et la gouvernance ne sont pas copiées dans l'adaptateur.

Plus le pont est fin, plus il est facile de le remplacer.

Règle n° 4 : les connaissances partagées font l'objet d'une référence

Plusieurs agents doivent utiliser la même voix de marque, les mêmes règles typographiques ou les mêmes conventions de sécurité. Ces contenus sont stockés dans un espace commun et sont chargés à partir de là.

Je ne les copie pas dans chaque dossier d'agent. Une modification apportée à la source commune doit s'appliquer à tous les rôles concernés. Les copies ne seraient plus synchronisées dès la première modification.

Cette règle n'a rien d'exceptionnel. C'est justement pour cela qu'elle est importante. L'infrastructure n'a rien de très attrayant. Mais elle dure plus longtemps que les fonctionnalités.

Règle n° 5 : l'écriture a lieu à la fin de la session

Un système de fichiers ne conserve en mémoire que ce qui se trouve effectivement dans les fichiers. C'est pourquoi une entrée dans la mémoire journalière est nécessaire à la fin d'une session d'agent.

Ce document ne contient pas l'intégralité de la conversation. Il consigne les décisions prises, les étapes franchies, les constatations importantes et les points en suspens. Par la suite, les connaissances acquises au quotidien sont transformées en connaissances à long terme triées et sélectionnées ou en une leçon durable.

Sans cette routine, le référentiel ne serait qu'un simple recueil statique d'invites.

Règle n° 6 : les étapes d'approbation sont explicitement définies

Chaque agent productif définit ce qu'il est autorisé à faire lui-même et les cas où une personne doit prendre une décision. Dans le cas de Sol, par exemple : elle est autorisée à créer des brouillons, mais ne peut rien publier. Un autre agent est autorisé à modifier le code, mais ne peut pas déclencher de déploiement en production sans validation.

Ces limites sont définies au niveau de l'agent, et pas seulement dans une interface. Elles sont donc conservées lors du changement d'outil.

Règle n° 7 : le cerveau n'est pas un « secret store »

Un référentiel privé n'est pas forcément l'endroit idéal pour tous les types de contenu. Les secrets en clair n'ont jamais leur place là-bas. Les personas liés aux clients et les contenus de travail confidentiels restent dans leur contexte de projet protégé respectif.

Le « cerveau » central ne contient que ce qui doit réellement s'y trouver, tous agents confondus. Cette limite fait partie intégrante de l'architecture ; il ne s'agit pas d'un travail de nettoyage a posteriori.

Voici comment est structuré le Vault

La structure concrète est délibérément prévisible :

• On commence par définir les spécifications et les aperçus destinés aux personnes et aux agents.
• Un espace commun regroupe les « Brand Voices », les conventions et les enseignements tirés de l'expérience de tous les agents.
• Les modèles permettent de s'assurer que les nouveaux agents reçoivent les mêmes éléments de base.
• Les adaptateurs de harnais font le lien avec les différents outils.
• Chaque agent dispose de son propre dossier contenant son profil, ses compétences manuelles, ses aptitudes, ses limites et sa mémoire.

Cet ordre est plus important que le nom exact du dossier. Un nouvel agent doit pouvoir comprendre où il a le droit de lire et d'écrire sans avoir à connaître au préalable l'historique complet du projet.

Pourquoi Git et pas une base de données ?

Une base de données permettrait de répondre plus rapidement aux requêtes. Cependant, en ce qui concerne l'identité canonique de mes agents, Git présente trois avantages qui me semblent plus importants.

Lisibilité : Les fichiers Markdown peuvent être ouverts sans logiciel spécifique.

Traçabilité : Un diff montre ce qui a changé. Un commit associe la modification, la date et la justification.

Portabilité : Un dossier cloné peut être réutilisé sur un autre ordinateur et avec un autre outil.

Cela ne signifie pas pour autant que les bases de données ou la recherche vectorielle soient inutiles. Dans ma configuration, elles peuvent être intégrées en tant qu'index ou cache. Elles servent à accélérer le processus, mais ne sont pas les détentrices du savoir.

Obsidian, c'est l'interface, pas la base

J'utilise la racine du référentiel comme coffre-fort Obsidian. Cela me permet d'avoir accès à des liens wiki, à Graph, à la fonction de recherche et à des pages récapitulatives organisées. Pour moi, en tant qu'utilisateur, c'est très utile.

Mais le point important, c'est que : Obsidian enregistre les notes sous forme de fichiers locaux. L'interface peut évoluer sans qu'il soit nécessaire de réécrire le code source.

C'est précisément cette distinction que j'aimerais voir s'appliquer également du côté des agents. Un bon outil a pour but de rendre le travail plus agréable. Il ne devrait pas déterminer si mes connaissances restent lisibles.

Le critère pratique

Un « Agents Brain » n'est portable que si tu peux répondre « oui » à ces trois questions :

1. Peux-tu consulter la persona sans l'outil utilisé jusqu'à présent ?
2. Un autre outil peut-il charger ces mêmes règles sans que tu aies à les copier ?
3. Peut-on voir ce qu'un agent a enregistré de manière permanente à la fin de la session ?

Si la réponse est « non », cela signifie qu'à ce stade, les connaissances se trouvent encore dans l'outil plutôt que dans le cerveau.

Dans la partie suivante, je décompose un agent individuel en ses quatre fichiers principaux : SOUL, MASTER, RULES et MEMORY. Leur séparation permet de transformer une longue invite en une identité de travail plus facile à gérer.

Sources

• Source du projet : Spécification d'agents-brain, structure de Vault et validateurs, version du 15 juillet 2026 (source primaire privée)
• CommonMark : spécification Markdown ouverte
• Pro Git : Qu'est-ce que Git ?
• Aide Obsidian : Comment Obsidian stocke les données