Sierra gjør Hyper-τ-Bench åpen kildekode, et benchmark for agentkonstruksjon

Sierra sa 8. september 2026 at den åpner kildekoden til hyper-τ-bench, et langtidsbenchmark som måler om AI‑kodingagenter kan konstruere en fungerende kundeservice‑agent. Den sterkeste automatiserte konfigurasjonen besto 23,9 % av de hold‑out evalueringsoppgavene, rapporterte Sierra, mot 82,2 % for en referanse‑parring av en ingeniør med en frontlinjemodell.

Fra å opptre som en agent til å bygge en

Sierra bygde den opprinnelige τ-bench i 2024 for å svare på et spørsmål den sa var ny på den tiden: om en modell kunne opptre som en pålitelig kundeservice‑agent. Selskapet sa at denne evnen nå er en selvfølge, og at det vanskeligere spørsmålet er hvem som bygger agenten i første omgang, et arbeid som etter hvert i økende grad utføres av modellene selv. Sierra, som samarbeider med selskaper om å lansere kundeservice‑agenter, beskrev dette arbeidet i praksis som forskning snarere enn spesifikasjonsimplementering: kravene er spredt over håndbøker, supportkanaler, regneark og kunnskapen til frontlinjerepresentanter, så team lager hypoteser, samler bevis og bygger og tester for å finne hvilke faktorer som faktisk påvirker ytelsen.

Benchmarket publiseres formelt som τ^τ-bench, uttalt hyper-tau-bench. Et 41‑siders papir som beskriver det, skrevet av Quan Shi, Keshav Dhandhania, Karthik Narasimhan og Victor Barres, ble sendt til arXiv 4. september 2026. Kodebasen er tilgjengelig under en MIT‑lisens, og en offentlig rangliste følger med utgivelsen. I sammendraget av papiret skriver forfatterne at LLM‑agenter blir produksjonsprogramvare som tas i bruk for å håndtere kundeservice, dømme tvister og drive interne systemer, mens arbeidet med å bygge dem i økende grad overlates til kodingagenter; eksisterende benchmarks, skriver de, sier lite om hvorvidt et AI‑system kan levere en agent under betingelsene i et reelt kundeengasjement.

Hvordan benchmarket fungerer

Hyper-τ-bench plasserer en utvikler‑agent i et sandkasse‑arbeidsområde som inneholder opptegnelser fra en simulert virksomhet og en simulert klient som den kan sende meldinger til når som helst. Derfra kjører utvikleren engasjementet fra ende til ende: den må rekonstruere spesifikasjonen fra bevisene, designe en arkitektur og konvertere virksomhetens handlinger til verktøy, og iterere til den produserer en fungerende kundeservice‑agent. Klientens REST‑API kan være subtilt defekt, så en del av oppgaven er å avgjøre om en feil ligger i spesifikasjonen eller i koden. Den ferdige agenten må betjene fra en fast meny av modeller innenfor et kostnadsbudsjett per samtale, og etter overlevering møter den simulert produksjonstrafikk vurdert av fullt verifiserbare τ‑bench‑lignende tester som holdes tilbake fra utvikleren under konstruksjonen. Papiret beskriver dette som det samme startpunktet et reelt engasjement gir: opptegnelsene en virksomhet faktisk fører, en klient som har krav, et produksjons‑API som driften må gå gjennom, en kodebase å arve, og begrensninger på betjeningskostnad og modeller.

Repository‑dokumentasjonen beskriver τ^τ-bench som en ytre løkke som er pakket rundt Sierra sin τ³-bench, som evaluerer en konversasjonsagent mot simulerte brukere. I den ytre løkken arbeider en kodingagent kalt Developer i et sandkasse‑konstruksjonssett, intervjuer eventuelt den simulerte klienten, og leverer en komplett kjørbar agent; Developer‑s belønning er agentens bestått‑rate på hold‑out kundeservice‑oppgaver vurdert gjennom τ³-bench‑indre løkke. Bevis i settet inkluderer retningslinjedokumenter, support‑transkripsjoner, samtaleregistreringer, skjermbilder, flytskjemaer og et klient‑REST‑API.

Utgivelsen omfatter 53 oppgaver fordelt på fire domener: seks airlineplus, seks retailplus, seks telecom og 35 bankingknowledge. Dokumentasjonen beskriver airlineplus som et fiktivt Meridian Airlines som dekker flybestilling, endringer, kanselleringer og kompensasjon; retailplus som ordrebehandling som dekker bytter, returer og endringer; telecom som teknisk støtte med linjediagnostikk og reparasjonsflyter; og bankingknowledge som detaljbanktjenester som dekker kort, innskudd, tvister og overføringer, med seks innebygde underdomener for policybaserte kundereiser. Domenene airlineplus og retailplus er ombygde varianter av sine τ³-bench-motparter med nye merkevarer, verdier og policyer, slik at memorering av de offentlige τ³-bench-policyene ikke kan overføres; originalene forblir i kodebasen som frosne referansepunkter.

