O demo do agente funcionou. Rodou três vezes na sua tela, respondeu certo, chamou a ferramenta certa, e alguém decidiu que estava pronto pra ir pro cliente. É exatamente aí que a maior parte dos problemas de agente de IA em produção nasce: ninguém testou o que acontece na quarta vez, na centésima, ou quando o dado que chega é o dado torto que o cliente realmente manda.
O gap que os números confirmam
O relatório State of Agent Engineering de 2026 da LangChain, com mais de 1.300 respostas de quem constrói agentes no dia a dia, mostra o tamanho do problema: 57% das organizações já têm agentes em produção, contra 51% no ano anterior. Até aqui, adoção normal.
O problema aparece na linha de baixo: 89% das equipes implementaram observabilidade (dashboards, tracing, logs) para os próprios agentes, mas só 52% implementaram avaliação (eval), o processo de medir, com critério, se o agente está fazendo a coisa certa. E qualidade, não custo, é o motivo mais citado para um agente não sair do estágio de piloto.
Traduzindo: a maioria sabe que o agente está rodando. A minoria sabe se ele está certo.
Por que agente é mais difícil de avaliar que chatbot
Um chatbot de pergunta e resposta tem uma saída: o texto que ele devolve. Dá pra comparar com uma resposta esperada e pronto. Um agente não funciona assim: ele dá vários passos, chama ferramentas, muda o estado de um sistema externo (agenda uma reunião, edita uma planilha, manda uma mensagem) e ajusta o próximo passo com base no que aconteceu no anterior.
A Anthropic descreve isso em "Demystifying evals for AI agents": a mesma flexibilidade que faz o agente ser útil é o que faz ele ser difícil de avaliar. Um agente pode chegar no resultado certo por um caminho errado, ou parecer ter dado certo enquanto deixou o sistema num estado que vai quebrar outra coisa daqui a duas horas. Julgar só a resposta final esconde os dois problemas.
A recomendação prática de lá é avaliar em camadas, porque cada camada pega um tipo de erro diferente:
| Camada | O que pega |
|---|---|
| Evals automatizados | Regressão óbvia antes de qualquer deploy |
| Monitoramento em produção | Comportamento que só aparece com tráfego real |
| Teste A/B | Se a mudança melhora o resultado de verdade, não só na sua hipótese |
| Feedback do usuário | O que o número não capta mas a pessoa sente |
| Revisão de transcript | O porquê de um resultado, não só o se deu certo |
| Estudo humano estruturado | Casos raros e de alto risco que nenhuma métrica cobre sozinha |
Nenhuma camada substitui as outras. Um agente que só tem dashboard de uptime está observando; não está avaliando.
Eval-driven development: como construir sem virar projeto de mês
A parte que costuma travar quem nunca fez isso é achar que eval exige um dataset gigante e uma equipe dedicada. A Anthropic recomenda o oposto: comece com 20 a 50 tarefas simples tiradas de falhas reais que o agente já cometeu (ou que você já viu em produtos parecidos), não de casos hipotéticos inventados na sala de reunião. Amostra pequena funciona porque, no início, cada correção tem efeito grande: dá pra ver a diferença sem precisar de mil exemplos.
O princípio que sustenta isso é "eval-driven development": construir a avaliação antes da capacidade existir, com o critério de sucesso definido por escrito, e só então construir o agente na direção desse critério. É o inverso do que a maioria faz, construir o agente, mostrar que funciona numa demo, e só depois perguntar como vai medir se ele continua funcionando.
E a avaliação em si tem duas partes que precisam vir separadas: primeiro julgar o resultado (a tarefa foi cumprida? o estado do sistema ficou correto?), depois, só depois, ler o transcript pra entender o motivo. Confundir as duas etapas é o erro mais comum: quem lê o transcript primeiro acaba julgando o resultado pela impressão de "parece que fez sentido", que é exatamente o viés que o eval existe para evitar.
A prova de que isso não é modinha de blog técnico
Se avaliação fosse só recomendação de melhores práticas, dava pra ignorar. O que torna isso inegociável é o que a própria OpenAI fez com o produto dela: em 3 de junho de 2026, avisou que a plataforma Evals, a ferramenta separada, com interface própria, que a empresa vendia justamente para isso, está sendo descontinuada. Fica somente leitura a partir de 31 de outubro de 2026 e sai do ar em 30 de novembro de 2026.
O motivo declarado não é falta de demanda por avaliação. É o contrário: a OpenAI está movendo a avaliação para dentro do Agents SDK, como "trace graders" que rodam no mesmo lugar onde o agente é construído e testado, em vez de uma ferramenta à parte que alguém precisa lembrar de abrir depois. O sinal da indústria é claro: eval não é um produto que você compra e cola por fora. É parte do loop de construção, ou não é levado a sério.
O que isso muda em quem constrói
Se você constrói (ou terceiriza a construção de) um agente de IA que vai automatizar algo real, responder cliente, decidir preço, mexer em agenda, tocar dinheiro, três mudanças práticas saem direto do que os dados acima mostram:
- Peça o eval antes do deploy, não depois do primeiro chamado do cliente reclamando. Se ninguém consegue te mostrar 20 a 50 casos reais em que o agente foi testado, o "funciona" que você está vendo é só a demo.
- Separe monitorar de avaliar. Dashboard de uptime e log de chamada são observabilidade. Eles dizem que o agente rodou, não que ele fez a coisa certa. São ferramentas diferentes, resolvem perguntas diferentes.
- Julgue o resultado no sistema, não o texto da resposta. Pergunta certa: "o estado ficou correto depois que o agente agiu?". Pergunta que engana: "a resposta pareceu coerente?".
Nenhuma dessas mudanças exige comprar ferramenta nova. Exige tratar avaliação como parte do trabalho de construir o agente, não como etapa de QA que alguém faz se der tempo.