O benchmark de agentes de IA mostra que o harness muda o custo?

Quando o modelo é o mesmo e o resultado muda, a variável está fora do modelo

Um benchmark publicado pela Ora em agosto de 2026 rodou a mesma tarefa, com os mesmos modelos, em dois harnesses de agente e mediu diferenças de 7% em passos, 2x em sucesso nativo e 9% em endpoints válidos. Na sequência, a correção de um defeito de cache de prompt derrubou o custo total em cerca de 15%. O benchmark de agentes de IA que a Ora opera existe para responder exatamente a esta pergunta: quanto do custo e do sucesso do seu agente depende do ambiente que executa o modelo, e não do modelo em si. A conta muda. Para empresas que pagam por inferência, a resposta muda o que vale medir.

Contexto: a Ora mede se a web está pronta para agentes

A Ora é uma plataforma que roda agentes contra sites reais de clientes com a tarefa de se registrar em um produto, integrar com ele e pagá-lo, e registra o custo, a latência e o número de etapas de cada jornada. A estimativa da própria empresa é que 99% da web não está pronta para esse tipo de agente, um número que a Ora afirma, não uma medição independente.

Para a empresa que compra inferência, o efeito é direto. Duas equipes podem escolher o mesmo modelo, no mesmo provedor, com o mesmo preço de token publicado, e terminar o mês com custos por tarefa muito diferentes, porque a execução em volta do modelo não é igual. A fatura não discrimina essa diferença: ela mostra tokens consumidos e nada mais. É o mesmo padrão já discutido quando o custo real de uma aplicação de IA vai além do preço do token, e o caso da Ora dá a ele números atribuíveis.

O detalhe que interessa ao comprador B2B é o desenho do teste. Um agente tem duas partes: o modelo, que raciocina, e o harness, o software que fornece as ferramentas ao modelo e o conduz de etapa em etapa. Quando um agente falha em um fluxo de cadastro, a diferença pode estar no modelo, no harness ou no site, e sem instrumentação o resultado é uma nota sem causa atribuída. É por isso que a Ora executa um runtime separado para cada harness e registra o traço de cada etapa. Sem traço, não há causa.

Como o benchmark de agentes de IA da Ora funciona

O caso documentado comparou dois harnesses em centenas de jornadas reais, em múltiplos domínios, com uma tarefa idêntica para os dois: integrar com um produto. Os dois lados rodaram os mesmos modelos. Este benchmark de harness mantém o modelo fixo, e é isso que dá valor ao teste: qualquer diferença observada vem do harness e da infraestrutura em volta dele, não da troca de modelo.

Cada jornada registra três dimensões que a Ora publica: passos até concluir a tarefa, sucesso nativo no site do cliente e qualidade dos endpoints encontrados. A instrumentação é granular o suficiente para mostrar, quando um agente trava em um fluxo de cadastro, qual etapa travou e o que o agente tentou.

Resultados: o harness muda a conta com o modelo fixo

Os números publicados pela Ora, sempre atribuídos ao teste deles:

Nenhum desses números descreve um modelo melhor. Os modelos eram os mesmos. Os números descrevem execução.

O último número da tabela merece atenção separada. Durante os testes, uma rodada expôs um problema de cache de prompt. A equipe do harness corrigiu o defeito e a rodada seguinte mediu cerca de 15% menos custo total. A fonte não publica os controles dessa rodada subsequente: o que ela documenta é a sequência de defeito exposto pelo teste, correção aplicada e custo total menor na medição seguinte.

Há um limite honesto que o próprio caso impõe: os números comparam dois harnesses em jornadas de integração em sites de clientes. Os modelos eram os mesmos. Os números descrevem execução: quantos passos o harness gastou para chegar ao objetivo, com que frequência ele resolvia a tarefa no site do cliente sem recorrer à busca web e quão aproveitáveis eram os endpoints que encontrava no caminho. Eles não dizem que um harness é universalmente melhor que outro, nem que a diferença observada se replicaria em outros tipos de tarefa. O que os números transferem é o método, não o placar. Em um orçamento de inferência, cada uma dessas dimensões vira dinheiro: passos são chamadas, fallback é latência e custo extra, endpoint inválido é retry cobrado.

O que o caso ensina sobre medir agentes

