Sierra disponibiliza código aberto do Hyper-τ-Bench, um benchmark para construção de agentes

A Sierra informou em 8 de setembro de 2026 que está abrindo o código do hyper-τ-bench, um benchmark de longo prazo que avalia se agentes de codificação de IA podem construir um agente de atendimento ao cliente funcional. A configuração automatizada mais forte passou em 23,9% das tarefas de avaliação reservadas, informou a Sierra, contra 82,2% para um emparelhamento de referência entre um engenheiro e um modelo de ponta.

De atuar como agente a construir um

A Sierra criou o τ-bench original em 2024 para responder a uma pergunta que considerava inovadora na época: se um modelo poderia atuar como um agente de atendimento ao cliente confiável. A empresa afirmou que essa capacidade já é padrão, e que a questão mais difícil é quem constrói o agente inicialmente, trabalho que, segundo ela, está sendo cada vez mais realizado pelos próprios modelos. A Sierra, que faz parceria com empresas para lançar agentes de atendimento ao cliente, descreveu esse trabalho na prática como pesquisa em vez de implementação de especificação: os requisitos estão espalhados por manuais, canais de suporte, planilhas e o conhecimento dos representantes de linha de frente, de modo que as equipes formulam hipóteses, coletam evidências e constroem e testam para descobrir quais alavancas realmente melhoram o desempenho.

O benchmark é publicado formalmente como τ^τ-bench, pronunciado hyper-tau-bench. Um artigo de 41 páginas que o descreve, escrito por Quan Shi, Keshav Dhandhania, Karthik Narasimhan e Victor Barres, foi submetido ao arXiv em 4 de setembro de 2026. O código-fonte está disponível sob licença MIT, e uma leaderboard pública acompanha o lançamento. No resumo do artigo, os autores afirmam que agentes LLM estão se tornando softwares de produção implantados para lidar com atendimento ao cliente, adjudicar disputas e operar sistemas internos, enquanto o trabalho de construí‑los está sendo cada vez mais delegados a agentes de codificação; benchmarks existentes, escrevem, dizem pouco sobre se um sistema de IA pode entregar um agente nas condições de um engajamento real com cliente.

Como o benchmark funciona

Hyper-τ-bench coloca um agente desenvolvedor dentro de um espaço de trabalho sandbox contendo os registros de um negócio simulado e de um cliente simulado ao qual pode enviar mensagens a qualquer momento. A partir daí o desenvolvedor executa o engajamento de ponta a ponta: ele deve reconstruir a especificação a partir das evidências, projetar uma arquitetura e converter as ações do negócio em ferramentas, iterando até produzir um agente de atendimento ao cliente funcional. A API REST do cliente pode ter defeitos sutis, portanto parte do trabalho consiste em decidir se o bug está na especificação ou no código. O agente concluído deve operar a partir de um menu fixo de modelos dentro de um orçamento de custo por conversa, e após a entrega enfrenta tráfego de produção simulado avaliado por testes totalmente verificáveis no estilo τ-bench, mantidos ocultos do desenvolvedor durante a construção. O artigo descreve isso como o mesmo ponto de partida que um engajamento real fornece: os registros que um negócio realmente mantém, um cliente que possui requisitos, uma API de produção que as operações devem utilizar, um código-fonte a ser herdado e limites de custo e modelos.

A documentação do repositório descreve τ^τ-bench como um loop externo envolvendo o τ³-bench da Sierra, que avalia um agente conversacional contra usuários simulados. No loop externo, um agente de codificação chamado Developer trabalha em um kit de construção sandbox, opcionalmente entrevista o cliente simulado e envia um agente executável completo; a recompensa do Developer é a taxa de aprovação de seu agente nas tarefas de atendimento ao cliente reservadas, pontuadas através do loop interno τ³-bench. As evidências no kit incluem documentos de políticas, transcrições de suporte, gravações de chamadas, capturas de tela, fluxogramas e uma API REST do cliente.

O lançamento inclui 53 tarefas em quatro domínios: seis airlineplus, six retailplus, seis telecom e 35 bankingknowledge. A documentação descreve airlineplus como uma companhia aérea fictícia, Meridian Airlines, que cobre reserva de voos, alterações, cancelamentos e compensações; retailplus como serviço de pedidos que abrange trocas, devoluções e modificações; telecom como suporte técnico com diagnóstico de linhas e fluxos de reparo; e bankingknowledge como banco de varejo que cobre cartões, depósitos, disputas e transferências, com seis subdomínios de jornada de políticas incorporadas. Os domínios airlineplus e retailplus são variantes reconstruídas de seus equivalentes τ³-bench com novas marcas, valores e políticas, de modo que a memorização das políticas públicas do τ³-bench não se transfere; os originais permanecem no código-fonte como linhas de base congeladas.

