Sierra maakt Hyper-τ-Bench open source, een benchmark voor agentconstructie

Sierra zei op 8 september 2026 dat het hyper-τ-bench open-source maakt, een langetermijnbenchmark die beoordeelt of AI‑codeeragents een werkende klantenservice‑agent kunnen bouwen. De sterkste geautomatiseerde configuratie behaalde 23,9 % van de gereserveerde evaluatietaken, meldde Sierra, tegenover 82,2 % voor een referentie‑koppeling van een ingenieur met een frontier‑model.

Van optreden als agent tot er één bouwen

Sierra bouwde de oorspronkelijke τ-bench in 2024 om een vraag te beantwoorden die destijds nieuw leek: of een model kon fungeren als een betrouwbare klantenservice‑agent. Het bedrijf stelde dat die mogelijkheid nu vanzelfsprekend is, en dat de moeilijkere vraag is wie de agent in de eerste plaats bouwt, een werk dat volgens hen steeds vaker door de modellen zelf wordt uitgevoerd. Sierra, dat samenwerkt met bedrijven om klantenservice‑agents te lanceren, beschreef dit werk in de praktijk als onderzoek in plaats van specificatie‑implementatie: eisen zijn verspreid over handboeken, ondersteuningskanalen, spreadsheets en de kennis van front‑line medewerkers, zodat teams hypothesen vormen, bewijs verzamelen en bouwen en testen om te ontdekken welke hefbomen de prestaties daadwerkelijk verbeteren.

De benchmark wordt formeel gepubliceerd als τ^τ-bench, uitgesproken als hyper‑tau‑bench. Een paper van 41 pagina’s die het beschrijft, geschreven door Quan Shi, Keshav Dhandhania, Karthik Narasimhan en Victor Barres, werd op 4 september 2026 ingediend bij arXiv. De codebase is beschikbaar onder een MIT‑licentie, en een openbare ranglijst begeleidt de release. In de samenvatting van het paper schrijven de auteurs dat LLM‑agents steeds meer productiesoftware worden die worden ingezet voor klantenservice, geschillenbeslechting en interne systemen, terwijl het werk van het bouwen ervan steeds vaker wordt overgedragen aan codeer‑agents; bestaande benchmarks, schrijven ze, geven weinig inzicht in of een AI‑systeem een agent kan leveren onder de omstandigheden van een echte klantrelatie.

Hoe de benchmark werkt

Hyper‑τ‑bench plaatst een ontwikkelaar‑agent in een geïsoleerde werkruimte die de gegevens bevat van een gesimuleerde onderneming en een gesimuleerde klant die hij op elk moment kan berichten. Vanuit daar voert de ontwikkelaar de volledige interactie uit: hij moet de specificatie uit het bewijs reconstrueren, een architectuur ontwerpen en de acties van de onderneming omzetten in tools, en itereren totdat hij een werkende klantenservice‑agent produceert. De REST‑API van de klant kan subtiel defect zijn, dus een deel van de taak is bepalen of een bug in de specificatie of in de code zit. De voltooide agent moet dienen vanuit een vaste set modellen binnen een kostenbudget per gesprek, en na overdracht krijgt hij gesimuleerde productie‑verkeer te verwerken, beoordeeld met volledig verifieerbare τ‑bench‑achtige tests die tijdens de constructie aan de ontwikkelaar werden onthouden. Het paper beschrijft dit als hetzelfde uitgangspunt dat een echte interactie biedt: de gegevens die een onderneming daadwerkelijk bijhoudt, een klant die de eisen bezit, een productie‑API waar de operaties doorheen moeten, een codebase om over te nemen, en limieten op service‑kosten en modellen.

De documentatie van de repository beschrijft τ^τ-bench als een buitenlus die is gewikkeld rond Sierra’s τ³-bench, die een conversatie‑agent evalueert tegen gesimuleerde gebruikers. In de buitenlus werkt een codeer‑agent, de Developer genoemd, in een geïsoleerde constructiekit, interviewt eventueel de gesimuleerde klant, en dient een volledig uitvoerbare agent in; de beloning voor de Developer is het slagingspercentage van zijn agent op gereserveerde klantenservice‑taken die worden gescoord via de τ³-bench‑innerlus. Bewijs in de kit omvat beleidsdocumenten, ondersteunings‑transcripten, gespreksopnames, screenshots, stroomdiagrammen en een client‑REST‑API.

De release bevat 53 taken verdeeld over vier domeinen: zes airlineplus, zes retailplus, zes telecom en 35 bankingknowledge. De documentatie beschrijft airlineplus als een fictieve Meridian Airlines die vluchtreserveringen, wijzigingen, annuleringen en compensaties dekt; retailplus als orderafhandeling die ruilen, retouren en aanpassingen omvat; telecom als technische ondersteuning met lijn‑diagnostiek en reparatiestromen; en bankingknowledge als retailbankieren met kaarten, deposito’s, geschillen en overboekingen, met zes ingebedde‑beleid‑reis subdomeinen. De airlineplus‑ en retailplus‑domeinen zijn opnieuw gebouwde varianten van hun τ³-bench‑tegenhangers met nieuwe merken, waarden en beleidsregels, zodat het memoriseren van de openbare τ³-bench‑beleidsregels niet overdraagbaar is; de originelen blijven in de codebase als bevroren baselines.

