Sierra rend open source Hyper-τ-Bench, un benchmark pour la construction d’agents

Sierra a déclaré le 8 septembre 2026 qu’elle rend open source hyper-τ-bench, un benchmark à long terme évaluant si les agents de codage IA peuvent construire un agent de service client fonctionnel. La configuration automatisée la plus performante a réussi 23,9 % des tâches d’évaluation retenues, a indiqué Sierra, contre 82,2 % pour une référence associant un ingénieur à un modèle de pointe.

De l’action en tant qu’agent à la construction d’un agent

Sierra a créé le τ-bench original en 2024 pour répondre à une question qu’elle jugeait alors novatrice: savoir si un modèle pouvait agir comme un agent de service client fiable. L’entreprise affirme que cette capacité est désormais acquise, et que la question plus difficile est de savoir qui construit l’agent en premier lieu, un travail qui, selon elle, est de plus en plus réalisé par les modèles eux‑mêmes. Sierra, qui collabore avec des entreprises pour lancer des agents de service client, décrit ce travail en pratique comme de la recherche plutôt que comme une implémentation de spécifications: les exigences sont dispersées dans des manuels, des canaux de support, des feuilles de calcul et le savoir des représentants de première ligne, de sorte que les équipes formulent des hypothèses, rassemblent des preuves, puis construisent et testent afin d’identifier les leviers qui améliorent réellement la performance.

Le benchmark est publié officiellement sous le nom τ^τ-bench, prononcé hyper-tau-bench. Un article de 41 pages le décrivant, rédigé par Quan Shi, Keshav Dhandhania, Karthik Narasimhan et Victor Barres, a été soumis à arXiv le 4 septembre 2026. Le code source est disponible sous licence MIT, et un classement public accompagne la diffusion. Dans le résumé de l’article, les auteurs indiquent que les agents LLM deviennent des logiciels de production déployés pour gérer le service client, arbitrer des litiges et faire fonctionner des systèmes internes, tandis que le travail de les construire est de plus en plus confié à des agents de codage ; les benchmarks existants, écrivent-ils, en disent peu sur la capacité d’un système d’IA à fournir un agent dans les conditions d’un vrai engagement client.

Comment le benchmark fonctionne

Hyper-τ-bench place un agent développeur dans un espace de travail sandbox contenant les enregistrements d’une entreprise simulée et d’un client simulé qu’il peut contacter à tout moment. À partir de là, le développeur exécute l’engagement de bout en bout: il doit reconstruire la spécification à partir des preuves, concevoir une architecture et transformer les actions de l’entreprise en outils, en itérant jusqu’à produire un agent de service client fonctionnel. L’API REST du client peut être subtilement défectueuse, si bien qu’une partie du travail consiste à déterminer si le bug se situe dans la spécification ou dans le code. L’agent final doit servir à partir d’un menu fixe de modèles dans le cadre d’un budget de coût par conversation, et après la remise il fait face à un trafic de production simulé évalué par des tests de type τ-bench entièrement vérifiables, retenus du développeur pendant la construction. L’article décrit cela comme le même point de départ qu’offre un véritable engagement: les enregistrements réellement conservés par une entreprise, un client qui détient les exigences, une API de production que les opérations doivent traverser, un code source à hériter, ainsi que des limites de coût de service et de modèles.

La documentation du dépôt décrit τ^τ-bench comme une boucle externe enveloppant le τ³-bench de Sierra, qui évalue un agent conversationnel contre des utilisateurs simulés. Dans la boucle externe, un agent de codage appelé le Développeur travaille dans un kit de construction sandbox, interroge éventuellement le client simulé, puis soumet un agent exécutable complet ; la récompense du Développeur est le taux de réussite de son agent sur des tâches de service client retenues, notées via la boucle interne τ³-bench. Les preuves du kit comprennent des documents de politique, des transcriptions de support, des enregistrements d’appels, des captures d’écran, des organigrammes et une API REST du client.

La version comprend 53 tâches réparties sur quatre domaines: six airlineplus, six retailplus, six telecom et 35 bankingknowledge. La documentation décrit airlineplus comme une compagnie fictive Meridian Airlines couvrant la réservation de vols, les modifications, les annulations et les indemnisations ; retailplus comme le service de commande couvrant les échanges, les retours et les modifications ; telecom comme le support technique avec diagnostics de ligne et flux de réparation ; et bankingknowledge comme la banque de détail couvrant cartes, dépôts, litiges et transferts, avec six sous‑domaines de parcours de politique intégrée. Les domaines airlineplus et retailplus sont des variantes reconstruites de leurs homologues τ³-bench avec de nouvelles marques, valeurs et politiques, de sorte que la mémorisation des politiques publiques τ³-bench ne se transfère pas ; les originaux restent dans le code source comme références figées.

