A maioria das equipes consegue ver o agente rodando. Dashboard com traces, logs de execução, latência por chamada de ferramenta. O que o agente fez ontem está registrado em algum lugar.
A pergunta mais difícil é outra. Ele fez bem?
O levantamento State of Agent Engineering, conduzido pela LangChain com 1.340 profissionais entre novembro e dezembro de 2025, coloca número nessa distância. 89% das equipes com agentes em produção têm observabilidade implementada. 52% têm avaliações sistemáticas.
O intervalo entre esses dois números é onde a qualidade dos agentes desaparece.
O que o trace não te diz
Um trace de execução te diz o que o agente fez. Quais ferramentas chamou, qual sequência seguiu, quanto tempo levou, onde retornou erro. É informação valiosa para depuração. Mas não te diz se o resultado foi bom.
Esse é o problema central dos agentes que não existe no software convencional: a saída é não determinística. A mesma entrada pode produzir respostas diferentes, todas tecnicamente válidas, algumas melhores do que outras. Não tem teste de unidade que resolva isso. Um teste de unidade afirma que para X a saída é exatamente Y. Um agente que responde "Sua solicitação está aprovada" e outro que responde "Pode prosseguir com a renovação" podem estar ambos corretos.
O time da Red Hat viveu esse problema ao construir um agente de self-service de TI. Testaram manualmente com casos pré-definidos e concluíram que o sistema funcionava. As avaliações automatizadas mostraram o contrário: a equipe tinha ajustado os prompts para os casos que conhecia, e casos fora desse conjunto quebravam. O teste manual não mente. Revela só o que você olhou.
Observabilidade sem avaliação é câmera de segurança sem analista. Você tem a gravação de tudo. Não sabe o que procurar.
A definição que vem antes
A resposta que a Red Hat encontrou, e que vai se tornando o padrão em times que colocam agentes em produção de verdade, tem nome. Eval-Driven Development.
A lógica é simples de enunciar. Antes de escrever o primeiro prompt, antes de escolher o modelo, antes de definir a arquitetura do agente, você define o que "bom" quer dizer. Especificamente. O que o agente precisa fazer para que você o considere correto naquele contexto.
Isso parece óbvio. Não é. O padrão dominante é o contrário: você prompta, testa com alguns exemplos, e quando parece razoável, manda pra frente. O problema é que "parece razoável" é uma afirmação sobre os exemplos que você escolheu. Não sobre o espaço completo de entradas que o agente vai encontrar em produção.
A diferença entre "o agente consegue fazer essa tarefa alguma vez" e "o agente faz essa tarefa de forma confiável na distribuição real de entradas" é exatamente onde a maioria dos pilotos de agentes trava. Não por falta de capacidade do modelo. Por falta de definição prévia do que "funcionar" significa.
Definir a avaliação primeiro não é só boa prática de engenharia. É o que torna o ciclo de melhoria possível. Sem critério explícito, você não consegue dizer se uma mudança de modelo, de prompt ou de contexto fez o agente melhorar ou piorar. Você só consegue dizer que continua razoável.
O loop que fecha
O que separa o time com 89% de observabilidade do time com 52% de avaliação não é acesso a ferramentas. É o loop.
Sem avaliação, o ciclo para em "observar". Você sabe que houve falha quando o usuário reporta. Investiga no trace. Ajusta algo. Volta a observar. A próxima falha pode ser a mesma, pode ser outra, mas você não tem como saber sistematicamente se melhorou.
Com avaliação, o ciclo fecha. Falhas de produção viram casos de teste rotulados. O conjunto de avaliação cresce com o que o agente errou de verdade. Mudanças de configuração são testadas contra esse conjunto antes de chegar ao usuário. A melhoria deixa de ser percepção e passa a ser mensurável.
É reliability engineering aplicado a um sistema não determinístico. O critério de sucesso não é um assert que passa ou falha. É um conjunto de métricas que você definiu antes de começar, com um juiz, geralmente outro modelo, que avalia o comportamento contra esses critérios.
32% dos times com agentes em produção citam qualidade como o principal obstáculo, segundo o levantamento da LangChain. Na minha leitura, esse número não vai mudar enquanto a maioria dos times tiver observabilidade sem avaliação. Ver o problema não é o mesmo que ter mecanismo de melhorá-lo.
A outra metade do spec
Na distribuição de valor do paradigma 70/30, o que fica com os humanos é sobre intenção, especificação, julgamento e validação. A execução comprimiu; o valor migrou para as pontas.
O que a maturidade de avaliação está tornando claro é que "validação" tem dois tempos. O primeiro é antes: definir os critérios que vão dizer se o agente acertou. O segundo é depois: verificar o comportamento contra esses critérios.
Spec-driven development cuida da entrada: especificar a intenção, o contexto e as restrições que o agente recebe. Eval-driven development cuida da saída: definir o que deve vir do outro lado. Um completa o outro. Sem os dois, você especificou o que o agente precisa entender e ficou torcendo pelo que ele vai produzir.
A habilidade que distingue os times que fecham esse loop não é técnica no sentido convencional. É a capacidade de dizer, com precisão, o que "certo" significa nesse contexto antes de perguntar ao agente se ele acertou.
89% observam. 52% avaliam. A diferença entre os dois grupos não aparece em nenhum dashboard.