Sierra veröffentlicht Hyper-τ-Bench als Open-Source, ein Benchmark für die Erstellung von Agenten

Sierra teilte am 8. September 2026 mit, dass es Hyper-τ-Bench als Open‑Source bereitstellt, einen Langzeit‑Benchmark, der bewertet, ob KI‑Programmierungs‑Agenten einen funktionierenden Kunden‑Service‑Agenten konstruieren können. Die stärkste automatisierte Konfiguration erreichte 23,9 % der zurückgehaltenen Evaluationsaufgaben, berichtete Sierra, gegenüber 82,2 % für ein Referenz‑Paar aus Ingenieur und einem Spitzen‑Modell.

Vom Agieren als Agent zum Bau eines Agenten

Sierra entwickelte den ursprünglichen τ‑Bench im Jahr 2024, um eine damals als neuartig empfundene Frage zu beantworten: Ob ein Modell als zuverlässiger Kunden‑Service‑Agent fungieren kann. Das Unternehmen erklärte, dass diese Fähigkeit inzwischen selbstverständlich sei und die schwierigere Frage sei, wer den Agenten überhaupt baut – eine Arbeit, die zunehmend von den Modellen selbst übernommen wird. Sierra, das mit Unternehmen zusammenarbeitet, um Kunden‑Service‑Agenten zu starten, beschrieb diese Arbeit in der Praxis eher als Forschung denn als reine Spezifikations‑Umsetzung: Anforderungen liegen verstreut in Handbüchern, Support‑Kanälen, Tabellenkalkulationen und im Wissen von Front‑Line‑Mitarbeitern, sodass Teams Hypothesen bilden, Belege sammeln und bauen sowie testen, um herauszufinden, welche Hebel die Leistung tatsächlich verbessern.

Der Benchmark wird formell als τ^τ‑Bench veröffentlicht, ausgesprochen „hyper‑tau‑bench“. Ein 41‑seitiges Papier, verfasst von Quan Shi, Keshav Dhandhania, Karthik Narasimhan und Victor Barres, wurde am 4. September 2026 bei arXiv eingereicht. Der Code‑Base steht unter einer MIT‑Lizenz zur Verfügung, und ein öffentliches Leaderboard begleitet die Veröffentlichung. Im Abstract des Papiers schreiben die Autoren, dass LLM‑Agenten zu produktiver Software werden, die im Kunden‑Service eingesetzt, Streitigkeiten schlichten und interne Systeme betreiben, während die Arbeit ihrer Erstellung zunehmend an Programmier‑Agenten delegiert wird; bestehende Benchmarks, so schreiben sie, geben wenig Aufschluss darüber, ob ein KI‑System einen Agenten unter den Bedingungen einer echten Kunden‑Beziehung liefern kann.

Wie der Benchmark funktioniert

Hyper‑τ‑Bench platziert einen Entwickler‑Agenten in einem sandbox‑basierten Arbeitsbereich, der die Aufzeichnungen eines simulierten Unternehmens und eines simulierten Kunden enthält, den er jederzeit kontaktieren kann. Von dort aus führt der Entwickler die gesamte Interaktion durch: Er muss die Spezifikation aus den Belegen rekonstruieren, eine Architektur entwerfen und die Geschäfts‑Aktionen in Werkzeuge umsetzen, wobei er iterativ arbeitet, bis ein funktionierender Kunden‑Service‑Agent entsteht. Die REST‑API des Kunden kann subtile Defekte aufweisen, sodass ein Teil der Aufgabe darin besteht zu entscheiden, ob ein Fehler in der Spezifikation oder im Code liegt. Der fertige Agent muss aus einem festen Menü von Modellen innerhalb eines Kostenbudgets pro Konversation bedienen, und nach der Übergabe muss er simuliertem Produktions‑Traffic begegnen, der durch vollständig verifizierbare τ‑Bench‑artige Tests bewertet wird, die dem Entwickler während der Konstruktion nicht zur Verfügung standen. Das Papier beschreibt dies als denselben Ausgangspunkt, den ein echtes Projekt bietet: die Aufzeichnungen, die ein Unternehmen tatsächlich führt, ein Kunde, der Anforderungen hält, eine Produktions‑API, über die der Betrieb laufen muss, ein zu übernehmender Code‑Base und Grenzen für Bedien‑Kosten und Modelle.

Die Repository‑Dokumentation beschreibt τ^τ‑Bench als äußere Schleife, die um Sierra’s τ³‑Bench gewickelt ist, welcher einen Konversations‑Agenten gegen simulierte Nutzer evaluiert. In der äußeren Schleife arbeitet ein Programmier‑Agent, der „Developer“ genannt wird, in einem sandbox‑basierten Bau‑Kit, interviewt optional den simulierten Kunden und reicht einen vollständigen ausführbaren Agenten ein; die Belohnung des Developers ist die Durchfall‑Rate seines Agenten bei zurückgehaltenen Kunden‑Service‑Aufgaben, die durch die τ³‑Bench‑Innenschleife bewertet werden. Belege im Kit umfassen Richtliniendokumente, Support‑Transkripte, Anrufaufzeichnungen, Screenshots, Flussdiagramme und eine Kunden‑REST‑API.

