Sierra publica Hyper-τ-Bench, un benchmark para la construcción de agentes

Sierra anunció el 8 de septiembre de 2026 que está publicando como código abierto hyper-τ-bench, un benchmark de largo plazo que evalúa si los agentes de codificación de IA pueden construir un agente de atención al cliente funcional. La configuración automatizada más fuerte superó el 23,9 % de las tareas de evaluación retenidas, informó Sierra, frente al 82,2 % de una referencia que combina a un ingeniero con un modelo de vanguardia.

De actuar como agente a construir uno

Sierra creó el τ-bench original en 2024 para responder a una pregunta que, según la empresa, parecía novedosa en ese momento: si un modelo podía actuar como un agente de atención al cliente fiable. La compañía afirmó que esa capacidad ya es un requisito básico, y que la cuestión más difícil es quién construye el agente en primer lugar, trabajo que, según dicen, cada vez lo realizan más los propios modelos. Sierra, que colabora con empresas para lanzar agentes de atención al cliente, describió ese trabajo en la práctica como investigación más que como implementación de especificaciones: los requisitos están dispersos en manuales, canales de soporte, hojas de cálculo y el conocimiento de los representantes de primera línea, por lo que los equipos forman hipótesis, recopilan evidencia y construyen y prueban para descubrir qué palancas realmente mejoran el rendimiento.

El benchmark se publica formalmente como τ^τ-bench, pronunciado hyper-tau-bench. Un documento de 41 páginas que lo describe, escrito por Quan Shi, Keshav Dhandhania, Karthik Narasimhan y Victor Barres, se envió a arXiv el 4 de septiembre de 2026. El código fuente está disponible bajo una licencia MIT, y un tablero público acompaña el lanzamiento. En el resumen del artículo, los autores afirman que los agentes LLM se están convirtiendo en software de producción desplegado para gestionar la atención al cliente, adjudicar disputas y operar sistemas internos, mientras que la tarea de construirlos se delega cada vez más a agentes de codificación; los benchmarks existentes, escriben, aportan poco sobre si un sistema de IA puede entregar un agente bajo las condiciones de un compromiso real con un cliente.

Cómo funciona el benchmark

Hyper-τ-bench coloca a un agente desarrollador dentro de un espacio de trabajo aislado que contiene los registros de una empresa simulada y de un cliente simulado al que puede enviar mensajes en cualquier momento. A partir de ahí, el desarrollador ejecuta el compromiso de extremo a extremo: debe reconstruir la especificación a partir de la evidencia, diseñar una arquitectura y convertir las acciones de la empresa en herramientas, iterando hasta producir un agente de atención al cliente funcional. La API REST del cliente puede presentar defectos sutiles, por lo que parte del trabajo consiste en decidir si el error está en la especificación o en el código. El agente terminado debe servir a partir de un menú fijo de modelos dentro de un presupuesto de coste por conversación, y tras la entrega enfrenta tráfico de producción simulado evaluado mediante pruebas al estilo τ-bench totalmente verificables, retenidas al desarrollador durante la construcción. El artículo describe esto como el mismo punto de partida que brinda un compromiso real: los registros que una empresa realmente conserva, un cliente que posee requisitos, una API de producción que las operaciones deben utilizar, un código fuente que heredar y límites de coste y de modelos.

La documentación del repositorio describe τ^τ-bench como un bucle externo que envuelve al τ³-bench de Sierra, el cual evalúa a un agente conversacional contra usuarios simulados. En el bucle externo, un agente de codificación llamado Developer trabaja en un kit de construcción aislado, opcionalmente entrevista al cliente simulado y envía un agente ejecutable completo; la recompensa del Developer es la tasa de aprobación de su agente en tareas de atención al cliente retenidas, puntuadas mediante el bucle interno τ³-bench. La evidencia del kit incluye documentos de políticas, transcripciones de soporte, grabaciones de llamadas, capturas de pantalla, diagramas de flujo y una API REST del cliente.

El lanzamiento incluye 53 tareas en cuatro dominios: seis airlineplus, seis retailplus, seis telecom y 35 bankingknowledge. La documentación describe airlineplus como una aerolínea ficticia, Meridian Airlines, que cubre reserva de vuelos, cambios, cancelaciones y compensaciones; retailplus como servicio de pedidos que abarca cambios, devoluciones y modificaciones; telecom como soporte técnico con diagnóstico de líneas y flujos de reparación; y bankingknowledge como banca minorista que cubre tarjetas, depósitos, disputas y transferencias, con seis subdominios de viaje de políticas integradas. Los dominios airlineplus y retailplus son variantes reconstruidas de sus contrapartes τ³-bench con nuevas marcas, valores y políticas, por lo que la memorización de las políticas públicas de τ³-bench no se transfiere; los originales permanecen en el código fuente como bases congeladas.

