Agent Harnesses : l'infrastructure derriere des agents IA fiables

Beaucoup de demos d'agents IA se ressemblent au debut : connecter un bon modele, ajouter quelques outils, ecrire un bon prompt et laisser le systeme traiter une tache. Cela peut suffire pour une demo. Cela ne suffit pas pour la production. Les agents de production doivent memoriser le contexte utile, utiliser des outils de maniere sure, recuperer apres echec, respecter les permissions, verifier leur propre travail et continuer a operer lorsqu'une tache dure plus qu'une simple reponse de modele. Le modele compte, mais le systeme autour du modele decide si l'agent reste utile au quotidien. Ce systeme est souvent appele agent harness, agent runtime, couche d'orchestration, environnement d'execution ou agent scaffolding. Dans cet article, nous utilisons "agent harness" pour designer le runtime et la couche d'orchestration autour du modele. D'autres equipes emploient agent framework, orchestration layer, execution runtime ou agent scaffolding pour la meme couche.

Qu'est-ce qu'un agent harness

Un agent harness est l'infrastructure logicielle qui transforme un modele de langage sans etat en agent operationnel. Le modele predit, planifie et realise une inference proche du raisonnement. Le harness lui donne un environnement controle dans lequel il peut agir. Un harness de production comprend souvent :

des boucles d'orchestration
l'enregistrement et l'execution des outils
la gestion du contexte
la memoire court terme et long terme
la persistance d'etat
les controles de permissions
l'execution en sandbox
les retries et la gestion d'erreurs
les boucles de verification
les traces et l'observabilite
le routage de modeles
la delegation a des sous-agents

Sans cette couche, un agent IA reste en general plus proche d'une interface de chat ou d'un assistant a etape unique. Avec cette couche, il peut devenir un moteur de workflow. Par exemple, un utilisateur peut demander a un agent de corriger un bug de checkout. Un modele peut suggerer ou regarder. Un harness permet a l'agent d'inspecter le depot, chercher des fichiers, editer du code, lancer des tests, lire les erreurs, reparer le patch, verifier le diff et s'arreter uniquement lorsque le resultat est valide. Cette difference devient le produit.

Pourquoi le harness prend plus d'importance

Les equipes IA constatent que deux produits utilisant le meme modele peuvent produire des resultats tres differents. La raison se situe dans l'infrastructure. Les modeles frontier progressent vite. A mesure que des capacites comme tool use, structured output, long context, code generation et l'inference proche du raisonnement deviennent disponibles chez davantage de fournisseurs, une plus grande partie de l'avantage produit se deplace vers l'environnement autour du modele. Le travail sur le harness se cumule lui aussi. Chaque echec peut devenir une amelioration durable :

Si un agent appelle des outils avec de mauvais arguments, on renforce schemas et validation.
S'il perd des decisions precedentes, on ameliore contexte et memoire.
S'il effectue des changements risquee, on ajoute des garde-fous de permission.
S'il declare un travail termine trop tot, on ajoute de la verification.
S'il repete des appels couteux, on ameliore cache ou routage.
S'il se degrade avec un contexte long, on ajoute compaction et retrieval.

Les corrections de prompt aident, mais ne suffisent pas. Le comportement durable vient du design du runtime.

Prompt engineering, context engineering et harness engineering

Ces termes sont lies, mais ne sont pas identiques. Prompt engineering est la couche d'instructions. Elle indique au modele quel role suivre, quelles contraintes importent et comment repondre. Context engineering est la couche d'information. Elle decide ce que le modele voit, quand il le voit et quelle part appartient a la fenetre courante. Harness engineering est la couche d'execution complete. Elle inclut prompts et contexte, mais aussi outils, etat, securite, memoire, verification, files d'attente, observabilite et cycle de vie. Cette distinction compte parce que les prompts demandent un comportement, alors que les harnesses l'imposent. Un prompt peut dire : "Ne supprime pas de fichiers sans permission." Un harness peut bloquer les commandes destructives tant que l'utilisateur ne les a pas approuvees. Un prompt peut dire : "Verifie ton travail." Un harness peut lancer les tests, inspecter la sortie et empecher la finalisation lorsque la verification echoue.

