Mes agents IA n'appartiennent pas à leur outil

Ce que tu vas en retirer : Pourquoi l'identité de mes agents IA se trouve dans des fichiers séparés plutôt que dans l'outil concerné, comment six programmes différents parviennent malgré tout à charger la même équipe – et comment j'évalue ce qui fonctionne efficacement.

À l'origine, « Mein Agents Brain » est né d'un problème : mon équipe d'IA était en grande partie prisonnière d'un seul outil (Harness) : l'orchestration en cours, les canaux, les automatisations déjà mises en place. J'ai pu conserver les fichiers Markdown de mes agents, mais j'ai dû tout reconstruire à partir de zéro.

Depuis, je conçois mes programmes de manière à ce que cela ne se reproduise plus. L'identité de mes agents, leurs autorisations et ce qu'ils ont appris sont consignés dans des fichiers qui, d'une part, m'appartiennent et, d'autre part, dont je peux retracer toutes les modifications. Le programme dans lequel un agent s'exécute actuellement est en revanche interchangeable – les spécialistes appellent cet environnement d'exécution un « harness », mais je dis généralement simplement : son corps actuel.

Un agent, ce n'est pas simplement la fenêtre de chat dans laquelle je suis en train de lui parler. Cette fenêtre n'est que l'endroit où il travaille aujourd'hui. Tu découvriras ici comment ce même agent peut fonctionner dans différents outils sans que j'aie à le réinventer à chaque fois.

Ce que cette séparation m'épargne

Cela ressemble à un détail architectural. Mais pour moi, il s'agit d'une décision commerciale.

J'ai pu constater à quel point un outil peut rapidement nécessiter plus d'entretien qu'il n'en facilite le travail avec OpenClaw en janvier et février 2026. Dans un tel cas, je veux pouvoir changer de solution sans perdre mon équipe – dans le domaine des achats, le problème que j'évite ainsi s'appelle la dépendance vis-à-vis d'un fournisseur. Mes agents ne dépendent d’aucun fournisseur en particulier, car aucune fonctionnalité essentielle n’est propre à son produit.

À cela s'ajoute la continuité. Lorsque j'enseigne une méthode de travail à une agente ou que j'instaurer une correction de manière permanente, cela doit perdurer au-delà du prochain changement d'outil. Sinon, après chaque déménagement, on retombe dans cette phase fastidieuse où l'équipe ne connaît pas ses propres règles.

Et comme mon autrice Sol écrit sous mon nom, il y a une troisième raison : la fiabilité des validations. Le fait qu'elle ne publie jamais elle-même ne doit pas dépendre de l'outil qu'elle utilise aujourd'hui. Je reviendrai là-dessus dans un instant.

Un petit fichier indique à l'outil où se trouve l'agent

Pour qu’un outil puisse charger un agent, un pont est nécessaire. Dans mon cas, il s’agit d’un petit fichier de configuration, l’adaptateur : il pointe vers le dossier de l’agent dans Brain – le dépôt Git privé dans lequel tous ces fichiers sont gérés en version – définit l’ordre de lecture au démarrage, charge explicitement les règles de partage et exige que l’agent réinscrive une entrée journalière dans sa mémoire à la fin d’une session (ce qu’on appelle le « write-back »).

Ce qui n'a pas sa place dans le système est tout aussi important : pas de copie de la personnalité, pas de duplication des connaissances spécialisées, pas de deuxième version des règles de validation. Toute copie commence à devenir obsolète dès qu'elle existe. C’est exactement ce que j’ai fait une fois : dans une configuration initiale, une copie composite du persona se trouvait sur le système cible, et j’ai compris qu’elle deviendrait erronée dès la prochaine correction dans Brain. Le jour même, je suis passé à des références directes, et depuis, je veille à ce que ces fichiers restent légers.

Six ponts vers le même cerveau

Il existe désormais de tels ponts pour six outils. Claude Code, d’Anthropic, lit les instructions relatives au projet, y compris les définitions d’agents. Codex – l’outil en ligne de commande issu de l’univers ChatGPT d’OpenAI – reçoit un briefing sur le projet. Google Gemini attend un fichier de projet dédié, tandis qu’Hermes, de Nous Research, charge l’identité via une invite système. Kimi Code, de Moonshot AI, et Grok Build, de xAI, les deux derniers arrivés, disposent chacun de leurs propres formats d’agents.

Six formats, six syntaxes différentes. Sur le fond, cependant, le contenu est partout le même : l'adresse de l'agent, les informations à lire au démarrage, les autorisations en vigueur et les données réécrites à la fin.

C'est selon ce même principe que mes agents se transmettent le travail entre eux. Lorsque Nox – mon orchestrateur, c'est-à-dire l'agent qui répartit les tâches et en assure la supervision – délègue une mission à un autre outil, il ne copie pas la persona dans le texte de la mission. Il écrit en substance : « Travaille en tant que Sol, lis d’abord ses fichiers. » La cible charge ainsi toujours la version la plus récente, y compris les dernières corrections.

Les règles de validation sont intégrées

Les limites constituent la partie la moins négociable de ce système. Sol peut rédiger des textes et les enregistrer sous forme de brouillon dans WordPress ; elle n’a pas le droit de les publier, c’est moi qui en décide. Cette règle figure dans ses propres fichiers d'agent – dans RULES, son contrat de travail précisant ses compétences et ses autorisations, et dans MASTER, son manuel détaillé – et ces deux fichiers sont chargés à chaque démarrage, quel que soit l'outil utilisé.

