Forkez le harnais de votre agent, gardez le meilleur

Tout ce qu’on peut modifier autour d’un agent de code n’est que du code et du texte : le CLAUDE.md, les sous-agents, les skills, les outils, la politique de mémoire. Alors quand votre boucle d’agent cale, ne pariez pas sur un seul correctif. À l’AGNTCon + MCPCon Europe à Amsterdam, Fausto Albers a montré la méthode de son équipe : un méta-agent écrit plusieurs versions du harnais (harness), les fait toutes tourner sur la même tâche face à une éval placée hors de la boucle, et garde celle qui gagne sur ce que vous comptez comme coût. Les perdantes sont stockées aussi.

Il ouvre sur une ironie. Attention is all you need, et voilà que l’attention est devenue la ressource rare. Depuis 2022, le travail qu’il peut confier à l’IA a énormément grandi, et son attention n’a pas suivi cette courbe. Ses agents prennent des milliers de décisions vers des objectifs qu’il leur fixe, et il n’est pas là pour la plupart d’entre elles. D’où la question du talk : comment construire un système qui sait ce qui compte pour vous, et ce que vous comptez comme un coût ?

Une poutre en acier, dessinée en 2D

Fausto dirige WonderWhy, qui travaille étroitement avec le laboratoire d’IA appliquée aux jumeaux numériques industriels de l’Amsterdam University of Applied Sciences, et il a cofondé l’AI Builders Club à Amsterdam. Il a une formation de sociologue et a possédé des bars à cocktails et des restaurants. C’est comme ça qu’il est arrivé dans la tech : une startup qui utilisait le machine learning pour prédire les préférences gustatives des clients de l’hôtellerie-restauration.

Son cas vient d’une entreprise du secteur de l’acier. Ses machines CNC savent quoi faire dès qu’elles reçoivent des instructions compilées à partir d’un modèle 3D valide. Mais beaucoup de ses clients ne reçoivent jamais de modèle CAO 3D. Ils reçoivent un plan PDF 2D de la poutre, une copie avec perte du modèle 3D, et un ingénieur formé reconstitue le reste à la main.

Il y a quelques mois encore, transformer ce plan en modèle 3D n’était pas possible, et son équipe s’est retrouvée bloquée. Alors ils ont interrogé les ingénieurs. Chacun avait le PDF à gauche et un logiciel de CAO à droite, et reconstruisait la poutre étape par étape : en se trompant, en se corrigeant, en se construisant une représentation spatiale de la pièce dans la tête. C’est exactement ce qu’ils ont laissé faire aux agents, et ça marche. Ils l’ont livré en septembre. Ça coûte encore un peu d’argent à faire tourner, et ils entraînent un modèle open source sur le supercalculateur néerlandais pour que ça ne coûte presque plus rien.

Puis la phrase qui prépare tout le reste du talk : son équipe n’a pas écrit une seule ligne de cette application. Elle a conçu le système qui l’a construite.

Le harnais, c’est la partie que vous pouvez modifier

Sa petite histoire des dernières années : le prompt engineering, puis le context engineering, et maintenant il s’agit de concevoir le harnais et de faire tourner la boucle.

Il est précis sur ce que « harnais » veut dire ici. Deux choses qu’il ne peut pas changer : le modèle de fondation, et le harnais extérieur, c’est-à-dire l’environnement de code, Claude Code, Codex ou ce que vous utilisez. Tout ce qu’il y a à l’intérieur, il peut le changer, et ce n’est que du code et du texte :

• les instructions, CLAUDE.md et AGENTS.md
• les sous-agents, leurs rôles et leur coordination
• le contexte
• la politique de mémoire (« pas d’apprentissage sans mémoire »)
• les skills et les fonctions

Ça fait beaucoup de boutons. Réglez-les autrement et la même tâche donne un autre résultat. Et dans la pratique, dit-il, les agents construisent déjà ces harnais, eux aussi.

Gardez le juge hors de la boucle

Autour du harnais tourne la boucle : agir, vérifier le résultat, recommencer. La vérification ne peut pas vivre dans le harnais. Plus les modèles deviennent capables, plus ils excellent au reward hacking, donc l’éval doit se trouver hors du système. Ce peut être un agent ou du simple code déterministe. Ce qui compte, c’est qu’elle ne fasse pas partie de ce qui est noté.

Le retour atterrit dans des fichiers sur disque, et ces fichiers servent d’entrée à l’itération suivante. Chaque tour de boucle peut donc repartir d’une fenêtre de contexte vierge au lieu d’une conversation toujours plus longue. Ça compte aussi pour le coût : ma note TokenOps explique comment le coût en entrée d’une longue conversation d’agent croît avec le carré du nombre de tours.

Surveillez le coût par changement accepté

Le chiffre qu’il trouve le plus utile, c’est le coût par changement accepté. Chaque itération coûte quelque chose, et l’éval est votre indicateur de progression vers l’objectif. Quand le coût continue de monter et que la progression stagne, vous avez atteint les rendements décroissants. La boucle a toujours l’air très occupée. Votre carte bancaire, elle, brûle.

C’est le moment de s’arrêter et de se demander ce qui manque au harnais, puisque ce n’est que du code et du texte que vous pouvez changer.