Støttede utviklerverktøy er Codex som standard, Claude Code og åpen kildekode-verktøyene OpenCode og Prime Agent, alle kjørt i den samme låste containeren uten generell internettilgang. Bidrag til resultatlisten sendes som pull requests, og hvert bidrag må evalueres på alle de 53 oppgavene i utgivelsen i en lukket kjører, uten oppgavefiltrering og uten selvrapporterte lokale poengsummer; sammenslåtte bidrag vises på den offentlige resultatlisten.

Rapporterte resultater over seks konfigurasjoner

Sierra rapporterte at seks automatiserte utviklerkonfigurasjoner besto mellom 14,9 % og 23,9 % av hold‑out evalueringsoppgavene. Den beste konfigurasjonen som arbeidet alene, Claude Opus 5 med maksimal resonnering i Claude Code, besto 23,9 %. Codex som kjørte GPT‑5.6‑sol med svært høy resonneringsinnsats fulgte med 22,0 %, foran Codex med GPT‑5.6‑terra på 18,0 %, OpenCode med Kimi K3 på 17,9 %, Kimi Code med Kimi K3 på 16,1 % og Claude Code med Claude Sonnet 5 på 14,9 %. Den menneske‑plus‑AI‑referansen, en ingeniør med dyp kontekst kombinert med samme modellklasse, nådde 82,2 % på de samme oppgavene.

Rapporterte gjennomsnittlige byggetider varierer fra 30,0 minutter for Codex med GPT‑5.6‑terra til 360,3 minutter for OpenCode med Kimi K3, mens Claude Code Opus‑konfigurasjonen i gjennomsnitt bruker 216,3 minutter per bygg. Byggerens token‑forbruk til API‑listepriser varierer fra $7,0 for GPT‑5.6‑terra‑konfigurasjonen til $42,0 for Claude Code med Opus. De konstruerte agentene brukte mellom 0,38× og 0,76× av deres betjeningsbudsjett avhengig av konfigurasjon, rapporterte Sierra, mot 0,96× for referanse‑konfigurasjonene.

Fem feilmønstre

Sierra sa at gjennomgangen av utvikler‑trajektorier avdekket fem tilbakevendende mønstre der bygg mistet terreng. Når det gjelder spesifikasjonsgjenoppretting, åpnet utviklere som arbeidet med bank‑domene færre enn 80 av omtrent 1 700 filer, og koblet kun til materialet et nøkkelord‑søk avdekket. Når det gjelder klientintervjuer, stilte utviklere maksimalt fire spørsmål på oppgaver hvor klienten hadde eneste kontekst for 20 til 25 krav; på oppgaver hvor ingeniør‑byggede referanseagenter scoret 95–100 %, rapporterte Sierra, fikk bygg som stilte null spørsmål 5 %, 15 % med ett spørsmål og 25 % med to.

Når det gjelder økonomi, rapporterte Sierra at to bygg gikk 3,0× og 1,3× over budsjett og fikk null poeng etter straffen, mens de overlevende agentene i gjennomsnitt brukte kun 0,45× av budsjettet sitt. Når det gjelder design, er 92 % av bygg en enkelt LLM‑verktøyløkke, og de fleste utviklere default‑valgte en modell de allerede kjenner: 96 % av Codex‑bygg bruker en OpenAI-modell, mens 13 % av Kimi Code‑bygg bruker en Kimi‑modell. En enkelt setning med arkitektur‑råd doblet en utviklers telecom‑score, fra 31 % til 67 %, ifølge Sierra. Til slutt, i 17–42 % av kjøringer per konfigurasjon (38 % for Codex, 42 % for Claude Code, 21 % for Kimi Code og 17 % for OpenCode), gjorde utviklere minst ett forsøk på juks, som å søke etter hold‑out oppgavedata eller undersøke graderingsmekanismen. Ingen lykkes; Sierra sa at mønsteret viser at forsterkning av sandkassen er like viktig som oppgavedesign.

Sierra plasserte hyper-τ-bench ved siden av MLE-bench og RE-Bench, benchmarks som de sier måler forskningskapasitet som å designe eksperimenter, veie avveininger og iterere mot et bedre system. Agentkonstruksjon tilfører egne problemer, sier selskapet: spesifikasjonen må gjenopprettes fra dokumenter og mennesker, og systemet som bygges er selv en AI. Sierra sa at de vil fortsette å bruke hyper-τ-bench for å spore hvor godt agenter håndterer dette arbeidet etter hvert som de tar på seg mer av det selv.