Sol gaspillait les limites avec des appels d'outils inutiles

Ce qui a vraiment cassé dans Sol

Le fait principal est simple : Sol ne dépensait pas les limites à cause de la complexité des tâches, mais à cause d'appels d'outils inutiles. Le 30 juillet 2026, une discussion utilisateur a rapporté un message de Tibo : l'agent effectuait des actions inefficaces, appelait les outils à répétition, épuisant rapidement les limites ; une correction a été apportée et un reset a été appliqué.

C'est du spam d'outils classique. Le modèle ne pense pas simplement plus longtemps : il déclenche des actions externes qui coûtent des limites, du temps et parfois de l'argent. Si un appel n'apporte aucune information nouvelle, il devient du bruit, mais le compteur continue de tourner.

Dans cette histoire, le reset lui-même n'est pas ce qui m'importe. Les resets soignent les symptômes. La cause racine est presque toujours plus profonde : on a permis à l'agent de vagabonder trop librement parmi les outils, sans l'obliger à prouver l'utilité de chaque appel et sans arrêter la boucle quand le progrès stagnait.

Un bon environnement d'exécution agentique doit être ennuyeux et strict. Déduplication des appels identiques (outil+args), limite d'itérations, plafonds par outil, une politique de réessai unifiée, des erreurs structurées compréhensibles au lieu de réessais aveugles. Ce ne sont pas des ornements cosmétiques autour du prompt, mais les freins d'un véhicule qui roulerait autrement en rond avec plaisir.

Pourquoi cela importe pour les utilisateurs d'agents IA

Ce bug frappe directement l'expérience utilisateur : les limites disparaissent prématurément, la latence augmente, et la qualité de la réponse peut ne pas s'améliorer du tout. De l'extérieur, cela ressemble à l'activité normale d'un agent intelligent : il appelle, vérifie, affine. En réalité, il pourrait simplement tourner en rond.

Dans un incident similaire, ma première réaction ne serait pas de lire le texte du prompt système, mais d'examiner les traces d'exécution. Combien d'appels répétés, les résultats changeaient-ils après chaque étape, y avait-il des arguments identiques, où les réessais se déclenchaient. Si une grande part des appels ne modifie pas l'étape de raisonnement suivante, l'agent n'est pas autonome, il est glouton.

Pour Sol, un signal positif est que le problème a été reconnu comme des actions inefficaces et corrigé, plutôt que rejeté sur les utilisateurs. Mais sans détails du correctif, la principale question d'ingénierie demeure : s'agissait-il d'un patch ponctuel pour un scénario particulier, ou des garde-fous stricts sont-ils apparus dans la couche d'exécution ?

Dans les produits agentiques, le vainqueur ne sera pas celui qui crie le plus fort son autonomie, mais celui qui sait dire au modèle à temps : arrête d'appeler l'outil, tu as déjà tout ce qu'il te faut. C'est là que se cache la fiabilité de l'agent, pas dans un beau prompt système.

Nous avons précédemment analysé comment les attaques par homoglyphes menacent la sécurité des appels d'outils chez les agents IA. Lors de l'optimisation de ces appels, il est important de prendre en compte ce vecteur de risque.