Sierra lansează Hyper-τ-Bench ca open-source, un benchmark pentru construcția de agenți

Sierra a declarat pe 8 septembrie 2026 că publică ca open-source hyper-τ-bench, un benchmark pe termen lung care evaluează dacă agenții AI de programare pot construi un agent de servicii pentru clienţi funcțional. Configuraţia automată cea mai performantă a trecut 23,9% din sarcinile de evaluare reţinută, potrivit unui raport al Sierra, comparativ cu 82,2% pentru o combinaţie de referinţă între un inginer şi un model de frontieră.

De la a acționa ca agent la a construi unul

Sierra a creat τ-bench original în 2024 pentru a răspunde unei întrebări pe care, la acea vreme, o considera nouă: dacă un model ar putea acţiona ca un agent de servicii pentru clienţi fiabil. Compania a afirmat că această capacitate este acum un standard, iar întrebarea mai dificilă este cine construieşte agentul în primul rând, o activitate care, după cum susţine, este tot mai des realizată de însăşi modele. Sierra, care colaborează cu companii pentru lansarea de agenţi de servicii pentru clienţi, a descris această muncă în practică ca cercetare mai degrabă decât ca implementare de specificaţii: cerinţele sunt împrăştiate în manuale, canale de suport, foi de calcul şi în cunoştinţele reprezentanţilor de primă linie, astfel că echipele formulează ipoteze, adună dovezi şi construiesc şi testează pentru a descoperi ce factori influenţează cu adevărat performanţa.

Benchmark‑ul este publicat oficial sub denumirea τ^τ-bench, pronunţat hyper‑tau‑bench. Un articol de 41 de pagini care îl descrie, scris de Quan Shi, Keshav Dhandhania, Karthik Narasimhan și Victor Barres, a fost depus la arXiv pe 4 septembrie 2026. Baza de cod este disponibilă sub licenţa MIT, iar un clasament public însoţește lansarea. În rezumatul lucrării, autorii scriu că agenţii LLM devin software de producție utilizat pentru a gestiona serviciul clienţi, a judeca dispute şi a opera sisteme interne, în timp ce munca de a-i construi este tot mai des delegată agenţilor de programare; benchmark‑urile existente, scriu aceştia, oferă puţine informaţii despre dacă un sistem AI poate livra un agent în condiţiile unei colaborări reale cu un client.

Cum funcționează benchmark‑ul

Hyper‑τ‑bench plasează un agent dezvoltator într-un spaţiu de lucru sandbox care conţine înregistrările unei afaceri simulate şi ale unui client simulat cu care poate comunica în orice moment. De acolo, dezvoltatorul rulează angajamentul de la început până la sfârşit: trebuie să reconstruiască specificaţia din dovezi, să proiecteze o arhitectură şi să transforme acţiunile afacerii în instrumente, iterând până când produce un agent de servicii pentru clienţi funcţional. API‑ul REST al clientului poate fi uşor defectuos, astfel că o parte a sarcinii este să se decidă dacă o eroare se află în specificaţie sau în cod. Agentul final trebuie să servească dintr-un meniu fix de modele, în cadrul unui buget de cost per conversaţie, iar după predare se confruntă cu trafic de producţie simulat evaluat prin teste de tip τ‑bench complet verificabile, reţinute de la dezvoltator în timpul construcţiei. Lucrarea descrie acest lucru ca acelaşi punct de plecare pe care îl oferă un angajament real: înregistrările pe care le păstrează efectiv o afacere, un client care deţine cerinţele, un API de producţie prin care operaţiunile trebuie să treacă, o bază de cod de moştenit şi limite privind costul de servire şi modelele.

Documentaţia din depozit descrie τ^τ‑bench ca un ciclu exterior înfăşurat în jurul τ³‑bench al Sierra, care evaluează un agent conversaţional în raport cu utilizatori simulaţi. În ciclul exterior, un agent de programare numit „Developer” lucrează într‑un kit de construcţie sandbox, intervievează opţional clientul simulat şi trimite un agent executabil complet; recompensa Developer‑ului este rata de trecere a agentului său la sarcinile de servicii pentru clienţi reţinute, evaluate prin ciclul interior τ³‑bench. Dovezile din kit includ documente de politică, transcrieri de suport, înregistrări de apeluri, capturi de ecran, diagrame de flux şi un API REST al clientului.

Lansarea conţine 53 de sarcini în patru domenii: şase airlineplus, şase retailplus, şase telecom şi 35 bankingknowledge. Documentaţia descrie airlineplus ca o companie fictivă Meridian Airlines care acoperă rezervarea de zboruri, modificări, anulări şi compensaţii; retailplus ca servicii de comandă care acoperă schimburi, retururi şi modificări; telecom ca suport tehnic cu diagnosticare de linii şi fluxuri de reparare; şi bankingknowledge ca banking de retail care acoperă carduri, depozite, dispute şi transferuri, cu şase subdomenii de călătorie cu politici încorporate. Domeniile airlineplus şi retailplus sunt variante reconstruite ale omologilor lor din τ³‑bench, cu mărci, valori şi politici noi, astfel încât memorarea politicilor publice τ³‑bench nu se transferă; originale rămân în baza de cod ca repere îngheţate.

