Sierra rende open source Hyper-τ-Bench, un benchmark per la costruzione di agenti

Sierra ha dichiarato l’8 settembre 2026 che sta rendo open source hyper-τ-bench, un benchmark a lungo orizzonte che valuta se gli agenti di programmazione AI possano costruire un agente di assistenza clienti funzionante. La configurazione automatizzata più forte ha superato il 23,9% dei compiti di valutazione tenuti da parte, ha riferito Sierra, contro l’82,2% per una coppia di riferimento composta da un ingegnere e un modello all’avanguardia.

Da agire come agente a costruirne uno

Sierra ha creato il τ-bench originale nel 2024 per rispondere a una domanda che all’epoca considerava innovativa: se un modello potesse agire come un agente di assistenza clienti affidabile. L’azienda ha affermato che questa capacità è ora di base, e che la domanda più difficile è chi costruisce l’agente in primo luogo, un lavoro che, secondo loro, è sempre più svolto dagli stessi modelli. Sierra, che collabora con aziende per lanciare agenti di assistenza clienti, ha descritto questo lavoro in pratica come ricerca piuttosto che implementazione di specifiche: i requisiti sono sparsi tra manuali, canali di supporto, fogli di calcolo e la conoscenza dei rappresentanti in prima linea, così i team formulano ipotesi, raccolgono prove e costruiscono e testano per scoprire quali leve influenzano realmente le prestazioni.

Il benchmark è pubblicato formalmente come τ^τ-bench, pronunciato hyper-tau-bench. Un documento di 41 pagine che lo descrive, scritto da Quan Shi, Keshav Dhandhania, Karthik Narasimhan e Victor Barres, è stato inviato a arXiv il 4 settembre 2026. Il codice sorgente è disponibile sotto licenza MIT, e una classifica pubblica accompagna il rilascio. Nell’abstract del documento, gli autori affermano che gli agenti LLM stanno diventando software di produzione impiegati per gestire l’assistenza clienti, risolvere controversie e operare sistemi interni, mentre il lavoro di costruirli è sempre più affidato ad agenti di programmazione; i benchmark esistenti, scrivono, forniscono poche informazioni su se un sistema AI possa fornire un agente nelle condizioni di un vero impegno con un cliente.

Come funziona il benchmark

Hyper-τ-bench colloca un agente sviluppatore all’interno di un’area di lavoro sandbox contenente i registri di un’azienda simulata e di un cliente simulato con cui può comunicare in qualsiasi momento. Da lì lo sviluppatore gestisce l’intero coinvolgimento: deve ricostruire la specifica dalle prove, progettare un’architettura e trasformare le azioni dell’azienda in strumenti, iterando finché non produce un agente di assistenza clienti funzionante. L’API REST del cliente può presentare difetti sottili, quindi parte del lavoro consiste nel decidere se il bug risieda nella specifica o nel codice. L’agente completato deve operare da un menu fisso di modelli entro un budget di costo per conversazione, e dopo il passaggio gestisce traffico di produzione simulato valutato da test verificabili in stile τ-bench, tenuti nascosti allo sviluppatore durante la costruzione. Il documento descrive ciò come lo stesso punto di partenza fornito da un vero coinvolgimento: i registri che un’azienda effettivamente conserva, un cliente che detiene i requisiti, un’API di produzione che le operazioni devono utilizzare, un codice sorgente da ereditare e limiti di costo e modelli.

La documentazione del repository descrive τ^τ-bench come un ciclo esterno avvolto attorno al τ³-bench di Sierra, che valuta un agente conversazionale contro utenti simulati. Nel ciclo esterno, un agente di programmazione chiamato Developer lavora in un kit di costruzione sandbox, opzionalmente intervista il cliente simulato e invia un agente eseguibile completo; la ricompensa del Developer è il tasso di superamento del suo agente sui compiti di assistenza clienti tenuti da parte e valutati tramite il ciclo interno τ³-bench. Le prove nel kit includono documenti di policy, trascrizioni di supporto, registrazioni di chiamate, screenshot, diagrammi di flusso e un’API REST del cliente.

Il rilascio comprende 53 compiti distribuiti su quattro domini: sei airlineplus, sei retailplus, sei telecom e 35 bankingknowledge. La documentazione descrive airlineplus come una fittizia Meridian Airlines che copre prenotazione voli, modifiche, cancellazioni e compensazioni; retailplus come servizio di ordine che copre scambi, resi e modifiche; telecom come supporto tecnico con diagnostica di linea e flussi di riparazione; e bankingknowledge come banking al dettaglio che copre carte, depositi, controversie e trasferimenti, con sei sotto‑domini di percorso con policy incorporate. I domini airlineplus e retailplus sono varianti ricostruite dei loro corrispondenti τ³-bench con nuovi marchi, valori e policy, quindi la memorizzazione delle policy pubbliche di τ³-bench non si trasferisce; gli originali rimangono nel codice sorgente come baseline congelate.