Comment fonctionne un agent harness

La plupart des agent harnesses suivent une boucle. D'abord, le harness assemble l'entree du modele. Cette entree peut inclure le prompt systeme, les instructions developpeur, la demande utilisateur, les definitions d'outils, la memoire, l'etat courant de la tache et le contexte selectionne depuis des fichiers ou des bases de donnees. Ensuite, le modele repond. Il peut renvoyer du texte, des donnees structurees, des appels d'outils ou une demande de deleguer le travail a un autre agent. Le harness classe ensuite cette sortie. Si le modele a produit une reponse finale, la boucle peut s'arreter. S'il a demande un outil, le harness valide l'appel. La validation est critique. Le harness verifie si les arguments correspondent au schema, si l'outil est disponible, si l'action est sure et si l'utilisateur ou le systeme a accorde la permission. Puis l'outil s'execute. Il peut lire des fichiers, interroger une base, chercher des documents, appeler une API, lancer du code, ouvrir un navigateur ou ecrire un patch. Le resultat revient ensuite au modele comme observation. Si l'outil echoue, l'erreur doit etre emballee assez clairement pour que le modele puisse se reprendre. La boucle continue jusqu'a ce que l'agent atteigne un point d'arret verifie, atteigne une limite de budget, demande une intervention humaine ou soit interrompu. Cela parait simple. La qualite de production vit dans chaque detail autour de cette boucle.

Elements centraux d'un harness de production

1. Boucle d'orchestration

La boucle d'orchestration pilote les tours de l'agent. Modeles courants :

ReAct : raisonner, agir, observer, repeter
plan and execute : produire un plan puis l'executer
generate, test, repair : produire un resultat, le verifier, corriger les echecs
gather, act, verify : reunir du contexte, agir, verifier le resultat

La boucle peut etre techniquement petite. La partie difficile consiste a decider quel contexte entre a chaque tour, quelles actions sont autorisees, ce que signifient les erreurs et a quel moment la tache est reellement terminee.

2. Couche outils

Les outils sont la maniere dont l'agent agit sur le monde. De bons outils sont concus pour les modeles, pas uniquement pour les humains. Un humain peut interpreter une sortie CLI bruyante, des valeurs implicites cachees, des drapeaux ambigus et des echecs partiels. Un agent a besoin de limites plus nettes. La couche outils devrait gerer :

noms et descriptions
schemas d'arguments
controles de permissions
sandboxing
execution
formatage des sorties
retries
journaux d'audit

Le design des outils decide souvent de la qualite de l'agent. Trop d'outils embrouillent le modele. Des parametres vagues produisent des appels peu fiables. Des permissions trop larges creent du risque. Les harnesses solides exposent le plus petit ensemble d'outils utile a la tache courante.

3. Gestion du contexte

Le contexte n'est pas du stockage. C'est une surface de travail rare. Les grandes fenetres de contexte aident, mais ne suppriment pas le besoin de selection. Quand des logs sans importance, d'anciennes sorties, de vieux plans et du contenu repete remplissent la fenetre, le modele devient moins fiable. Les harnesses de production utilisent des strategies comme :

charger d'abord de petits index
recuperer fichiers ou enregistrements exacts a la demande
resumer les tours precedents
masquer les anciennes sorties d'outils
conserver decisions et problemes ouverts tout en supprimant le bruit
deleguer l'exploration a des sous-agents qui renvoient des resumes compacts

L'objectif n'est pas le contexte maximal. L'objectif est le plus petit contexte a fort signal qui aide le modele a bien faire l'etape suivante.

4. Memoire

La memoire permet a un agent de conserver de l'information utile entre tours et sessions. La memoire court terme couvre la tache active. La memoire long terme stocke des faits durables, des preferences, des regles de projet et des decisions recurrentes. La memoire de travail peut inclure fichiers de progression, listes de taches ou scratchpads structures. La memoire ne doit pas etre traitee comme une verite. Elle doit etre traitee comme un indice. Si la memoire indique qu'un projet utilise un framework precis, l'agent devrait quand meme inspecter le projet avant d'appliquer des changements specifiques a ce framework. Cela evite qu'une memoire ancienne se transforme en certitude hallucinee. La memoire a aussi besoin d'isolement et de revue, car des faits mauvais ou malveillants stockes peuvent influencer les executions futures. Un systeme de production doit eviter les fuites de memoire entre utilisateurs, equipes, tenants ou frontieres de permission.