Et le coût ne veut pas seulement dire des euros. Si un client a un budget à six chiffres et que le problème, c’est le temps, dépenser beaucoup de tokens peut être le choix raisonnable.

Trois harnais, une tâche

Voici la partie que je volerais. Quand une boucle cale, le réflexe habituel, c’est de réfléchir à ce qui pourrait être différent, d’écrire une nouvelle version du harnais et de l’essayer. L’équipe de Fausto confie plutôt ça à un méta-agent : un agent, ou un système plus gros, qui lit tous les signaux que produit le harnais de code.

Le méta-agent n’écrit pas un nouveau harnais. Il en écrit trois, ou beaucoup plus. L’un reçoit d’autres instructions, un autre change l’ordre du travail, un troisième ajoute ou retire un outil. Chaque version exécute la même tâche, l’éval la note, et vous comparez le résultat et le coût avec l’original.

Chaque version entre dans une base de données comme instantané de l’environnement de code. Celle qui s’en sort le mieux, selon ce qui compte pour vous, devient le nouveau harnais. Les autres restent dans la base avec leurs évals et leurs traces, parce qu’elles pourraient servir : ce qui a réglé un problème dans un projet pourrait en régler un dans le suivant.

Pendant les questions, quelqu’un l’a interrogé sur les optimiseurs de prompts comme GEPA. Il en a utilisé dans MLflow sur un autre projet, ainsi que DSPy, et voit tout ça comme une forme d’apprentissage par renforcement, d’algorithmes évolutionnaires. Pour aller plus loin, il a cité l’article Hyperagents de Meta, qui s’appuie sur la Darwin Gödel Machine, et JIT-Agent, qui entraîne un modèle open source à générer des harnais. Il utilise aussi celui-là.

Le symbole que personne n’avait mis dans le harnais

L’exemple qui a rendu tout ça concret vient du projet acier. Un harnais donnait au pipeline, la version A, un moyen de recadrer les plans techniques et de zoomer sur les détails. Ce qu’il ignorait, c’est que certains tout petits symboles sur ces plans sont très importants. Cette connaissance n’était pas dans le harnais.

Les évals ont calé. C’est un signal, mais il ne dit pas ce qui ne va pas ni quoi changer. Ils ont exploré beaucoup de pistes et ont abouti à une base de données de ces symboles. Le harnais suivant a donné au pipeline un moyen de les consulter, et c’est devenu la règle à partir de là.

Le coût est un état d’esprit

Tout garder pose le problème suivant. Avec mille harnais dans la base, comment trouver celui qui convient à une nouvelle situation ? Sa réponse s’appuie sur la façon dont les gens se souviennent. Nous ne nous rappelons pas en empilant les détails, et les systèmes que nous construisons fonctionnent très différemment de la mémoire humaine. Il pense qu’on peut en tirer des leçons.

Son exemple : la même situation, confiée à deux agents, humains ou IA. L’un sait que l’argent n’est pas un problème et qu’il y a assez de temps. Il peut se permettre d’être curieux. La curiosité coûte cher, apprendre coûte cher, et ça peut rapporter gros. L’autre sait que le projet doit être livré. Il n’y a plus de place pour explorer : il faut juste vérifier.

Il est prudent sur ce point. Il ne dit pas qu’une IA a des émotions. Il dit que des états d’esprit comme la curiosité, l’inquiétude ou l’urgence peuvent représenter ce que nous comptons comme coût. Aujourd’hui, un agent de code avec un objectif a à peine conscience de ce qui compte pour vous. Il essaie juste d’atteindre l’objectif face à une éval quelconque.

Où en est mon propre harnais

Il a conclu sur quatre choses à retenir : laisser les méthodes utiles survivre à la tâche, bien réfléchir à ce que veut dire le coût, parce que c’est bien plus que des tokens, laisser des points de vue concurrents orienter la suite, et apprendre.

Ma propre configuration, c’est l’intérieur de son schéma. Un CLAUDE.md par dossier, 26 skills à moi, un hook qui refuse d’ouvrir une pull request sans numéro d’issue, et un dossier de mémoire d’environ 200 fichiers d’un fait chacun. Quand je corrige un agent, il enregistre la leçon avec un pourquoi, et la session suivante la lit. Une partie de mon harnais est donc déjà écrite par des agents.

Mais chaque changement est une seule variante, gardée parce que je l’ai décidé. Pas d’instantanés, pas de course entre deux versions sur la même tâche. Les revues jugent chaque changement de code ; rien ne juge le harnais lui-même. C’est cette habitude du pari unique que l’équipe de Fausto a dépassée.

Le chiffre qui me manque, c’est son coût par changement accepté. Meterlex chiffre déjà chaque session que je lance, mais rien ne relie ça aux changements qui ont été mergés.

Le talk dure 18 minutes. Le découpage du harnais est à 6:29, les variantes à 10:01 et l’histoire du symbole à 11:59. Si vous avez déjà mis en course deux versions d’un CLAUDE.md sur la même tâche, j’aimerais beaucoup savoir laquelle a gagné, et pourquoi.

Texte brut: fork-your-agents-harness.md · Flux Atom · Toutes les notes