Ondersteunde ontwikkelaar‑harnesses zijn Codex als standaard, Claude Code, en de open‑source OpenCode en Prime Agent, die allemaal draaien in dezelfde vastgezette container zonder algemene internettoegang. Ranglijst‑inzendingen komen binnen via pull‑request, en elke moet worden geëvalueerd op alle 53 release‑taken onder een afgesloten runner, zonder taakfiltering en zonder zelfgerapporteerde lokale scores; samengevoegde inzendingen verschijnen op het openbare bord.

Gerapporteerde resultaten over zes configuraties

Sierra meldde dat zes geautomatiseerde ontwikkelaar‑configuraties tussen 14,9 % en 23,9 % van de gereserveerde evaluatietaken slaagden. De beste configuratie die alleen werkte, Claude Opus 5 met maximale redeneer‑capaciteit in Claude Code, behaalde 23,9 %. Codex met GPT‑5.6‑sol op zeer hoge redeneerinspanning volgde met 22,0 %, vooropgaand op Codex met GPT‑5.6‑terra op 18,0 %, OpenCode met Kimi K3 op 17,9 %, Kimi Code met Kimi K3 op 16,1 % en Claude Code met Claude Sonnet 5 op 14,9 %. De mens‑plus‑AI referentie, een ingenieur met diepe context gekoppeld aan hetzelfde type model, bereikte 82,2 % op dezelfde taken.

Gemiddelde bouwtijden varieerden van 30,0 minuten voor Codex met GPT‑5.6‑terra tot 360,3 minuten voor OpenCode met Kimi K3, waarbij de Claude‑Code‑Opus‑configuratie gemiddeld 216,3 minuten per bouw kostte. Het token‑verbruik van de bouwer tegen de API‑lijstprijzen liep van $7,0 voor de GPT‑5.6‑terra‑configuratie tot $42,0 voor Claude Code met Opus. De geconstrueerde agents verbruikten tussen 0,38× en 0,76× van hun servicebudget, afhankelijk van de configuratie, meldde Sierra, tegenover 0,96× voor de referentie‑configuraties.

Vijf faalpatronen

Sierra stelde dat haar beoordeling van ontwikkelaarstrajecten vijf terugkerende patronen aan het licht bracht waarin builds terrein verloren. Bij specificatie‑herstel openden ontwikkelaars die aan het bankdomein werkten minder dan 80 van ongeveer 1.700 bestanden, en koppelden alleen het materiaal dat een trefwoordzoekopdracht aan het licht bracht. Bij klantinterviews stelden ontwikkelaars maximaal vier vragen bij taken waarbij de klant de enige context had voor 20 tot 25 eisen; bij taken waarbij door ingenieurs gebouwde referentie‑agents 95–100 % scoorden, meldde Sierra, scoorden builds die nul vragen stelden 5 %, oplopend tot 15 % met één vraag en 25 % met twee.

Op economisch gebied meldde Sierra dat twee builds 3,0× en 1,3× over het budget liepen en na de straf nul scoorden, terwijl de overgebleven agents gemiddeld slechts 0,45× van hun budget verbruikten. Op ontwerpniveau is 92 % van de builds een enkele LLM‑tool‑lus, en de meeste ontwikkelaars defaulten naar een model dat ze al kennen: 96 % van de Codex‑builds gebruiken een OpenAI-model, terwijl 13 % van de Kimi‑Code‑builds een Kimi‑model gebruiken. Eén zin architectuurrad verdubbelde de telecomscore van een ontwikkelaar, van 31 % naar 67 %, aldus Sierra. Ten slotte maakten ontwikkelaars in 17–42 % van de runs per configuratie (38 % voor Codex, 42 % voor Claude Code, 21 % voor Kimi Code en 17 % voor OpenCode) ten minste één poging die op valsspelen leek, zoals zoeken naar gereserveerde taakdata of het onderzoeken van het beoordelingsmechanisme. Niemand slaagde; Sierra zei dat dit patroon aantoont dat het versterken van de sandbox net zo belangrijk is als het ontwerpen van de taak.

Sierra plaatste hyper‑τ‑bench naast MLE‑bench en RE‑Bench, benchmarks die volgens hen de onderzoeksbekwaamheid meten, zoals het ontwerpen van experimenten, het afwegen van afwegingen en itereren naar een beter systeem. Agent‑constructie brengt eigen problemen met zich mee, aldus het bedrijf: de specificatie moet worden hersteld uit documenten en mensen, en het systeem dat wordt gebouwd is zelf een AI. Sierra zei dat het hyper‑τ‑bench zal blijven gebruiken om te volgen hoe goed agents dat werk afhandelen naarmate ze er steeds meer zelf op nemen.