Instrumentele de dezvoltare suportate sunt Codex ca implicit, Claude Code, şi OpenCode și Prime Agent open‑source, toate rulând în acelaşi container fixat fără acces general la internet. Trimiterile pentru clasament sosesc prin pull request, iar fiecare trebuie evaluată pe toate cele 53 de sarcini ale lansării sub un runner sigilat, fără filtrare de sarcini şi fără scoruri locale auto‑raportate; trimiterile integrate apar pe tabla publică.

Rezultatele raportate pentru cele şase configuraţii

Sierra a raportat că şase configuraţii automate de dezvoltatori au trecut între 14,9% şi 23,9% din sarcinile de evaluare reţinute. Cea mai bună configuraţie, funcţionând singură, Claude Opus 5 cu raţionament maxim în Claude Code, a atins 23,9%. Codex rulând GPT‑5.6‑sol cu efort de raţionament xhigh a urmat cu 22,0%, înaintea Codex cu GPT‑5.6‑terra la 18,0%, OpenCode cu Kimi K3 la 17,9%, Kimi Code cu Kimi K3 la 16,1% şi Claude Code cu Claude Sonnet 5 la 14,9%. Referinţa om‑plus‑AI, un inginer cu context profund asociat aceluiaşi tip de model, a atins 82,2% la aceleaşi sarcini.

Timpul mediu de construire raportat variază de la 30,0 minute pentru Codex cu GPT‑5.6‑terra la 360,3 minute pentru OpenCode cu Kimi K3, configuraţia Claude Code Opus având în medie 216,3 minute per construcţie. Cheltuielile de token ale constructorului la preţurile listă ale API‑ului variază de la 7,0 $ pentru configuraţia GPT‑5.6‑terra la 42,0 $ pentru Claude Code cu Opus. Agenţii construiţi au consumat între 0,38× şi 0,76× din bugetul lor de servire în funcţie de configuraţie, potrivit Sierra, comparativ cu 0,96× pentru configuraţiile de referinţă.

Cinci modele de eșec

Sierra a declarat că revizuirea traiectoriilor dezvoltatorilor a evidenţiat cinci tipare recurente în care construcţiile au pierdut teren. În recuperarea specificaţiilor, dezvoltatorii care lucrau în domeniul bancar au deschis mai puţin de 80 din aproximativ 1.700 de fişiere, conectând doar materialul evidenţiat de căutarea pe cuvinte cheie. În interviurile cu clientul, dezvoltatorii au pus cel mult patru întrebări la sarcini în care clientul deţinea contextul unic pentru 20‑25 de cerinţe; la sarcini în care agenţii de referinţă construiţi de ingineri au obţinut scoruri de 95‑100%, Sierra a raportat, construcţiile care nu au pus nicio întrebare au obţinut 5%, crescând la 15% cu o întrebare şi la 25% cu două.

În ceea ce priveşte economia, Sierra a raportat că două construcţii au depăşit bugetul cu 3,0× şi respectiv 1,3× şi au obţinut zero puncte după penalizare, în timp ce agenţii rămaşi au cheltuit în medie doar 0,45× din bugetul lor. În ceea ce priveşte designul, 92% din construcţii sunt un singur ciclu de instrument LLM, iar majoritatea dezvoltatorilor se bazează pe un model pe care îl cunosc deja: 96% din construcţiile Codex utilizează un model OpenAI, în timp ce 13% din construcţiile Kimi Code folosesc un model Kimi. O singură propoziţie de recomandare arhitecturală a dublat scorul telecom al unui dezvoltator, de la 31% la 67%, conform Sierra. În cele din urmă, în 17‑42% din rulări pe configuraţie (38% pentru Codex, 42% pentru Claude Code, 21% pentru Kimi Code şi 17% pentru OpenCode), dezvoltatorii au făcut cel puţin o încercare de tip înşelăciune, cum ar fi căutarea de date ale sarcinilor reţinute sau investigarea mecanismului de notare. Niciuna nu a reuşit; Sierra a afirmat că acest tipar arată că întărirea sandbox‑ului contează la fel de mult ca şi proiectarea sarcinilor.

Sierra a plasat hyper‑τ‑bench alături de MLE‑bench și RE‑Bench, benchmark‑uri pe care le descrie ca măsurând capacitatea de cercetare, cum ar fi proiectarea de experimente, evaluarea compromisurilor și iterarea spre un sistem mai bun. Construcţia de agenţi adaugă propriile probleme, a declarat compania: specificaţia trebuie recuperată din documente şi oameni, iar sistemul în construcţie este el însuşi un AI. Sierra a afirmat că va continua să folosească hyper‑τ‑bench pentru a monitoriza cât de bine gestionează agenţii această muncă pe măsură ce îşi asumă din ce în ce mai mult din ea în mod autonom.