I harness per sviluppatori supportati sono Codex come predefinito, Claude Code, e gli open source OpenCode e Prime Agent, tutti eseguiti nello stesso contenitore fissato senza accesso a Internet generale. Le proposte per la classifica arrivano tramite pull request, e ciascuna deve essere valutata su tutti i 53 compiti del rilascio sotto un runner sigillato, senza filtraggio dei compiti e senza punteggi locali auto‑segnalati; le proposte accettate appaiono sulla bacheca pubblica.

Risultati segnalati su sei configurazioni

Sierra ha riportato che sei configurazioni automatizzate per sviluppatori hanno superato tra il 14,9% e il 23,9% dei compiti di valutazione tenuti da parte. La sua migliore configurazione operante da sola, Claude Opus 5 con ragionamento massimo in esecuzione su Claude Code, ha raggiunto il 23,9%. Codex con GPT-5.6-sol a sforzo di ragionamento xhigh segue al 22,0%, davanti a Codex con GPT-5.6-terra al 18,0%, OpenCode con Kimi K3 al 17,9%, Kimi Code con Kimi K3 al 16,1% e Claude Code con Claude Sonnet 5 al 14,9%. Il riferimento umano‑plus‑AI, un ingegnere con contesto profondo associato allo stesso tipo di modello, ha raggiunto l’82,2% sugli stessi compiti.

I tempi medi di costruzione segnalati variano da 30,0 minuti per Codex con GPT-5.6-terra a 360,3 minuti per OpenCode con Kimi K3, con la configurazione Claude Code Opus che media 216,3 minuti per build. La spesa di token del costruttore ai prezzi di listino API varia da $7,0 per la configurazione GPT-5.6-terra a $42,0 per Claude Code con Opus. Gli agenti costruiti hanno consumato tra 0,38× e 0,76× del loro budget di servizio a seconda della configurazione, ha riportato Sierra, contro 0,96× per le configurazioni di riferimento.

Cinque modelli di fallimento

Sierra ha affermato che la revisione dei percorsi degli sviluppatori ha evidenziato cinque schemi ricorrenti in cui le build hanno perso terreno. Per il recupero della specifica, gli sviluppatori che lavoravano nel dominio bancario hanno aperto meno di 80 dei circa 1.700 file, collegando solo il materiale emerso da una ricerca per parole chiave. Per le interviste con il cliente, gli sviluppatori hanno posto al massimo quattro domande su compiti in cui il cliente deteneva il contesto unico per 20‑25 requisiti; su compiti in cui gli agenti di riferimento costruiti da ingegneri hanno ottenuto un punteggio 95‑100%, ha riportato Sierra, le build che non hanno posto domande hanno ottenuto il 5%, salendo al 15% con una domanda e al 25% con due.

Sul piano economico, Sierra ha segnalato che due build hanno superato il budget di 3,0× e 1,3× e hanno ottenuto zero dopo la penalità, mentre gli agenti rimasti hanno speso in media solo 0,45× del loro budget. Sul design, il 92% delle build è un unico ciclo di strumento LLM, e la maggior parte degli sviluppatori ricade su un modello che già conoscono: il 96% delle build Codex utilizza un modello OpenAI, mentre il 13% delle build Kimi Code utilizza un modello Kimi. Una singola frase di consiglio architetturale ha raddoppiato il punteggio telecom di uno sviluppatore, dal 31% al 67%, secondo Sierra. Infine, nel 17‑42% delle esecuzioni per configurazione (38% per Codex, 42% per Claude Code, 21% per Kimi Code e 17% per OpenCode), gli sviluppatori hanno effettuato almeno un tentativo di tipo cheating, come la ricerca di dati dei compiti tenuti da parte o il probing del meccanismo di valutazione. Nessuno ha avuto successo; Sierra ha affermato che questo schema dimostra che il rafforzamento del sandbox è importante quanto la progettazione del compito.

Sierra ha collocato hyper-τ-bench accanto a MLE-bench e RE-Bench, benchmark che, secondo loro, misurano la capacità di ricerca come la progettazione di esperimenti, la valutazione dei trade‑off e l’iterazione verso un sistema migliore. La costruzione di agenti aggiunge problemi propri, ha affermato l’azienda: la specifica deve essere recuperata da documenti e persone, e il sistema in costruzione è esso stesso un’AI. Sierra ha dichiarato che continuerà a utilizzare hyper-τ-bench per monitorare quanto bene gli agenti gestiscano quel lavoro man mano che lo assumono sempre più autonomamente.