Le même agent, quatre outils différents

Ce que tu vas en retirer : Tu vois comment des adaptateurs légers permettent d'appliquer la même identité d'agent à différents harnesses – et pourquoi les règles d'autorisation doivent être transférées lors du changement d'outil.

Pour moi, un agent, ce n'est pas la fenêtre de chat dans laquelle je suis en train de discuter avec lui.

La fenêtre est son outil actuel. Dans « Agents Brain », j'appelle ce mode d'exécution un « harness ». L'identité se trouve ailleurs : dans les fichiers canoniques de l'agent.

Cette séparation permet un changement de corps. Claude Code, Codex, Gemini et Hermes nécessitent des approches différentes. Il ne faut toutefois pas qu'ils reçoivent quatre copies d'un même personnage.

Il existe des adaptateurs fins pour cela.

Ce qu'un adaptateur doit vraiment faire

Un adaptateur assure la liaison entre le faisceau et le « Brain ». Il contient le moins de logique propre possible.

Ses missions sont claires :

1. trouver le dossier canonique des agents,
2. indiquer l'ordre de lecture obligatoire,
3. Charger explicitement les « Approval-Gates »,
4. exiger la réécriture quotidienne de la mémoire à la fin de la session.

Ce qui n'a pas sa place ici : un profil complet copié, des connaissances techniques dupliquées ou une deuxième version des règles de validation.

Dès que ce type de contenu arrive dans l'adaptateur, la dérive commence. Une correction est alors effectuée dans le Brain, mais elle est oubliée dans l'ancien briefing de l'outil. Au prochain démarrage, il existe deux vérités.

Quatre outils, quatre ponts

L'aspect des adaptateurs varie en fonction de l'outil.

Claude Code lit les instructions relatives au projet et les définitions d'agents. Le pont renvoie ensuite vers le dossier d'agents souhaité et indique l'ordre de démarrage de ceux-ci.

Codex utilise un briefing de projet. Là encore, le contenu reste générique : quel agent est compétent par défaut, où se trouve son « cerveau » et que faut-il rédiger avant la réponse finale ?

Gémeaux reçoit un fichier de projet correspondant, contenant le même contrat, dans le format souhaité.

Hermès charge l'identité via une invite système ou un « thin bridge ».

La syntaxe change. Le contrat reste le même.

C'est le chemin de l'agent qui se déplace, et non la copie de la persona

Lorsqu'un orchestrateur délègue une tâche à un autre harnais, le profil n'est pas copié dans la commande. À la place, la cible reçoit l'instruction de relire le dossier canonique des agents.

Cela présente deux avantages.

Premièrement, la mission reste de petite envergure. Deuxièmement, le travail préparatoire tient compte de l'état d'avancement actuel, y compris les nouvelles leçons et les étapes de validation modifiées.

Une persona copiée est potentiellement obsolète dès l'instant où elle est envoyée. Un lien vers la source reste plus fiable.

Bien sûr, cela suppose que l'autre harnais ait accès au « Brain ». C'est précisément pour cette raison que le chemin d'accès fait partie de la configuration locale et ne figure pas dans l'adaptateur public en tant que chemin privé câblé.

Les « Approval-Gates » ne changent pas de propriétaire

L'élément essentiel du principe de l'adaptateur n'est pas la persona. Ce sont les limites.

Sol peut préparer des textes et des brouillons WordPress. Elle ne publie rien elle-même. Si Nox lui confie une mission via Codex plutôt que via Claude Code, cette règle ne change pas. Même un environnement d'exécution particulièrement performant ne bénéficie pas pour autant d'une autorisation supplémentaire.

Il en va de même pour les actions destructrices, les déploiements ou les opérations payantes effectuées par d'autres rôles. La délégation élargit le flux de travail. Elle n'étend pas automatiquement l'autorisation.

C'est pourquoi RULES et MASTER sont chargés à chaque démarrage. Un adaptateur qui ne transmet que la tonalité est trop rudimentaire. Un bon adaptateur transmet l'intégralité du contrat de travail en renvoyant à sa source.

Quatre niveaux d'évaluation au lieu d'une note globale

Le fait qu'il y ait quatre fichiers d'adaptation dans le référentiel ne prouve pas encore qu'un agent soit pleinement opérationnel dans quatre outils. C'est pourquoi je distingue quatre niveaux de validation :

