Anthropic, OpenAI et LangChain expliquent pourquoi les agents d'IA ont besoin d'un harness

Le principal problème des agents d'IA actuels ne tient pas à la qualité du modèle de base, mais à la couche qui l'entoure : orchestration, mémoire, gestion du contexte et fiabilité des outils. Cette couche, que l'on appelle de plus en plus agent harness, fait passer un LLM sans état (stateless) du statut de démo spectaculaire à celui de système capable d'enchaîner durablement de longues séquences d'actions, de survivre aux erreurs et de mener une tâche à son terme.

Au début, beaucoup d'équipes se contentent d'une interface de chat, de quelques appels d'outils (tool calls) et d'une simple boucle ReAct. Pour un prototype, cela suffit : le modèle raisonne, choisit un outil, reçoit la réponse et poursuit le dialogue. Mais en production, les défaillances systémiques apparaissent vite.

L'agent oublie ce qu'il a fait deux ou trois étapes plus tôt, répète les mêmes appels, perd des résultats intermédiaires, et la fenêtre de contexte se remplit de bruit aléatoire. Les outils posent un problème à part : ils peuvent renvoyer un format inattendu, répondre avec du retard ou tomber en panne sans cause claire. Sans couche de contrôle, de journalisation et de reprise par-dessus, la qualité du système ne dépend plus de l'intelligence du modèle, mais de la fragilité de son enrobage.

C'est pourquoi de grands acteurs comme Anthropic, OpenAI, Perplexity et LangChain ne construisent pas seulement de nouveaux modèles, mais une véritable infrastructure d'agents. Au centre de cette infrastructure se trouve la boucle d'orchestration : elle décide quand le modèle doit réfléchir à nouveau, quand appeler un outil, quoi enregistrer en mémoire, quoi renvoyer à l'utilisateur et à quel moment s'arrêter. En somme, le harness joue le rôle de système d'exploitation de l'agent. Il fixe les règles d'exécution, suit l'état de la session, achemine les actions entre le modèle et les services externes, et réduit le risque que l'agent s'enferme dans une boucle infinie ou perde de vue l'objectif de la tâche.

Plusieurs composants de cette approche peuvent déjà être considérés comme obligatoires. Premièrement, la gestion des outils : description des interfaces, validation des données d'entrée, nouvelles tentatives, timeouts et gestion des erreurs. Deuxièmement, une mémoire à plusieurs niveaux : à court terme pour la tâche en cours, de travail pour les résultats intermédiaires, et à plus long terme pour les préférences, les règles et l'expérience accumulée. Troisièmement, le contrôle du contexte : sélectionner les fragments vraiment importants, compresser l'historique, supprimer les déchets et ne transmettre au modèle que ce qui influe sur l'étape suivante. Sans ces mécanismes, même un LLM performant se dégrade à mesure que la tâche s'allonge. Avec eux, le même modèle devient nettement plus fiable.

Une autre couche importante du harness concerne l'observabilité et l'évaluation de la qualité. Il ne suffit pas au développeur de savoir qu'une réponse est mauvaise : il doit voir tout le parcours de l'agent, c'est-à-dire quel prompt a été envoyé au modèle, quel outil a été appelé, quelle réponse est revenue, où l'erreur est survenue et pourquoi l'étape suivante a été choisie. Sans cela, impossible de déboguer correctement le comportement de l'agent ni d'améliorer le système par itérations. Les stacks matures ajoutent donc traçage, métriques, exécution en sandbox, checkpoints manuels et mécanismes human-in-the-loop pour les actions à risque.

L'effet pratique est lui aussi parlant. Le matériel source cite un exemple de LangChain : l'entreprise a amélioré non pas les poids du modèle, mais l'infrastructure qui l'entoure, et cela a suffi pour bondir dans TerminalBench 2.0, d'une position hors du top 30 jusqu'à la cinquième place. Un autre résultat est encore plus intéressant : dans un projet de recherche, un LLM a servi à optimiser sa propre infrastructure d'agent, et le système a atteint un pass rate de 76,4 %, devançant des solutions assemblées à la main.

C'est un signal important pour le marché. La concurrence se déplace de la question « quel modèle est le plus intelligent » vers « quel environnement d'exécution aide le mieux le modèle à réfléchir, mémoriser, planifier et se corriger ». Pour les développeurs et les équipes produit, la conclusion est directe : pour obtenir un agent opérationnel plutôt qu'un bot jouet, il faut investir non seulement dans le choix du modèle, mais aussi dans le harness.

Les gagnants seront ceux qui organiseront le mieux la boucle d'exécution, la mémoire, le contexte, l'observabilité et la tolérance aux pannes. Dans un avenir proche, c'est la qualité de cet enrobage, et non le prochain bond dans les benchmarks, qui fera la principale différence entre une belle démo et un système auquel on peut confier un vrai travail.