5. Persistance d'etat

Les taches de production depassent souvent une seule reponse de modele. Le harness devrait suivre :

ID de session
ID d'execution
statut courant
appels d'outils en attente
fichiers modifies
agents enfants
approbations accordees
cout et usage de tokens
resultat final
statut de livraison

L'etat permet de reprendre une tache apres interruption. Il donne aussi de l'auditabilite : que s'est-il passe, quand, pourquoi et via quel outil.

6. Gestion d'erreurs

Les erreurs sont normales dans les workflows agentiques. Un bon harness separe les types d'erreurs :

les erreurs transitoires doivent etre rejouees avec backoff
les erreurs d'arguments doivent renvoyer un feedback clair au modele
les erreurs de permission doivent demander validation ou choisir une voie sure
les erreurs inattendues doivent arreter avec des diagnostics utiles

Cela compte parce que les taches a plusieurs etapes accumulent les echecs. Meme un taux de reussite eleve par etape peut devenir faible sur une sequence longue. La logique de recuperation n'est pas optionnelle.

7. Guardrails et permissions

Le modele peut decider ce qu'il veut faire. Le harness doit decider ce qu'il a le droit de faire. Des limites de permission utiles incluent :

acces lecture seule vs ecriture
perimetre du workspace
approbation des commandes destructives
approbation des mutations de base de donnees
limites sur les API externes
restrictions d'acces aux credentials
revue humaine avant une action orientee utilisateur

Cette couche doit etre appliquee par le code, pas seulement decrite dans un prompt. Pour les actions a haut risque, l'approbation doit arriver avant l'execution de l'outil, pas apres.

8. Boucles de verification

La verification est l'endroit ou les agents deviennent fiables. Pour des taches logicielles, la verification peut inclure tests, type checks, linters, builds, captures d'ecran, browser checks et revue du diff. Pour des workflows metier, elle peut inclure validation de schemas, contraintes de base de donnees, revue humaine, seuils de confiance, citations de documents et inspection de traces. Une partie de la verification est deterministe. Une autre utilise un modele juge. Les verifications deterministes doivent etre privilegiees quand c'est possible, car elles fournissent une verite de reference plus nette.

9. Observabilite

Les equipes doivent voir comment les agents se comportent. Un harness de production devrait tracer :

prompts et sorties de modele
appels d'outils
resultats d'outils
erreurs
retries
approbations
usage de tokens
latence
resultats de verification
resultats finaux

Sans observabilite, les equipes ne peuvent pas ameliorer le systeme. Elles ne peuvent que deviner pourquoi il a echoue.

Sous-agents et gestion du cycle de vie multi-agents

Une fois qu'un agent peut lancer d'autres agents, le probleme change. Les sous-agents sont utiles lorsque le travail peut etre decoupe. Un agent peut inspecter la documentation pendant qu'un autre relit du code. L'un peut tester l'interface pendant qu'un autre corrige la logique backend. L'un peut rechercher des sources pendant qu'un autre redige le brouillon. Mais lancer des sous-agents n'est pas la meme chose que les gerer. La gestion du cycle de vie multi-agents commence lorsque le runtime possede de nombreux agents actifs dans le temps. Un systeme multi-agents serieux a besoin de :

IDs durables pour les agents enfants
lignage parent-enfant
IDs d'execution
roles et limites de profondeur
files d'attente
annulation
reorientation du travail
evenements de completion
politique de nettoyage
recuperation apres redemarrage

La question cle devient : ou vit l'agent enfant, qui le possede, comment remonte-t-il son resultat et que se passe-t-il si le parent est deja passe a autre chose. Une delegation simple renvoie un resume au parent. La gestion du cycle de vie multi-agents traite la completion comme un probleme de routage. Un enfant peut terminer pendant que le parent est actif, inactif, redemarre ou absent. Le runtime doit livrer ce resultat au bon endroit avec sa provenance intacte. C'est pour cela que les systemes d'agents avances commencent a ressembler a des gestionnaires de processus. Ils ont besoin d'identite, de cycle de vie, de files d'attente, de recuperation et de nettoyage.