Si Nox lui confie donc cette tâche via Codex plutôt que via Claude Code, cela ne change rien à cette autorisation. Même l’outil le plus performant ne se voit pas attribuer de droits supplémentaires simplement parce qu’il offre davantage de fonctionnalités : un processus de délégation plus long ne transforme pas une autrice en éditrice. Il en va de même pour tout ce qui implique des coûts, la suppression d’un élément ou la mise en ligne d’un contenu : ces étapes restent de ma responsabilité, quel que soit l’outil utilisé.

Quatre étapes entre la promesse et la preuve

À ce stade, je pourrais affirmer : six outils, une équipe, tout fonctionne. Mais six fichiers d'adaptation ne prouvent pour l'instant absolument rien : un fichier de configuration est une promesse, mais cela ne signifie pas pour autant que le système est opérationnel. C'est pourquoi je vérifie chaque élément en quatre étapes et je ne m'avance qu'en fonction des résultats obtenus à chaque étape.

Dans un premier temps, des scripts de test automatiques vérifient l'état du papier. Le pont pointe-t-il vers le « Brain » approprié ? Les fichiers obligatoires sont-ils chargés ? Les règles d'autorisation y figurent-elles ? Ces tests détectent également les petits détails, par exemple lorsqu'un nom spécifique se retrouve par inadvertance dans un modèle générique.

À la deuxième étape, l'outil doit réellement se lancer et lire l'identité dans l'ordre prévu – en lecture seule, sans rien modifier. Ce n'est qu'alors que je sais que le système charge bel et bien le persona, et qu'il ne se contente pas simplement de pouvoir le charger.

La troisième étape correspond à mon test d'urgence. À partir d’une copie fraîche du dépôt, dans un environnement volontairement dépouillé dépourvu de mes programmes habituels, il doit être possible de restaurer un agent, avec ses règles et sa routine de mémoire, en utilisant uniquement Git et les outils Python intégrés. Si cela fonctionne, le système ne dépend d’aucune installation cachée sur mon ordinateur.

La quatrième étape correspond à la mise en œuvre complète : l'agent effectue une tâche réelle dans l'outil en cours d'exécution, respecte ses délais de validation et enregistre l'entrée du jour dans sa mémoire. Ensuite, un deuxième cycle indépendant doit pouvoir relire cette entrée. Ce n'est qu'alors que je considère un système comme pleinement opérationnel.

Les étapes s'enchaînent les unes après les autres, et aucune ne remplace la suivante. En les mélangeant, on transforme rapidement une configuration existante en une démonstration pratique inventée de toutes pièces.

Où se trouvent aujourd'hui les six corps

Cinq des six ont désormais de véritables cycles derrière eux – mais pas tous au même niveau, et c’est exactement ce que je dis. Hermès est le corps dans lequel Nox travaille de toute façon quotidiennement et tient son journal. Claude Code a réussi l’épreuve complète : tâche réelle, délais respectés, entrée quotidienne rédigée et relue de manière autonome. Grok Build, le dernier arrivé, a lui aussi réussi cette épreuve entre-temps. Deux restrictions s’appliquent à cette attestation : les cycles non supervisés ont nécessité plusieurs prolongements explicites de la même session, et la mémoire à long terme intégrée de Grok reste délibérément désactivée – la mémorisation s’effectue exclusivement dans le Brain.

Codex a démontré à plusieurs reprises, de manière concrète, l'existence de ce contrat de lecture commun, notamment lors d'une comparaison directe avec Claude Code et Hermes : tous trois ont lu la même séquence initiale issue du même « Brain » et sont parvenus à la même interprétation. Kimi Code a effectué un premier véritable cycle, en se limitant jusqu’à présent à la lecture. Pour les deux, le cycle complet avec la saisie de l’entrée du jour reste à effectuer – c’est pourquoi cela n’est pas encore affirmé.

Il reste Gemini. Le pont est construit et passe tous les tests contractuels, mais il n’y a pas encore eu de véritable mise en service – et cela ne tient désormais plus à ma configuration : Google a supprimé l’accès gratuit à cet outil et renvoie vers un produit de remplacement. Je prendrai le temps de décider si je passe à ce nouveau produit, si j’opte pour un accès payant ou si je mets Gemini en attente pour l’instant. D’ici là, Gemini figure dans ma liste pour ce qu’il est : prêt, mais pas utilisé.

Pourquoi je parle quand même de « changement de corps »

La métaphore tient la route tant qu’elle reste techniquement correcte. Le corps apporte les capacités : accès au modèle, terminal, navigateur, gestion du temps, interface. Le « cerveau » fournit le rôle, le savoir-faire, les limites et la mémoire. Un changement modifie donc ce qu’un agent est capable de faire et où il travaille – et non qui il est.

Cela ne fonctionne que tant que les deux parties restent distinctes. Dès qu’un corps commence à accumuler ses propres connaissances, qui ne se reflètent nulle part ailleurs, il redevient partie intégrante de la mémoire – et je redeviens dépendant d’un seul outil.

Si tu te demandes si cet effort en vaut la peine au quotidien : c'est précisément le bilan que je dresse dans la dernière partie – ce qui était réellement transférable lors du changement de corps, quelles lacunes sont apparues et quelles preuves font encore défaut.

Sources

• Source du projet : Spécification agents-brain, six adaptateurs Harness, scripts de test Interop et Fresh-Clone, ainsi que des journaux d'exécution internes (sources primaires privées)
• Pro Git : Qu'est-ce que Git ?