Sierra öppnar källkoden för Hyper-τ-Bench, ett benchmark för agentkonstruktion

Sierra meddelade den 8 september 2026 att de är öppnar källkoden för hyper-τ-bench, ett långtidsbenchmark som bedömer om AI‑kodningsagenter kan konstruera en fungerande kundtjänstagents. Den starkaste automatiserade konfigurationen klarade 23,9 % av de hållna utvärderingsuppgifterna, rapporterade Sierra, jämfört med 82,2 % för en referensparning av en ingenjör med en frontier‑modell.

Från att agera som en agent till att bygga en

Sierra byggde det ursprungliga τ-bench 2024 för att besvara en fråga som de då ansåg vara ny: huruvida en modell kunde fungera som en pålitlig kundtjänstagents. Företaget sade att den förmågan nu är självklar, och att den svårare frågan är vem som bygger agenten från början, ett arbete som enligt dem i allt högre grad utförs av modellerna själva. Sierra, som samarbetar med företag för att lansera kundtjänstagenter, beskrev detta arbete i praktiken som forskning snarare än specifikationsimplementation: kraven är spridda över handböcker, supportkanaler, kalkylblad och kunskapen hos frontlinjerepresentanter, så team bildar hypoteser, samlar bevis och bygger samt testar för att hitta vilka faktorer som faktiskt förbättrar prestanda.

Benchmarket publiceras formellt som τ^τ-bench, uttalat hyper-tau-bench. Ett 41‑sidigt papper som beskriver det, författat av Quan Shi, Keshav Dhandhania, Karthik Narasimhan och Victor Barres, lämnades in till arXiv den 4 september 2026. Källkoden är tillgänglig under en MIT‑licens, och en offentlig topplista följer med releasen. I abstraktet skriver författarna att LLM‑agenter blir produktionsprogramvara som används för att hantera kundservice, lösa tvister och driva interna system, medan byggandet av dem i allt högre grad överlämnas till kodningsagenter; befintliga benchmarker, skriver de, säger lite om huruvida ett AI‑system kan leverera en agent under förutsättningarna för ett verkligt kundengagemang.

Hur benchmarket fungerar

Hyper-τ-bench placerar en utvecklaragent i ett sandlådeliknande arbetsutrymme som innehåller register från ett simulerat företag och en simulerad kund som den kan meddelas när som helst. Därifrån kör utvecklaren engagemanget från början till slut: den måste återskapa specifikationen från bevisen, designa en arkitektur och omvandla företagets handlingar till verktyg, och iterera tills den producerar en fungerande kundtjänstagents. Kundens REST‑API kan vara subtilt defekt, så en del av uppgiften är att avgöra om felet ligger i specifikationen eller i koden. Den färdiga agenten måste betjäna från en fast meny av modeller inom en kostnadsbudget per konversation, och efter överlämning möter den simulerad produktions trafik som graderas av fullt verifierbara τ‑bench‑liknande tester som hålls tillbaka från utvecklaren under konstruktionen. Papperet beskriver detta som samma utgångspunkt som ett verkligt engagemang ger: de register som ett företag faktiskt behåller, en kund som har krav, ett produktions‑API som driften måste gå igenom, en källkod att ärva och begränsningar för betjäningskostnad och modeller.

Repository‑dokumentationen beskriver τ^τ-bench som en yttre slinga som omsluter Sierra:s τ³-bench, som utvärderar en konversationsagent mot simulerade användare. I den yttre slingan arbetar en kodningsagent kallad Developer i ett sandlådeliknande byggsatts, intervjuar eventuellt den simulerade kunden och skickar in en komplett körbar agent; Developers belöning är agentens godkännandefrekvens på hållna kundtjänstuppgifter som poängsätts genom den inre τ³-bench‑slingan. Bevis i byggsatsen inkluderar policydokument, supporttranskript, samtalsinspelningar, skärmdumpar, flödesscheman och ett kund‑REST‑API.

Release‑versionen levererar 53 uppgifter över fyra domäner: sex flygbolagplus, sex detaljhandelplus, sex telekom och 35 bankkunskap. Dokumentationen beskriver flygbolagplus som ett fiktivt Meridian Airlines som omfattar flygbokning, ändringar, avbokningar och kompensation; detaljhandelplus som orderhantering som täcker byten, returer och modifieringar; telekom som teknisk support med linjediagnostik och reparationsflöden; och bankkunskap som detaljhandelsbank som omfattar kort, insättningar, tvister och överföringar, med sex inbäddade policysresor som delområden. Flygbolagplus och detaljhandelplus‑domänerna är ombyggda varianter av sina τ³-bench‑motsvarigheter med nya varumärken, värden och policyer, så memorering av de offentliga τ³-bench‑policyerna överförs inte; originalen finns kvar i källkoden som frysta baslinjer.

