*A conversa não é o resultado

Imagine um assistente de uma loja fictícia de materiais de escritório. O cliente pede para acrescentar duas caixas de papel ao carrinho. A resposta chega rapidamente: “Pronto, atualizei”. Mas o carrinho continua igual. A linguagem funcionou; a tarefa falhou.*

No guia técnico da Anthropic publicado em jan. 9, 2026, a avaliação de agentes distingue o registro da execução do estado final do ambiente. O texto também propõe combinar verificações por código, avaliações por modelo e revisão humana, conforme a natureza de cada critério. Essa distinção oferece uma base útil: a qualidade da conversa e o sucesso operacional precisam de evidências diferentes.

Fonte: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

Um teste pequeno que revela um problema grande

Nossa proposta de exercício é começar com um carrinho sintético e uma API de teste, sem clientes ou pagamentos reais. Registre o estado inicial e peça uma única alteração. Ao terminar, consulte o carrinho por uma leitura independente da resposta do agente.

Para esse cenário, a aprovação exige três condições: o produto correto recebeu a quantidade solicitada; os demais itens permaneceram iguais; e a mensagem final descreveu o estado efetivamente confirmado. São critérios sugeridos para o exemplo, não resultados medidos de uma implementação.

Agora acrescente variações. A API pode rejeitar a solicitação; o produto pode não existir; a resposta da ferramenta pode chegar depois do limite de espera. Em cada caso, defina antes o comportamento aceitável. Uma falha explícita não deve virar uma confirmação de sucesso. Uma resposta ambígua exige reconciliação do estado, não uma nova alteração às cegas.

O que observar além do “passou”

Guarde separadamente a entrada, o estado inicial, as chamadas de ferramenta, os retornos e a leitura final. Use identificadores sintéticos para relacionar esses elementos. Assim, quem analisa o teste consegue distinguir uma interpretação errada de um problema na integração.

Para o piloto, recomendamos acompanhar três dimensões em paralelo: conclusão correta da tarefa, fidelidade da mensagem ao resultado e tempo total até a confirmação. Uma média favorável de tempo não compensa uma alteração incorreta. Também vale classificar falhas por impacto: dizer que concluiu sem comprovação pode exigir um bloqueio de liberação, conforme o risco do produto.

O critério precisa ser definido por quem entende o processo. Engenharia verifica o estado; Produto explicita o que significa sucesso; atendimento ajuda a avaliar se a explicação é compreensível. Quando houver um avaliador baseado em IA, compare suas notas com revisão humana antes de confiar nelas como requisito de lançamento.

O motivo atual para manter testes portáveis

Há também uma mudança concreta de ferramenta a considerar. Em atualização de jun. 3, 2026, a OpenAI anunciou o encerramento dos produtos Agent Builder e Evals. A documentação consultada em out. 9, 2026 informa que Evals ficará somente para leitura para usuários existentes em out. 31, 2026, com encerramento previsto para nov. 30, 2026.

Fontes: https://openai.com/index/introducing-agentkit/

https://developers.openai.com/api/docs/guides/evaluation-getting-started

A recomendação editorial que tiramos desse aviso é manter casos, critérios e evidências exportáveis, sob controle da equipe. Isso não significa que exista uma migração automática entre fornecedores. Significa reduzir a dependência de uma única interface para preservar o conhecimento sobre o que o seu agente deve fazer.

Uma aplicação prática para esta semana

Escolha uma operação pequena e reversível em ambiente de teste. Escreva um caso normal, um caso com informação insuficiente e um caso de falha da integração. Defina o estado esperado e a mensagem aceitável antes de executar. Compare a versão atual com uma mudança de prompt ou modelo, mantendo os mesmos casos e condições.

Depois, revise uma falha junto com alguém de Produto. A pergunta mais útil é: qual evidência faltou para sabermos que a tarefa terminou? Essa resposta costuma orientar melhor a próxima melhoria do que pedir ao agente para “ser mais cuidadoso”.

Conclusão

Um agente confiável precisa conectar intenção, execução e confirmação. Começar com poucos testes verificáveis ajuda a tornar essa conexão explícita. O valor está em saber por que uma tarefa passou, por que falhou e o que precisa continuar verdadeiro na próxima versão.