1. Compare com o modelo fixo. Diferenças de passos, sucesso e custo entre configurações só significam algo quando o modelo é o mesmo nos dois lados. Trocar modelo e harness ao mesmo tempo deixa o resultado sem causa.
2. Meça por jornada, não por token. O custo de agentes de IA relevante é o de concluir a tarefa, que inclui retries cobrados, fallbacks e etapas desperdiçadas, não o preço do token multiplicado pelo volume.
3. Instrumente antes de otimizar. O ganho de 15% de custo só apareceu depois que o traço de execução expôs o problema de cache de prompt. Sem traço, o desperdício continua embutido na fatura.
4. Cache de prompt é um item de auditoria, não uma configuração. Ele degrada silenciosamente e o sintoma aparece como custo, não como erro.
5. Sucesso tem camadas. Concluir a tarefa no site do cliente sem cair em busca web é um resultado qualitativamente melhor do que concluir com fallback, e os dois somam "sucesso" em dashboards ingênuos.

Como aplicar isso na sua operação

Para quem roteia modelos em produção, o caso reforça uma disciplina que já aplicamos no custo por tarefa no roteamento de modelos: a unidade de decisão é a tarefa concluída, com o traço que mostra onde o custo aconteceu. O mesmo raciocínio vale para medir o desempenho dos provedores de LLM, porque a variação entre endpoints com o mesmo modelo já foi documentada em variabilidade do mesmo modelo por endpoint.

Três passos transferíveis, na ordem do caso:

1. Fixe o modelo e varie um fator por vez: harness, endpoint ou política de cache.
2. Registre o traço de cada jornada. Passos, latência, custo e tipo de sucesso, no formato que o traço de chamada LLM permite auditar. O traço vem primeiro.
3. Audite o cache de prompt antes de negociar preço ou trocar de modelo, porque é uma correção direta e fácil de ignorar.

Vale registrar também a diferença entre sucesso nativo e fallback, porque ela aparece em produção de forma silenciosa. Um agente que termina a tarefa buscando na web concluiu, no relatório. Falhou no que o cliente contratou: executar no seu próprio sistema. O traço que separa os dois resultados é o mesmo traço de chamada LLM que permite auditar request por request, e sem ele o sucesso agregado do dashboard esconde metade da história.

Quem já calcula o custo real de uma aplicação de IA além do preço do token reconhece o padrão: o custo que derruba a margem raramente está no número de marketing do modelo.

Perguntas frequentes

O que é o harness de um agente de IA? É o software que fornece ferramentas ao modelo e o conduz de etapa em etapa até concluir a tarefa. No benchmark da Ora, cada harness rodou com o mesmo modelo, o que isolou a diferença de resultado no harness e na infraestrutura.

O benchmark de agentes de IA da Ora é independente? É uma plataforma comercial da Ora, que vende justamente essa medição, e os números citados aqui vêm do caso publicado pela empresa em 2026-08-21. A estimativa de 99% da web não preparada para agentes é da própria Ora, não uma medição independente.

Como o cache de prompt reduziu o custo em 15%? Uma rodada de testes expôs um problema de cache de prompt. Após a correção pela equipe do harness, a rodada seguinte mediu cerca de 15% menos custo total, segundo a Ora. A fonte não detalha o mecanismo interno do defeito nem os controles da rodada de medição.

O que devo medir primeiro no custo do meu agente? Comece pelo traço por jornada: passos, latência, custo e se a tarefa concluiu no alvo ou com fallback. Com o traço em mãos, audite o cache de prompt, de correção direta, e só depois considere trocar de modelo.

Trocar de modelo resolve um problema de execução? Não necessariamente. O caso da Ora mostra diferenças de passos, sucesso e custo com o modelo fixo, o que significa que parte do custo pode estar no harness, no cache ou na infraestrutura. Trocar de modelo sem instrumentação move a variável sem identificá-la.

Referências

• Como a Ora avalia agentes de IA, caso publicado em 2026-08-21

Por onde começar

O traço vem antes da decisão de fornecedor. Antes de qualquer troca de modelo ou renegociação de contrato, produza o traço por jornada do tráfego atual: passos, latência, custo e tipo de sucesso, com o cache de prompt auditado. O caso da Ora sugere a ordem. Primeiro a instrumentação, depois a correção de execução, e só então a decisão de fornecedor. O Nexforce Router atua nessa camada com roteamento, logs e rastreamento por chamada, mantendo a medição consistente quando os modelos e endpoints mudam por trás da aplicação.