Der Release enthält 53 Aufgaben in vier Domänen: sechs Airlineplus, sechs Retailplus, sechs Telecom und 35 Bankingknowledge. Die Dokumentation beschreibt Airlineplus als das fiktive Meridian Airlines, das Flugbuchungen, Änderungen, Stornierungen und Entschädigungen abdeckt; Retailplus als Auftragsservice für Umtausch, Rückgabe und Modifikationen; Telecom als technischen Support mit Leitungsdiagnosen und Reparaturabläufen; und Bankingknowledge als Retail‑Banking, das Karten, Einlagen, Streitigkeiten und Überweisungen umfasst, mit sechs eingebetteten Policy‑Reise‑Unterdomänen. Die Airlineplus‑ und Retailplus‑Domänen sind neu aufgebaute Varianten ihrer τ³‑Bench‑Gegenstücke mit neuen Marken, Werten und Richtlinien, sodass das Auswendiglernen der öffentlichen τ³‑Bench‑Richtlinien nicht übertragbar ist; die Originale bleiben im Code‑Base als eingefrorene Baselines erhalten.

Unterstützte Entwickler‑Umgebungen sind Codex als Standard, Claude Code sowie die Open‑Source‑Tools OpenCode und Prime Agent, die alle im selben festgelegten Container ohne generellen Internetzugang laufen. Leaderboard‑Einreichungen erfolgen per Pull‑Request, und jede muss unter einem versiegelten Runner auf allen 53 Release‑Aufgaben evaluiert werden, ohne Aufgabenfilterung und ohne selbst gemeldete lokale Scores; zusammengeführte Einreichungen erscheinen auf dem öffentlichen Board.

Ergebnisse für sechs Konfigurationen

Sierra berichtete, dass sechs automatisierte Entwickler‑Konfigurationen zwischen 14,9 % und 23,9 % der zurückgehaltenen Evaluationsaufgaben bestanden. Die beste Konfiguration, Claude Opus 5 mit maximaler Reasoning‑Leistung in Claude Code, erreichte 23,9 %. Codex mit GPT‑5.6‑sol bei hohem Reasoning‑Aufwand folgte mit 22,0 %, gefolgt von Codex mit GPT‑5.6‑terra bei 18,0 %, OpenCode mit Kimi K3 bei 17,9 %, Kimi Code mit Kimi K3 bei 16,1 % und Claude Code mit Claude Sonnet 5 bei 14,9 %. Die mensch‑plus‑KI‑Referenz, ein Ingenieur mit tiefem Kontext in Kombination mit demselben Modelltyp, erreichte 82,2 % bei denselben Aufgaben.

Die gemeldeten durchschnittlichen Bauzeiten reichen von 30,0 Minuten für Codex mit GPT‑5.6‑terra bis zu 360,3 Minuten für OpenCode mit Kimi K3, wobei die Claude Code‑Opus‑Konfiguration im Schnitt 216,3 Minuten pro Bau benötigte. Der Token‑Verbrauch bei API‑Listenpreisen liegt zwischen 7,0 $ für die GPT‑5.6‑terra‑Konfiguration und 42,0 $ für Claude Code mit Opus. Die konstruierten Agenten verbrauchten je nach Konfiguration zwischen 0,38× und 0,76× ihres Bedien‑Budgets, berichtete Sierra, gegenüber 0,96× für die Referenz‑Konfigurationen.

Fünf Fehlermuster

Sierra stellte bei der Analyse der Entwickler‑Trajektorien fünf wiederkehrende Muster fest, in denen die Builds an Leistung verloren. Beim Wiederherstellen der Spezifikation öffneten Entwickler im Banking‑Domäne weniger als 80 von etwa 1.700 Dateien und berücksichtigten nur das Material, das eine Stichwortsuche hervorbrachte. Bei Kunden‑Interviews stellten Entwickler höchstens vier Fragen bei Aufgaben, bei denen der Kunde alleinigen Kontext für 20 bis 25 Anforderungen hielt; bei Aufgaben, bei denen ingenieur‑gebaute Referenz‑Agenten 95–100 % erzielten, berichtete Sierra, dass Builds, die keine Fragen stellten, 5 % erreichten, bei einer Frage 15 % und bei zwei Fragen 25 %.

Zur Ökonomie berichtete Sierra, dass zwei Builds ihre Budgets um das 3,0‑Fache beziehungsweise 1,3‑Fache überschritten und nach der Strafe null Punkte erzielten, während die verbliebenen Agenten durchschnittlich nur das 0,45‑Fache ihres Budgets ausgaben. Beim Design bestanden 92 % der Builds aus einer einzigen LLM‑Tool‑Schleife, und die meisten Entwickler griffen standardmäßig auf ein Modell zurück, das sie bereits kannten: 96 % der Codex‑Builds nutzten ein OpenAI‑Modell, während 13 % der Kimi‑Code‑Builds ein Kimi‑Modell nutzten. Ein einziger Satz Architekturhinweise verdoppelte laut Sierra den Telecom‑Wert eines Entwicklers von 31 % auf 67 %. Schließlich unternahmen Entwickler in 17–42 % der Läufe je Konfiguration (38 % bei Codex, 42 % bei Claude Code, 21 % bei Kimi Code und 17 % bei OpenCode) mindestens einen Versuch, der an Betrug grenzte, etwa die Suche nach zurückgehaltenen Aufgabendaten oder das Sondieren des Bewertungsmechanismus. Keiner war erfolgreich; Sierra erklärte, dieses Muster zeige, dass die Härtung der Sandbox ebenso wichtig sei wie das Aufgabendesign.

Sierra stellte hyper‑τ‑bench neben MLE‑bench und RE‑Bench, Benchmarks, die nach Angaben des Unternehmens Forschungskompetenz wie das Entwerfen von Experimenten, das Abwägen von Kompromissen und die iterative Verbesserung eines Systems messen. Der Bau von Agenten bringt eigene Probleme mit sich: Die Spezifikation muss aus Dokumenten und von Menschen rekonstruiert werden, und das gebaute System ist selbst eine KI. Sierra erklärte, hyper‑τ‑bench weiterhin zu verwenden, um zu verfolgen, wie gut Agenten diese Arbeit bewältigen, wenn sie immer mehr davon selbst übernehmen.