Seu agente passou no eval e falhou com o cliente

Observabilidade responde se está de pé, não se está certo

A instrumentação já é padrão de mercado. No State of Agent Engineering da LangChain, com 1.340 respostas publicadas em junho de 2026, 89% das organizações têm alguma forma de observabilidade nos agentes e 62% têm rastro detalhado de cada passo e cada chamada de ferramenta. Entre quem já roda agente em produção, os números sobem para 94% e 71,5%.

A avaliação anda bem atrás. Na mesma pesquisa, 52,4% rodam avaliação offline e 37,3% rodam avaliação sobre tráfego real. Ver o agente pensar virou rotina. Julgar se ele acertou, não.

A pesquisa da VentureBeat mede a mesma distância pelo outro lado: 51% das empresas monitoram apenas se o sistema está funcionando, contra 23% que monitoram se a resposta está correta. Somando quem revisa de forma pontual e quem não sabe responder, cerca de três quartos não têm checagem automática de correção em produção.

Tempo de resposta, custo e taxa de erro são métricas de sistema. Nenhuma delas responde se o agente escolheu a ferramenta certa, se usou o dado que recuperou ou se concluiu a tarefa que o usuário pediu. O painel fica verde enquanto a resposta sai errada.

Teste de software tradicional não descreve um agente

O teste clássico compara uma saída fixa com um valor esperado. A mesma entrada produz o mesmo resultado, e a comparação é binária. O agente quebra as três premissas: a saída é probabilística, o caminho tem muitos passos e cada passo aciona um sistema externo.

A aritmética da cadeia é implacável. Um fluxo de cem passos com 99% de acerto por passo termina certo em cerca de 37% das execuções. A qualidade do modelo por passo pode parecer excelente e a tarefa completa continuar falhando na maioria das vezes.

Avaliar apenas a resposta final esconde onde a corrida quebrou. O erro costuma nascer no meio: a ferramenta errada, o parâmetro trocado, o contexto que não chegou. É a mesma camada de integração que já tratamos em MCP e a camada de integração dos agentes.

O que medir: passo, ferramenta e tarefa

A suíte útil avalia o traço inteiro, não só o texto que sai no fim. Quatro medidas cobrem a maior parte das falhas de produção.

• Seleção de ferramenta: o agente chamou a ferramenta certa, com os parâmetros certos, na ordem certa.
• Fidelidade do passo: a resposta usa o que foi recuperado, sem inventar dado que a fonte não traz.
• Conclusão da tarefa: o pedido do usuário foi resolvido ponta a ponta, não apenas respondido com elegância.
• Política e segurança: o agente respeitou o limite de escrita, o dado sensível e a regra do negócio, inclusive sob instrução maliciosa.

O último item conversa direto com o vetor descrito em prompt injection e o perímetro de segurança da IA. Um caso de teste que injeta instrução hostil pela ferramenta vale mais que dez perguntas educadas no conjunto de avaliação.

O ciclo que fecha: offline, produção e regressão

A avaliação offline roda sobre um conjunto de casos com gabarito conhecido. É repetível, entra na esteira e serve de portão antes da entrega. O limite dela é conhecido: o conjunto envelhece e deixa de parecer com o que o usuário pergunta.

A avaliação sobre tráfego real cobre esse ponto cego. Ela mede a execução que ninguém previu, expõe a queda de qualidade ao longo do tempo e capta o pedido que não existia no laboratório. A documentação de referência da Microsoft para agentes em produção descreve o ciclo em uma linha: avaliar offline, entregar, observar a produção, coletar a falha nova, devolver ao conjunto offline.

A falha que não vira caso de teste volta. É esse laço que separa o piloto simpático da operação confiável, o mesmo padrão descrito em o abismo entre o piloto e a produção.

Sem suíte de regressão, toda troca vira aposta. Mudar um prompt, ligar uma ferramenta nova ou trocar o modelo do roteador passa a ser decisão sem evidência, exatamente o oposto do que descrevemos em a decisão de roteamento entre modelos.

O rigor da avaliação segue o nível de autonomia

Nem todo agente merece o mesmo portão. O Gartner classifica os agentes em quatro níveis de autonomia: observar, aconselhar, agir com aprovação humana e agir de forma autônoma. Cada nível representa uma fronteira de confiança diferente e pede um controle proporcional.

Aplicar o mesmo controle a todos falha nas duas pontas. Trava o agente simples, atrasa a entrega e empurra o time para a construção fora do radar da TI. Libera demais o agente autônomo e expande o risco operacional e de conformidade.

A conta chega depois. O Gartner projeta que, até 2027, 40% das empresas vão rebaixar ou desligar agentes autônomos por lacunas de governança identificadas apenas após incidentes em produção. O incidente é o método de descoberta mais caro que existe.

• Escreva o critério de aceite antes de construir o agente: o que conta como certo, o que é inaceitável e qual o limite mínimo de qualidade para entrar no ar.
• Instrumente o traço completo e avalie o passo, não apenas a resposta final. Sem rastro por passo, não há diagnóstico, só suposição.
• Ligue a suíte à esteira: nenhuma mudança de prompt, ferramenta ou modelo entra em produção sem rodar o conjunto de regressão.
• Ajuste o rigor ao nível de autonomia. Agente que só lê pede teste leve. Agente que escreve, paga ou responde ao cliente pede portão duro e desligamento rápido.

O inventário do que já roda continua sendo o pré-requisito, como tratamos em a IA que você não governa. Não se avalia o agente que ninguém sabe que existe.

A NN monta essa camada. Define o critério de aceite com a área de negócio, instrumenta o traço por passo, constrói o conjunto de regressão a partir das falhas reais e liga o portão à esteira de entrega. O agente sobe com evidência, não com impressão.

Observabilidade responde se o agente está de pé. Avaliação responde se ele está certo. Quem só tem a primeira descobre a segunda pelo cliente.