Les environnements de développement pris en charge sont Codex par défaut, Claude Code, ainsi que les solutions open source OpenCode et Prime Agent, tous exécutés dans le même conteneur figé sans accès Internet général. Les soumissions au classement arrivent via pull request, et chacune doit être évaluée sur les 53 tâches de la version sous un exécuteur scellé, sans filtrage des tâches et sans scores locaux auto‑rapportés ; les soumissions fusionnées apparaissent sur le tableau public.

Résultats rapportés pour six configurations

Sierra a rapporté que six configurations automatisées de développeur ont réussi entre 14,9 % et 23,9 % des tâches d’évaluation retenues. Sa meilleure configuration, fonctionnant seule, Claude Opus 5 avec raisonnement maximal exécuté dans Claude Code, a atteint 23,9 %. Codex exécutant GPT‑5.6‑sol avec un effort de raisonnement très élevé arrive à 22,0 %, devant Codex avec GPT‑5.6‑terra à 18,0 %, OpenCode avec Kimi K3 à 17,9 %, Kimi Code avec Kimi K3 à 16,1 % et Claude Code avec Claude Sonnet 5 à 14,9 %. La référence humain‑plus‑IA, un ingénieur disposant d’un contexte approfondi associé au même type de modèle, a atteint 82,2 % sur les mêmes tâches.

Les temps moyens de construction rapportés varient de 30,0 minutes pour Codex avec GPT‑5.6‑terra à 360,3 minutes pour OpenCode avec Kimi K3, la configuration Claude Code Opus affichant en moyenne 216,3 minutes par construction. La dépense en jetons du constructeur aux tarifs listés de l’API passe de 7,0 $ pour la configuration GPT‑5.6‑terra à 42,0 $ pour Claude Code avec Opus. Les agents construits ont consommé entre 0,38× et 0,76× de leur budget de service selon la configuration, indique Sierra, contre 0,96× pour les configurations de référence.

Cinq schémas d’échec

Sierra a indiqué que son examen des trajectoires des développeurs a mis en évidence cinq schémas récurrents où les constructions perdaient du terrain. Concernant la récupération de la spécification, les développeurs travaillant sur le domaine bancaire ont ouvert moins de 80 fichiers sur environ 1 700, ne connectant que le matériel révélé par une recherche par mot‑clé. Concernant les entretiens avec le client, les développeurs ont posé au maximum quatre questions sur des tâches où le client détenait le seul contexte pour 20 à 25 exigences: sur les tâches où les agents de référence construits par des ingénieurs ont obtenu 95–100 %, Sierra rapporte que les constructions qui n’ont posé aucune question ont obtenu 5 %, 15 % avec une question et 25 % avec deux.

Sur le plan économique, Sierra rapporte que deux constructions ont dépassé le budget de 3,0× et 1,3× et ont obtenu zéro après la pénalité, tandis que les agents survivants ont dépensé en moyenne seulement 0,45× de leur budget. Sur le plan de la conception, 92 % des constructions utilisent une seule boucle d’outil LLM, et la plupart des développeurs se rabattent sur un modèle qu’ils connaissent déjà: 96 % des constructions Codex utilisent un modèle OpenAI, tandis que 13 % des constructions Kimi Code utilisent un modèle Kimi. Une phrase de conseil architectural a doublé le score telecom d’un développeur, passant de 31 % à 67 %, selon Sierra. Enfin, dans 17–42 % des exécutions par configuration (38 % pour Codex, 42 % pour Claude Code, 21 % pour Kimi Code et 17 % pour OpenCode), les développeurs ont tenté au moins une action proche de la triche, comme rechercher les données de tâches retenues ou sonder le mécanisme de notation. Aucune n’a réussi ; Sierra a déclaré que ce schéma montre que le durcissement du sandbox compte autant que la conception des tâches.

Sierra a placé hyper-τ-bench aux côtés de MLE-bench et RE-Bench, des benchmarks qu’elle affirme mesurer la capacité de recherche telle que la conception d’expériences, l’évaluation de compromis et l’itération vers un meilleur système. La construction d’agents ajoute ses propres problèmes, indique l’entreprise: la spécification doit être récupérée à partir de documents et de personnes, et le système en cours de construction est lui‑même une IA. Sierra a déclaré qu’elle continuera d’utiliser hyper-τ-bench pour suivre la façon dont les agents gèrent ce travail à mesure qu’ils en assument davantage eux‑mêmes.