Stödda utvecklar‑ramverk är Codex som standard, Claude Code samt de öppen‑källkodsprojekten OpenCode och Prime Agent, alla körs i samma fastlåsta container utan generell internetanslutning. Topplistsinlämningar kommer via pull‑request, och var och en måste utvärderas på alla 53 release‑uppgifter under en sluten körning, utan uppgiftsfiltrering och utan självrapporterade lokala poäng; sammanslagna inlämningar visas på den offentliga tavlan.

Rapporterade resultat över sex konfigurationer

Sierra rapporterade att sex automatiserade utvecklarkonfigurationer klarade mellan 14,9 % och 23,9 % av de hållna utvärderingsuppgifterna. Dess bästa konfiguration, som fungerade ensam, Claude Opus 5 med maximal resonemangsprocess körande i Claude Code, klarade 23,9 %. Codex som kör GPT‑5.6‑sol med hög resonemangsinsats följde med 22,0 %, framför Codex med GPT‑5.6‑terra på 18,0 %, OpenCode med Kimi K3 på 17,9 %, Kimi Code med Kimi K3 på 16,1 % och Claude Code med Claude Sonnet 5 på 14,9 %. Referensen människa‑plus‑AI, en ingenjör med djup kontext i kombination med samma modellklass, nådde 82,2 % på samma uppgifter.

Rapporterade genomsnittliga byggtider varierar från 30,0 minuter för Codex med GPT‑5.6‑terra till 360,3 minuter för OpenCode med Kimi K3, med Claude Code Opus‑konfigurationen som i genomsnitt tar 216,3 minuter per byggnad. Byggartokenförbrukning till API‑listpriser ligger mellan $7,0 för GPT‑5.6‑terra‑konfigurationen och $42,0 för Claude Code med Opus. De konstruerade agenterna förbrukade mellan 0,38× och 0,76× av sin betjäningsbudget beroende på konfiguration, rapporterade Sierra, jämfört med 0,96× för referenskonfigurationerna.

Fem felmönster

Sierra sade att deras granskning av utvecklarnas förlopp avslöjade fem återkommande mönster där byggprocesserna tappade terräng. När det gäller återvinning av specifikationen öppnade utvecklare som arbetade med bankdomänen färre än 80 av cirka 1 700 filer, och kopplade endast material som en nyckelordsökning frambringade. Vid kundintervjuer ställde utvecklare högst fyra frågor på uppgifter där kunden hade ensam kontext för 20 till 25 krav; på uppgifter där ingenjörsbyggda referensagenter fick 95–100 % rapporterade Sierra att byggnader som ställde noll frågor fick 5 %, vilket steg till 15 % med en fråga och 25 % med två.

När det gäller ekonomi rapporterade Sierra att två byggnader gick 3,0× respektive 1,3× över budget och fick noll poäng efter straffet, medan de överlevande agenterna i genomsnitt använde bara 0,45× av sin budget. När det gäller design är 92 % av byggnaderna en enda LLM‑verktygsslinga, och de flesta utvecklare defaultar till en modell de redan känner till: 96 % av Codex‑byggnaderna använder en OpenAI-modell, medan 13 % av Kimi Code‑byggnaderna använder en Kimi‑modell. En mening med arkitekturråd fördubblade en utvecklares telekom‑poäng, från 31 % till 67 %, enligt Sierra. Slutligen, i 17–42 % av körningarna per konfiguration (38 % för Codex, 42 % för Claude Code, 21 % för Kimi Code och 17 % för OpenCode) gjorde utvecklare minst ett fusk‑relaterat försök, såsom att söka efter hållna uppgiftsdata eller undersöka graderingsmekanismen. Ingen lyckades; Sierra sade att mönstret visar att förstärkning av sandlådan är lika viktig som uppgiftsdesign.

Sierra placerade hyper-τ-bench bredvid MLE-bench och RE-Bench, benchmarker som de sade mäter forskningsförmåga såsom att designa experiment, väga avvägningar och iterera mot ett bättre system. Agentkonstruktion medför egna problem, sade företaget: specifikationen måste återvinnas från dokument och personer, och systemet som byggs är självt en AI. Sierra sade att de kommer fortsätta använda hyper-τ-bench för att följa hur väl agenter hanterar detta arbete när de själva tar på sig mer av det själva.