Agents manages vs harnesses personnalises

Les plateformes d'agents manages deviennent plus courantes. Elles emballent le harness et l'infrastructure de production pour permettre aux equipes d'aller plus vite. Cela peut etre utile lorsqu'une equipe veut :

lancer plus vite
un runtime heberge
une mise a l'echelle integree
une execution d'outils geree
une observabilite standard
moins de charge d'infrastructure

Mais les agents manages restent aussi une decision d'architecture. Les equipes peuvent encore avoir besoin d'un harness personnalise lorsque :

la qualite du workflow constitue la valeur produit centrale
les outils metier sont tres specifiques
permissions et audit sont stricts
le cout par tache compte
des agents longue duree ont besoin de regles de cycle de vie propres
le risque de verrouillage fournisseur compte
le comportement de l'agent standard sous-performe sur les evals internes

Pour beaucoup d'equipes, la voie pratique n'est ni "tout construire soi-meme" ni "utiliser uniquement un runtime gere". Elle est progressive. Commencez avec les outils existants. Construisez des evals. Identifiez les patterns d'echec. Personnalisez le harness la ou les echecs repetes ou l'economie le justifient.

Quand votre equipe doit s'y interesser

Il faut prendre au serieux le design du harness lorsqu'un workflow IA depasse le stade du prototype. Signes utiles :

les utilisateurs dependent du resultat
les erreurs creent un cout operationnel
le workflow touche des donnees privees ou reglementees
l'agent a besoin d'outils avec effets de bord
la tache comporte de nombreuses etapes
le resultat doit etre verifie
la revue humaine exige une trace d'audit
le cout en tokens devient visible
le comportement de l'agent varie de maniere imprevisible entre executions

A ce stade, le modele n'est qu'une partie du systeme. La fiabilite vient du harness.

Comment nous abordons cela chez Lunover

Chez Lunover, nous traitons les agents IA comme des systemes logiciels de production, pas comme des experiences de prompt. Cela signifie que nous partons de la valeur du workflow. Nous cartographions le vrai processus, les sources de donnees, les risques, les utilisateurs et les criteres de succes avant de construire. Ensuite, nous choisissons le bon niveau de complexite du harness pour le travail. Pour un assistant interne simple, cela peut signifier retrieval, tool use et monitoring de base. Pour un workflow oriente client, cela peut demander des permissions plus strictes, des evals, des fallbacks, de la revue de traces et une approbation humaine. Pour une automatisation longue duree, cela peut exiger un etat durable, des files de jobs, de la recuperation et une responsabilite claire sur chaque action prise par l'agent. Le but n'est pas de rendre l'agent impressionnant en demo. Le but est de rendre le systeme utile apres le lancement. Si votre equipe explore agents, copilots, RAG ou automatisation de workflow, commencez tot avec la question du harness : Que doit voir le modele ? Que peut-il faire ? Que ne doit-il jamais faire ? Comment sait-on que le resultat est correct ? Que se passe-t-il quand quelque chose echoue ? Qui revoit les actions a haut risque ? Quelles donnees survivent apres l'execution ? Ces questions determinent si une fonctionnalite IA devient un workflow fiable ou une interface fragile.

L'idee centrale

La prochaine vague de produits IA ne se gagnera pas uniquement sur le choix du modele. Les modeles apportent l'intelligence. Les harnesses apportent le comportement operationnel. Le harness decide si un agent peut utiliser des outils en securite, gerer le contexte, recuperer d'erreurs, verifier le travail, respecter les permissions et continuer a s'ameliorer dans le temps. Pour les equipes qui construisent de vrais systemes IA, une grande partie du travail d'ingenierie se trouve maintenant ici. Si votre equipe construit des agents IA, des copilots, des systemes RAG ou de l'automatisation de workflows, Lunover peut intervenir via Developpement IA, Applications web et Systemes metier, avec un vrai travail sur la couche de production autour de votre modele : outils, memoire, permissions, verification, observabilite et deploiement.