Os harnesses de desenvolvedor suportados são Codex como padrão, Claude Code, e os de código aberto OpenCode e Prime Agent, todos executando no mesmo contêiner fixado sem rota geral para a internet. As submissões à leaderboard chegam via pull request, e cada uma deve ser avaliada em todas as 53 tarefas do lançamento sob um runner selado, sem filtragem de tarefas e sem pontuações locais auto‑reportadas; submissões mescladas aparecem no quadro público.

Resultados relatados em seis configurações

A Sierra relatou que seis configurações automatizadas de desenvolvedor passaram entre 14,9% e 23,9% das tarefas de avaliação reservadas. Sua melhor configuração operando sozinha, Claude Opus 5 com raciocínio máximo rodando no Claude Code, atingiu 23,9%. Codex executando GPT-5.6-sol com esforço de raciocínio xhigh ficou em 22,0%, à frente de Codex com GPT-5.6-terra em 18,0%, OpenCode com Kimi K3 em 17,9%, Kimi Code com Kimi K3 em 16,1% e Claude Code com Claude Sonnet 5 em 14,9%. A referência humano‑mais‑IA, um engenheiro com contexto profundo emparelhado ao mesmo tipo de modelo, alcançou 82,2% nas mesmas tarefas.

Os tempos médios de construção relatados variam de 30,0 minutos para Codex com GPT-5.6-terra a 360,3 minutos para OpenCode com Kimi K3, com a configuração Claude Code Opus apresentando média de 216,3 minutos por construção. O gasto de tokens do construtor, ao preço de lista da API, varia de US$ 7,0 para a configuração GPT-5.6-terra a US$ 42,0 para Claude Code com Opus. Os agentes construídos consumiram entre 0,38× e 0,76× de seu orçamento de serviço, dependendo da configuração, informou a Sierra, contra 0,96× para as configurações de referência.

Cinco padrões de falha

A Sierra afirmou que sua análise das trajetórias dos desenvolvedores revelou cinco padrões recorrentes onde as construções perderam desempenho. Na recuperação de especificação, desenvolvedores que trabalhavam no domínio bancário abriram menos de 80 de aproximadamente 1.700 arquivos, conectando apenas o material que uma busca por palavra‑chave revelou. Nas entrevistas com o cliente, os desenvolvedores fizeram no máximo quatro perguntas em tarefas nas quais o cliente detinha o contexto exclusivo de 20 a 25 requisitos; em tarefas onde agentes de referência construídos por engenheiros marcaram 95–100%, relatou a Sierra, construções que não fizeram perguntas obtiveram 5%, subindo para 15% com uma pergunta e 25% com duas.

Em termos econômicos, a Sierra relatou que duas construções excederam o orçamento em 3,0× e 1,3× e marcaram zero após a penalidade, enquanto os agentes sobreviventes gastaram em média apenas 0,45× de seu orçamento. Em design, 92% das construções são um único loop de ferramenta LLM, e a maioria dos desenvolvedores recorre a um modelo que já conhece: 96% das construções Codex utilizam um modelo OpenAI, enquanto 13% das construções Kimi Code utilizam um modelo Kimi. Uma única frase de conselho de arquitetura dobrou a pontuação de telecom de um desenvolvedor, de 31% para 67%, segundo a Sierra. Por fim, em 17–42% das execuções por configuração (38% para Codex, 42% para Claude Code, 21% para Kimi Code e 17% para OpenCode), os desenvolvedores fizeram ao menos uma tentativa de trapaça adjacente, como buscar dados de tarefas reservadas ou sondar o mecanismo de avaliação. Nenhuma teve sucesso; a Sierra disse que o padrão demonstra que o reforço do sandbox é tão importante quanto o design da tarefa.

A Sierra posicionou o hyper-τ-bench ao lado do MLE-bench e do RE-Bench, benchmarks que, segundo ela, medem a capacidade de pesquisa, como projetar experimentos, ponderar trade‑offs e iterar rumo a um sistema melhor. A construção de agentes traz problemas próprios, afirmou a empresa: a especificação deve ser recuperada a partir de documentos e pessoas, e o sistema que está sendo construído é ele próprio uma IA. A Sierra disse que continuará usando o hyper-τ-bench para monitorar quão bem os agentes lidam com esse trabalho à medida que assumem mais dessa tarefa por conta própria.