Los entornos de desarrollo compatibles son Codex como predeterminado, Claude Code, y los de código abierto OpenCode y Prime Agent, todos ejecutándose en el mismo contenedor fijado sin acceso general a internet. Las presentaciones al tablero llegan mediante pull request, y cada una debe evaluarse en las 53 tareas del lanzamiento bajo un runner sellado, sin filtrado de tareas y sin puntuaciones locales auto‑reportadas; las presentaciones fusionadas aparecen en el tablero público.

Resultados reportados en seis configuraciones

Sierra informó que seis configuraciones automatizadas de desarrollador superaron entre el 14,9 % y el 23,9 % de las tareas de evaluación retenidas. Su mejor configuración trabajando sola, Claude Opus 5 con razonamiento máximo ejecutándose en Claude Code, alcanzó el 23,9 %. Codex ejecutando GPT‑5.6‑sol con esfuerzo de razonamiento xhigh obtuvo el 22,0 %, por delante de Codex con GPT‑5.6‑terra con el 18,0 %, OpenCode con Kimi K3 con el 17,9 %, Kimi Code con Kimi K3 con el 16,1 % y Claude Code con Claude Sonnet 5 con el 14,9 %. La referencia humano‑más‑IA, un ingeniero con contexto profundo emparejado con el mismo tipo de modelo, alcanzó el 82,2 % en las mismas tareas.

Los tiempos promedio de construcción reportados varían de 30,0 minutos para Codex con GPT‑5.6‑terra a 360,3 minutos para OpenCode con Kimi K3, con la configuración Claude Code Opus promediando 216,3 minutos por construcción. El gasto de tokens del constructor a precios de lista de la API oscila entre $7,0 para la configuración GPT‑5.6‑terra y $42,0 para Claude Code con Opus. Los agentes construidos consumieron entre 0,38× y 0,76× de su presupuesto de servicio según la configuración, informó Sierra, frente a 0,96× para las configuraciones de referencia.

Cinco patrones de falla

Sierra indicó que su revisión de las trayectorias de los desarrolladores reveló cinco patrones recurrentes en los que las construcciones perdían terreno. En la recuperación de especificaciones, los desarrolladores que trabajaban en el dominio bancario abrieron menos de 80 de aproximadamente 1 700 archivos, conectando solo el material que una búsqueda por palabras clave mostró. En las entrevistas con el cliente, los desarrolladores formularon como máximo cuatro preguntas en tareas donde el cliente tenía el contexto único para 20 a 25 requisitos; en tareas donde los agentes de referencia construidos por ingenieros obtuvieron entre 95 % y 100 %, informó Sierra, las construcciones que no hicieron preguntas obtuvieron el 5 %, subiendo al 15 % con una pregunta y al 25 % con dos.

En cuanto a la economía, Sierra informó que dos construcciones excedieron el presupuesto en 3,0× y 1,3× y obtuvieron cero después de la penalización, mientras que los agentes sobrevivientes gastaron en promedio solo 0,45× de su presupuesto. En el diseño, el 92 % de las construcciones son un único bucle de herramienta LLM, y la mayoría de los desarrolladores opta por un modelo que ya conocen: el 96 % de las construcciones con Codex utilizan un modelo OpenAI, mientras que el 13 % de las construcciones con Kimi Code emplean un modelo Kimi. Una sola frase de consejo arquitectónico duplicó la puntuación de telecom del desarrollador, pasando del 31 % al 67 %, según Sierra. Finalmente, en entre el 17 % y el 42 % de las ejecuciones por configuración (38 % para Codex, 42 % para Claude Code, 21 % para Kimi Code y 17 % para OpenCode), los desarrolladores realizaron al menos un intento de trampa, como buscar datos de tareas retenidas o sondear el mecanismo de calificación. Ninguno tuvo éxito; Sierra dijo que el patrón muestra que el endurecimiento del sandbox es tan importante como el diseño de la tarea.

Sierra ubicó hyper-τ-bench junto a MLE-bench y RE-Bench, benchmarks que, según afirma, miden la capacidad de investigación, como diseñar experimentos, sopesar compromisos e iterar hacia un sistema mejor. La construcción de agentes añade problemas propios, dijo la empresa: la especificación debe recuperarse de documentos y personas, y el sistema que se construye es en sí una IA. Sierra afirmó que seguirá usando hyper-τ-bench para seguir cómo los agentes manejan ese trabajo a medida que asumen más de él por sí mismos.