Les harness, la logique d'exécution qui entoure les modèles, génèrent des gains dans les performances des agents sur le long terme à travers le secteur. LangChain a amélioré Terminal-Bench de +13,7 points uniquement grâce à des changements du harness, le modèle restant inchangé. Vercel a supprimé 80 % des outils de son agent et a constaté une meilleure fiabilité avec une latence 3,5 fois plus faible. Dans ces cas, l'écart de performance venait du harness, pas du modèle.
Nous traversons une période d'itération rapide des harness, portée par un changement dans ce qu'on attend des agents. Les équipes poussent les agents vers des tâches plus longues et multi-étapes, et constatent que les architectures de première génération se dégradent vite. Le schéma courant d'un unique système prompt (souvent plus de 20 K tokens d'instructions conditionnelles) avec 20 à 40 schémas d'outils injectés d'emblée ne tient pas la route. Chez Glean, nous avons réduit notre propre prompt système de plus de 45 % en déplaçant les instructions dans des skills chargés progressivement à la place. La différence apparaît vite sur des tâches comme le remplissage d'un RFP de 200 questions, où chaque question exige une recherche indépendante multi-sources, et où les réponses compilées doivent être validées puis réécrites dans un tableur.
On a l'impression que les harness changent à mesure que les modèles deviennent plus capables. Ce n'est pas le seul moteur. Les harness sont reconstruits parce que nous donnons davantage de travail aux agents, ce qui exige davantage de contexte. Chaque appel d'outil supplémentaire, invocation de skill, résultat de recherche et sortie d'exécution s'ajoute à la fenêtre de contexte. C'est un problème que nous connaissons bien chez Glean. Nos racines sont dans la recherche d'entreprise, où le défi central a toujours été de réduire un vaste espace d'information au contexte précis nécessaire pour accomplir la tâche avec exactitude. De la même façon, à mesure que le volume et la variété du travail qui transite par un agent augmentent, la gestion du contexte devient le problème d'ingénierie central. Le harness est, au fond, un système distribué de gestion du contexte.
Chez Glean, perfectionner notre harness est une quête continue. Aujourd'hui dans sa troisième itération, chaque reconstruction reflète de nouveaux changements dans les capacités des modèles, la technologie et la manière dont l'IA est utilisée à l'échelle de l'entreprise. Cet article couvre quatre évolutions de la conception du harness :
- Le programmatic tool calling (PTC) dans des sandboxes déplace la logique de workflow dans du code isolé, en conservant l'état intermédiaire dans des variables et des fichiers plutôt que dans le prompt.
- Les sub-agents décomposent une boucle d'agent unique en contextes d'exécution isolés, chacun avec sa propre fenêtre de contexte.
- La compaction préserve l'état conversationnel essentiel à la poursuite de l'exécution, tout en déplaçant les sorties intermédiaires brutes vers des systèmes de fichiers.
- La découverte des skills en priorité par la recherche découple la découverte des outils et des skills du chargement des schémas, en ne récupérant les définitions complètes qu'au moment de l'exécution.
Dans ce billet, nous allons parcourir chacune de ces évolutions et expliquer comment notre harness a évolué au fil du temps pour mieux faire passer le contexte à l'échelle. ;
Le code comme principal primitive d'exécution
Le code devient la principale primitive d'exécution pour les agents. À mesure que le travail devient plus complexe, les agents doivent parcourir des ensembles de résultats, bifurquer selon des conditions, filtrer et joindre des données, classer des preuves, exécuter des opérations par lots et paralléliser des étapes indépendantes. Le code exprime cette logique plus naturellement qu'une série d'appels d'outils conversationnels, où le modèle redéduit son plan à partir de l'historique du chat à chaque tour.
Glean utilise le PTC pour déplacer cette logique de workflow dans un environnement d'exécution isolé. Les outils sont exposés comme des fonctions appelables en Python, de sorte que le modèle écrit un petit programme qui récupère, filtre, bifurque, boucle, écrit sur disque et agit en une seule exécution plutôt qu'au fil de dizaines d'échanges conversationnels. 20 appels d'outil peuvent avoir lieu dans une seule exécution de sandbox, et l'orchestrateur ne voit que le résumé et les métadonnées structurées qui reviennent. Les données intermédiaires restent dans des variables et des fichiers Python.
Avec le PTC intégré dans le bon harness, nous avons pu obtenir les gains suivants : ;
- Latence. Les opérations indépendantes peuvent être regroupées et parallélisées dans une seule exécution de code plutôt qu'être sérialisées à travers des allers-retours avec le LLM.
- Fiabilité. Les boucles, filtres, jointures et branchements conditionnels sont plus robustes en code que dans une chaîne fragile de tours de chat où le modèle reconstruit son plan à partir de l'historique de conversation à chaque étape. Cela facilite aussi la reprise après erreur, car l'agent dispose de traces de pile qu'il peut inspecter. ;
- Cohérence. Les scripts peuvent être enregistrés comme skills, ce qui facilite l'exécution de la même séquence d'appels d'outils pour des tâches courantes, à la fois au niveau entreprise et personnel. ;
- Efficacité du contexte à grande échelle. Seuls le résumé ou les résultats finaux reviennent à l'orchestrateur, et non chaque artefact intermédiaire. Cela rend possibles des analyses plus vastes, des opérations en masse et des tâches longues qui doivent paginer, stocker, calculer et revisiter l'état, car l'agent dispose d'un périmètre de programme et d'un système de fichiers en dehors de la fenêtre de contexte.
Les sub-agents comme frontières d'isolation du contexte
Les sub-agents ne sont pas nouveaux dans le harness de Glean, mais le PTC a étendu leur échelle et leur fiabilité. L'agent orchestrateur peut écrire du code pour lancer de manière programmatique des sub-agents en parallèle. ;
Les sub-agents deviennent particulièrement puissants lorsque l'agent orchestrateur doit appliquer le même niveau d'analyse à une grande collection d'éléments indépendants, comme la recherche sur des centaines de clients ou l'analyse de milliers de tickets de support. Dans ces cas, chaque sub-agent peut s'exécuter indépendamment sur sa propre tâche, avec sa propre fenêtre de contexte et son propre budget de tokens, tandis que l'agent orchestrateur fournit les instructions partagées pour effectuer le travail via un modèle de prompt ou une définition de tâche programmatique. Avec les sub-agents, la profondeur d'analyse s'améliore, car chacun peut concentrer son attention sur le contexte et sur la tâche à accomplir sans distraction. ;
Ce schéma permet au système de faire passer à l'échelle un raisonnement répétable sans surcharger une seule fenêtre de contexte, et il fait écho aux idées de Recursive Language Models, où des agents de niveau supérieur décomposent le travail et délèguent des tâches bornées à des travailleurs de niveau inférieur. ;
Stratégies de compaction pour préserver l'état de travail
Si les sub-agents aident à répartir le travail entre de nombreuses tâches indépendantes, en gardant les lignes de raisonnement parallèles isolées et gérables, ils ne résolvent pas la manière dont le contexte s'accumule au fil du temps au sein d'un seul agent. Chez Glean, nous avons constaté qu'environ ~5 % des requêtes atteignaient les limites de la fenêtre de contexte. ;
Pour résoudre ce problème, nous avons conçu une approche de compaction qui préserve les parties de l'état conversationnel qui sont essentielles à la poursuite de l'exécution : l'intention de l'utilisateur, les décisions prises jusqu'ici, les approches qui ont échoué, les prochaines étapes prévues et les sorties récentes à forte valeur signal. Tout le reste est soit résumé, soit déplacé hors de la fenêtre de contexte vers le système de fichiers. L'objectif est d'obtenir une représentation compressée mais sémantiquement complète de l'état de la tâche, qui permette à l'agent de reprendre là où il s'était arrêté après de nombreux tours.
En pratique, cela repose sur deux couches techniques :
- La première est la compaction de la conversation. Nous condensons les allers-retours bruts des tours précédents avec ce que l'utilisateur a demandé, ce que l'agent a tenté, ce qui a fonctionné, ce qui n'a pas fonctionné et ce qu'il prévoit de faire ensuite.
- La seconde est la compaction des sorties d'outils. Les grandes sorties d'outils sont écrites dans des fichiers du système de fichiers de la sandbox et réduites à des résumés avec des chemins de fichiers
La compaction et les sub-agents se renforcent mutuellement. Les sub-agents réduisent la quantité de détails non pertinents que l'orchestrateur voit jamais en gardant le travail intermédiaire dans des contextes isolés. La compaction gère ce qui reste dans l'historique propre de l'orchestrateur, en préservant la cohérence de la tâche dans le temps. L'un gère le contexte spatialement, l'autre temporellement.
Découverte des skills d'abord par la recherche
Les skills émergent comme un standard ouvert pour empaqueter une expertise réutilisable. Cette approche présente des avantages, notamment la divulgation progressive, où l'agent précharge le nom et la description du skill, puis ne récupère la charge utile complète que lorsque la tâche l'exige réellement. ;
Nous avons toutefois constaté que la divulgation progressive seule ne suffit pas à l'échelle de l'entreprise. Il n'est pas réaliste pour un agent de parcourir des centaines d'outils ou de skills, car même des descriptions d'une ligne par élément finissent par s'additionner et créent du bruit que l'agent doit traiter sur des requêtes où la plupart de ces capacités sont sans rapport. C'est pourquoi nous introduisons un index de tous les skills et ne chargeons dans le contexte que les éléments pertinents. ;
La découverte dans Glean suit une approche en trois phases : ;
- Rechercher dans l'index. Le modèle comprend qu'il a besoin d'une capacité et interroge l'index. Notre recherche de skills est plus puissante qu'une simple recherche sémantique, car nous exploitons des signaux du graphe d'entreprise pour classer selon le créateur, l'usage, et plus encore. L'objectif est de trouver le bon skill même dans des scénarios où plusieurs personnes créent et partagent des skills similaires.
- Voir la courte liste et les descriptions légères. L'index renvoie une courte liste de candidats avec leurs noms, descriptions et indications d'exécution. C'est la première fois que le modèle voit un quelconque détail sur ces capacités. Il peut ensuite sélectionner dans cette liste ciblée pour accomplir sa tâche.
- Charger le schéma complet au moment de l'exécution. Ce n'est que lorsque le modèle décide d'exécuter un skill précis que le schéma complet ou le fichier skill.md entre dans le contexte. ;
Avec Glean, l'agent ne paie jamais le coût de contexte lié au parcours de l'ensemble complet des capacités. Les descriptions n'apparaissent que pour les capacités que le modèle a activement recherchées. Les schémas complets n'apparaissent que pour celui qu'il est sur le point d'exécuter. Chaque niveau de détail est révélé au moment où l'agent en a besoin. L'agent fait de meilleurs choix parce qu'il raisonne sur une courte liste ciblée plutôt que de scanner des centaines d'entrées, ce qui permet au harness de passer à l'échelle sur une vaste surface de capacités.
Les harness distribuent la gestion du contexte
Le harness de Glean devient meilleur pour faire passer le contexte à l'échelle et le gérer, parce qu'il est plus distribué : le programmatic tool calling permet une logique d'exécution complexe, les sub-agents isolent le contexte, la compaction préserve l'état de la tâche tout en déchargeant le contexte, et la découverte des skills maintient les agents concentrés sur la tâche à accomplir. ;
Le harness n'arrête jamais d'évoluer. Chaque nouvelle génération d'IA au travail révèle les limites de ce qui existait auparavant, et notre harness évolue avec elle, en s'élargissant pour répondre aux exigences croissantes des agents et au contexte nécessaire pour obtenir des résultats fiables à l'échelle de l'entreprise. Vous voulez apporter un système fiable de gestion du contexte à vos agents ? Réservez dès aujourd'hui une démo Glean.
Auteurs : Nikhil Mandava, Ayushi Mrigen, Chau Tran, Abhi Samantapudi, Julie Mills, Matt Ding
