Seu agente de IA passou em todos os testes. O financeiro ainda matou o projeto

O agente de IA passou em todas as métricas do framework de avaliação. E foi desligado de qualquer jeito.

Pratik Rupareliya, engenheiro que publicou um framework de doze métricas para avaliação de agentes de IA há dois meses, estava na sala quando a decisão foi tomada. Uma empresa SaaS de médio porte havia construído um agente de atendimento ao cliente para lidar com tickets de cobrança e conta. O agente havia sido instrumentado contra as doze métricas: conclusão de tarefa, fidelidade, precisão de recuperação, acurácia de chamadas de ferramentas, latência, taxa de alucinação. Todas as métricas estavam verdes. O agente estava, por qualquer medida que o framework capturava, funcionando.

Então a CFO abriu o laptop e colocou um único número na tela. O custo por ticket resolvido — incluindo os tickets que o agente tentou e não conseguiu resolver — era maior do que o que a empresa pagava para humanos fazerem o mesmo trabalho. Não foi por erro de arredondamento. O fluxo assistido por agente estava custando mais caro por ticket resolvido do que o fluxo 100% humano que deveria substituir.

O buraco no framework de avaliação

O framework de doze métricas foi construído para responder a uma pergunta específica: este agente está se comportando corretamente em produção? Ele cobre os modos de falha que tornam um agente errado: recuperação que traz contexto incorreto, geração que alucina, chamadas de ferramenta com argumentos ruins, loops de raciocínio que nunca terminam. Cada métrica isola uma forma de o agente produzir um resultado errado.

Mas nenhuma das doze métricas é uma métrica econômica. O framework mede se o agente está certo. Não mede se o agente se paga.

A narrativa no início de 2026 era de que a inferência estava ficando mais barata e o verdadeiro desafio era a confiabilidade. “Meça a qualidade”, dizia o pensamento, “e a economia se resolve sozinha.” A economia não se resolveu sozinha. Os custos de inferência por token continuaram caindo, mas as arquiteturas de agentes ficaram mais vorazes mais rápido do que os tokens ficaram mais baratos. Uma única resolução de agente em 2026 não é uma chamada de modelo — é um passo de planejamento, várias chamadas de ferramenta, algumas passagens de raciocínio, às vezes um loop de autocrítica, às vezes uma nova tentativa após falha de ferramenta, e uma síntese final. O preço do token caiu, os tokens por resolução subiram, e para muitos fluxos de trabalho o segundo efeito venceu.

A métrica que faltava: custo por resultado bem-sucedido

A métrica que o framework precisava é custo por resultado bem-sucedido (cost per successful outcome). Não custo por chamada. Não custo por token. Não acurácia. O custo totalmente carregado de produzir um resultado de negócio bem-sucedido, dividido pelo número de resultados bem-sucedidos.

A palavra que faz o trabalho nessa definição é bem-sucedido. Custo por chamada é fácil e enganoso. Custo por resultado bem-sucedido é difícil e honesto. A diferença entre eles é onde a economia da empresa SaaS deu errado.

Veja a aritmética que matou o agente (números arredondados para proteger o cliente, mas a estrutura é fiel):

• O agente tentava cada ticket recebido. Cada tentativa custava aproximadamente US$ 3,40 em inferência totalmente carregada.
• O agente resolvia 71% dos tickets com qualidade alta (confirmada pelo framework).
• Os outros 29% eram escalados para um humano após a tentativa.

Em mil tickets: o agente gasta US$ 3.400 tentando todos. Resolve 710 e escala 290. Esses 290 escalonamentos vão para um humano a aproximadamente US$ 4,20 cada, mais US$ 1.218. A empresa pagou US$ 4.618 para resolver mil tickets que teriam custado US$ 4.200 só com humanos. O fluxo assistido por agente era 10% mais caro que o fluxo que substituiu.

Agora a métrica que realmente importa: custo por resultado bem-sucedido do agente é US$ 3.400 dividido por 710 = US$ 4,79 por ticket resolvido. Cada ticket que o agente resolveu com sucesso custou efetivamente US$ 4,79, porque o custo das tentativas que falharam precisa ser carregado pelas que tiveram sucesso. Um humano resolvia o mesmo ticket por US$ 4,20. O agente era mais preciso e 59 centavos mais caro em cada sucesso — antes mesmo de contar o pagamento duplo nos escalonamentos.

Por que é mais difícil medir do que parece

Se custo por resultado bem-sucedido é a métrica que decide a sobrevivência, a pergunta óbvia é por que as equipes já não a monitoram. A resposta é que é genuinamente difícil de calcular, por três razões específicas:

1. Atribuição de tentativas falhas. O custo de um resultado bem-sucedido inclui o custo das falhas no caminho até ele. Quando um agente tenta um ticket, gasta US$ 3,40 e depois escala, esses US$ 3,40 não produziram um resultado bem-sucedido, mas são um custo real de operação do sistema. A maioria das equipes instrumenta custo por chamada, vê um número confortável, e nunca faz a divisão que revela o valor real.

2. Pagamento duplo no escalonamento. Em qualquer fluxo com humano no loop, uma tentativa falha do agente não substitui o custo humano — ela se soma a ele. A empresa paga pelo agente tentar e depois paga pelo humano terminar. Abaixo de uma certa taxa de resolução, o desvio economiza menos do que as tentativas falhas custam, e o agente se torna um imposto sobre o fluxo humano em vez de um substituto.

3. O valor de negócio de um resultado nem sempre é um número limpo. Para um ticket de suporte, o valor é o custo carregado da alternativa humana — algo conhecido. Para um agente que qualifica um lead de vendas, ou redige uma cláusula de contrato, ou faz triagem de um alerta de segurança, o valor de um resultado bem-sucedido é um exercício de modelagem, não uma consulta.

O limiar que decide a sobrevivência

Uma vez que você consegue calcular o custo por resultado bem-sucedido, o teste de sobrevivência é uma única comparação: o custo por resultado bem-sucedido precisa ficar abaixo do valor de negócio daquele resultado, com margem suficiente para justificar a sobrecarga operacional de rodar o agente.

O limiar tem uma propriedade perigosa: ele se move contra você conforme o fluxo escala, não a favor. A intuição do software tradicional é que custos unitários caem com escala. Custos unitários de agentes frequentemente não caem, porque cada unidade de trabalho é sua própria execução de inferência e não fica mais barata com volume.

O que isso significa para times de MLOps em 2026

A lição do caso da empresa SaaS não é que agentes de IA não funcionam. É que agentes precisam de métricas econômicas tanto quanto de métricas de qualidade. Um agente que passa em todos os testes de acurácia, fidelidade e latência ainda pode estar economicamente submerso — e a economia, não a qualidade, é o que decide quais agentes permanecem em produção.

Para times que estão colocando agentes em produção agora, Rupareliya sugere incluir o custo por resultado bem-sucedido como a décima-terceira métrica do framework. A pergunta não é apenas “o agente está certo?” — é “o agente se paga?” E se a segunda resposta for não, a primeira não importa.