1. Contrat et adaptateur : Le pont redirige vers le « Brain » approprié, charge les fichiers requis et gère les étapes de validation.
2. Contrat en lecture seule : Le Harness démarre effectivement et lit l'identité, les règles et la mémoire dans l'ordre prévu.
3. Récupération via un clone « Fresh » : Le Brain peut être restauré à partir du référentiel dans un environnement isolé, sans dépendances locales cachées.
4. Exercice réel avec réécriture : Le Harness remplit une fonction concrète : il gère les portes, renvoie l'entrée quotidienne requise, et un autre processus peut la lire à son tour.

Ces étapes s'enchaînent les unes après les autres. Si on les mélange, on transforme rapidement une configuration existante en une preuve pratique inventée de toutes pièces.

Étape 1 : Contrat et adaptateur

Le référentiel vérifie les fichiers des adaptateurs et des agents à l'aide de validateurs. Il contrôle notamment les séquences de démarrage, les fichiers obligatoires, les points de validation, les références Brain Root et les copies indésirables de personas.

Ces tests contractuels permettent par exemple de repérer des noms concrets qui se sont glissés par inadvertance dans des modèles portables. Les ponts locaux et spécifiques à une personne peuvent être concrets. Les modèles canoniques doivent rester génériques.

Les tests automatisés permettent ainsi de prouver le transfert de fichiers. La connexion, la durée d'exécution et le réécriture effective en mémoire doivent faire l'objet de justificatifs distincts.

Étape 2 : le contrat de lecture seule

Claude Code, une nouvelle exécution de Codex et Hermes ont chargé, dans des environnements de test en lecture seule distincts, le même ordre de démarrage contraignant à partir du même coffre-fort. Tous trois ont lu le même contrat mémoire et sont parvenus à une évaluation sémantiquement identique pour la même condition de vérification.

Le contrat de lecture commun pour ces trois harnesses est donc pratiquement validé. Ces exécutions ne constituaient toutefois pas un test de réécriture. Elles ne montrent ni une tâche réelle accomplie, ni une entrée du journal quotidien qui aurait été renvoyée au Brain via le harness correspondant.

Des adaptateurs et des tests de contrat sont disponibles pour Gemini. Le lancement effectif avec ce même contrat de lecture n'a pas encore eu lieu.

Étape 3 : Récupération à partir d'un clone « fresh »

Le script automatisé « Recovery-Smoke » clone le référentiel dans un répertoire temporaire isolé, génère un agent « Draft » et un « Claude-Bridge » à partir des modèles d'origine, puis vérifie l'écriture et la relecture d'un fichier Markdown quotidien entre des processus distincts. Seules la bibliothèque standard Python et Git sont utilisées à cette fin. Obsidian, OpenViking et les CLI Harness locales sont délibérément absents.

Le « Fresh-Clone » vert démontre que l'identité, les portes et la routine mémoire peuvent être restaurées à partir du seul « Vault ». Il ne s'agit pas d'un test E2E d'un harnais spécifique. Il ne prouve donc ni l'exécution complète du code Claude, ni le démarrage de Gemini.

Étape 4 : L'exercice proprement dit avec « write-back »

La preuve la plus solide n'apparaît qu'au cours de l'exécution de l'outil : l'agent traite une commande réelle, respecte les étapes de validation et renvoie le rappel prescrit. Ensuite, un cycle indépendant doit pouvoir recharger cette entrée à partir du Brain.

Pour Claude Code, Codex et Hermes, la preuve du mode « lecture seule » est établie dans cette comparaison. Aucun des trois n'est ici soupçonné d'un tel contournement des tâches ou d'un contournement de type « write-back ». Quant à Gemini, la question du contrat de lecture réel reste encore en suspens.

Ce n'est qu'à l'issue de cet examen distinct qu'il est possible de déterminer avec précision le niveau de maturité de chaque harnais. La réussite d'un niveau vert ne garantit pas automatiquement la réussite du niveau suivant.

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

La métaphore est utile tant qu'elle reste techniquement correcte.

Le corps fournit des outils : accès au modèle, terminal, navigateur, Cron, passerelle ou interface utilisateur. Le cerveau apporte le rôle, le savoir-faire, les limites et la mémoire. Un changement modifie les capacités et l'environnement, mais pas automatiquement l'identité canonique.

Cela ne fonctionne que si les deux aspects restent distincts. Dès que le corps accumule ses propres connaissances, non reflétées, il fait à nouveau partie de la mémoire.

Dans la dernière partie, je dresse le bilan pratique : ce qui est réellement transférable, quelles lacunes sont apparues et quelles justifications font encore défaut.

Sources

• Source du projet : Spécification agents-brain, adaptateur Harness, validateur Interop/Fresh-Clone et protocoles de test internes (sources primaires privées)
• Pro Git : Qu'est-ce que Git ?