Evals de agentes de IA: como saber se o seu está pronto para o trabalho

Atualizado em outubro/2026.

O que este artigo ensina

• O que são evals de agentes de IA: o conjunto de testes que mostra se um agente funciona de forma consistente, antes de ele errar na frente de um cliente ou de um auditor.
• A diferença entre testar um prompt e avaliar um agente: por que “parecer bom nos três testes que você fez” não é a mesma coisa que estar pronto para produção.
• As quatro coisas que um eval pode medir: a resposta final, o caminho que o agente percorreu até ela, os limites de segurança que ele respeita e se ele avisa quando não tem certeza.
• Como montar seu primeiro conjunto de teste sem escrever código, usando ferramentas como Claude Cowork, Gemini Spark ou ChatGPT Work.
• O que é o juiz automático (LLM-as-Judge), para que serve, onde ele não substitui uma pessoa e como conferir as notas dele antes de confiar nelas.
• Como pensar no custo de avaliar um agente, comparado ao custo de não avaliar.
• O que fazer depois que o agente foi aprovado: transformar cada erro real em caso de teste e acompanhar uma amostra do uso real toda semana.
• Onde evals entra no harness engineering: a parte de testes, que transforma os Sensors em prática e sustenta o uso do agente em escala.
• O que perguntar antes de aprovar um agente de IA na sua área, mesmo sem ser da área técnica.

Este artigo complementa o e-book gratuito Engenharia de Prompts na Prática, best seller na Amazon com mais de 950 avaliações, que ensina a escrever prompts para ChatGPT, Gemini e Claude. É a base para escrever as instruções do agente que você vai testar com o método deste artigo.

Você passou a tarde montando um agente no Claude Cowork para triar currículos da sua área. Ele lê o currículo, cruza com a vaga, escreve um parecer e sugere avançar ou não o candidato. Nos três testes que você fez na hora do almoço, funcionou bem. A pergunta que fica é outra: ele vai continuar acertando no currículo 47, no 300, ou no que menciona uma condição de saúde que os três primeiros nunca mencionaram?

Essa pergunta tem nome. Chama-se eval, abreviação do inglês evaluation, avaliação, e é a etapa do trabalho com IA que mais gente pula, por parecer coisa exclusiva de time técnico.

Numa área de negócio que hoje constrói o próprio agente sem escrever uma linha de código, essa etapa pertence a quem constrói, não só a quem programa por trás.

O que são evals de agentes de IA

Evals são os testes que mostram se um agente de IA faz o trabalho certo, de forma consistente, antes (e depois) de ele começar a operar de verdade. Em vez de julgar uma resposta isolada, um eval roda o agente contra um conjunto de casos representativos, o chamado golden dataset, e mede o resultado contra um critério que alguém definiu antes de o teste começar.

A palavra é nova para muita gente no Brasil, mas o problema que ela nomeia não é. Um agente que “parece bom” em três testes de almoço e um agente que foi avaliado contra cinquenta casos reais, incluindo os difíceis, são duas coisas diferentes, mesmo que os dois tenham gerado boas respostas até agora.

Por que isso virou problema de negócio, não só de TI

Um agente de recrutamento que erra num currículo isolado é um problema de RH. O mesmo agente, sem eval, rodando sozinho para toda a base de candidatos da empresa, é um problema de auditoria, de reputação e, dependendo do critério que ele aprendeu sozinho a aplicar, de discriminação sistemática numa escala que nenhum recrutador humano alcançaria num mês inteiro de trabalho.

Hamel Husain, consultor especializado em produtos de IA, resume o padrão: “produtos malsucedidos quase sempre compartilham a mesma causa raiz: a falha em criar sistemas de avaliação robustos”, escreveu em artigo de referência sobre o tema (2024). Traduzindo: o agente não falha porque o modelo é ruim. Falha porque ninguém definiu, antes de colocá-lo para trabalhar, o que conta como acerto.

A área que constrói o agente é quem sabe dizer o que é um acerto, não o time de TI. Um agente de contratos sabe que “resposta parece profissional” é diferente de “resposta usa a cláusula certa” só porque alguém do jurídico definiu isso. Esse é o motivo pelo qual evals virou trabalho de quem usa o agente todo dia, e não só de quem o programou.

Como funciona uma avaliação de agente, na prática

Uma avaliação de agente segue um ciclo simples de descrever, ainda que exija disciplina para manter.

1. Reúne-se um conjunto de casos reais, o golden dataset: não os três exemplos fáceis que você testou na hora do almoço, mas uma amostra que inclua os casos comuns e os difíceis, os que já deram problema antes e os que têm alta chance de acontecer de novo.
2. O agente roda contra cada caso desse conjunto, do mesmo jeito que vai rodar em produção.
3. Alguém (uma pessoa ou, em escala maior, um juiz automático) compara a resposta do agente com o critério de acerto definido antes do teste, não depois, para não ajustar o critério ao resultado que já saiu.
4. O resultado vira um relatório: quantos casos passaram, quais falharam e por quê.
5. O agente é ajustado, e o mesmo conjunto de teste roda de novo, para saber se o ajuste realmente resolveu o problema ou só mudou de lugar.

Esse ciclo é o que separa avaliar de simplesmente testar. Testar é rodar o agente algumas vezes e sentir se a resposta parece boa. Avaliar é repetir o mesmo conjunto de casos toda vez que algo muda, para comparar o antes e o depois com o mesmo critério.

Quem já trabalhou com engenharia de contexto para agentes de IA reconhece o princípio: um agente muda de comportamento quando o contexto muda, e só um teste repetível mostra se a mudança foi para melhor.

Quatro coisas que um eval pode medir num agente

Um eval pode medir quatro coisas num agente, e cada uma pega um erro diferente. A separação importa também para quem constrói um agente sem escrever código.

A resposta final. É o tipo mais óbvio: a resposta que o agente entregou está certa? O parecer de crédito chegou à decisão correta, o e-mail respondeu à pergunta real do cliente, o resumo do contrato não inventou uma cláusula que não existe. Esse é o teste que a maioria já faz de forma informal, mesmo sem chamar de eval.

O caminho que o agente percorreu. Além de responder, um agente usa ferramentas: consulta uma planilha, manda um e-mail, abre um sistema. Duas respostas finais podem ser idênticas e um dos dois caminhos até ela ser um problema, como um agente de RH que, para responder sobre férias de um funcionário, abriu também o histórico de avaliação de desempenho dele sem que ninguém tivesse pedido isso. A resposta saiu certa; o caminho não deveria ter passado por ali.

Os limites de segurança. Aqui o teste não pergunta se a resposta está certa, pergunta se o agente segue instrução escondida dentro de um documento que ele leu (um e-mail com um comando disfarçado de assinatura, por exemplo), se ele repete dado sensível que não deveria aparecer na resposta, ou se aceita pedidos fora do escopo que a área definiu para ele.

Se o agente sabe quando não sabe. Pense em dois analistas que erram o mesmo número de pareceres. O primeiro escreve “não tenho certeza, confere comigo” nos casos em que errou. O segundo assina todos com a mesma firmeza. Só o primeiro dá para gerenciar.

Com um agente de IA acontece o mesmo. Um eval que conta só acerto e erro esconde essa diferença e ainda premia o agente que chuta: uma pesquisa da OpenAI mostrou que avaliar só pelo acerto empurra o modelo a arriscar uma resposta em vez de admitir dúvida, porque “não sei” vale zero ponto.

Por isso eu recomendo separar o erro em dois: o que vem com dúvida sinalizada e o que vem dito com convicção. O segundo é o que chega ao cliente sem ninguém perceber.

Para medir, inclua no conjunto alguns casos em que a resposta certa é “não tenho informação suficiente” ou “encaminhar para uma pessoa”, como um currículo sem o registro profissional que a vaga exige. Antes de rodar, confira se a instrução do agente diz o que fazer quando falta informação, por exemplo: “se faltar um dado que a vaga exige, diga isso e encaminhe para uma pessoa”.

Na planilha em que você registra o resultado de cada caso, acrescente uma coluna: o agente sinalizou dúvida? Depois, olhe só os erros. Cada erro sem aviso é um ponto para reforçar na instrução e testar de novo. Um agente pronto acerta a maior parte dos casos e, quando erra, avisa.

O primeiro conjunto, de dez a vinte casos, já pode misturar os quatro tipos: alguns casos testam só a resposta, um ou dois testam se o agente usa a ferramenta certa e na ordem certa, pelo menos um tenta fazer o agente sair do escopo dele, só para confirmar que ele não sai, e dois ou três não têm informação suficiente para uma resposta segura.

O juiz automático: o que é LLM-as-Judge e onde ele ajuda

Quando o conjunto de teste tem dez casos, uma pessoa revisa cada resposta manualmente sem dificuldade. Quando passa a ter duzentos ou dois mil, porque o agente já processa esse volume por semana, revisão manual de cada caso deixa de ser viável. É aí que entra o LLM-as-Judge, o juiz automático: um segundo modelo de IA que aplica o critério de avaliação escrito por um humano e classifica cada resposta do primeiro agente como aprovada, reprovada ou duvidosa.

A técnica tem origem documentada: pesquisadores da UC Berkeley a descreveram no paper “Judging LLM-as-a-Judge”, de Lianmin Zheng e colegas (NeurIPS, 2023). O juiz automático escala a avaliação, mas não escala o julgamento em si: o critério que ele aplica ainda foi escrito por alguém que entende o assunto, e os casos que ele marca como duvidosos continuam exigindo revisão de uma pessoa.

Para quem constrói um agente numa área de negócio, a aplicação cabe em dois passos. Escreva o critério de acerto em linguagem simples, como “a resposta cita a cláusula correta do contrato-modelo” ou “o parecer não usa idade, gênero ou estado civil como critério de decisão”. Depois, peça à própria ferramenta de IA para rodar esse critério contra dezenas de casos e sinalizar os que fogem do padrão, sem que ninguém precise ler um por um.

Antes de confiar no juiz, compare com uma pessoa

O juiz automático também é um modelo de IA e, como pesquisadores da UC Berkeley mostraram, herda os tipos de erro do agente que ele avalia. Se ele errar, o relatório inteiro erra junto, com cara de número confiável.

No estudo de Berkeley que descreveu a técnica, os melhores juízes concordaram com pessoas em mais de 80% dos casos, perto do quanto duas pessoas concordam entre si. Esse número vale para aquele teste. O seu juiz, com o seu critério e os seus casos, precisa ser medido de novo.

A conferência leva poucas horas:

1. Separe de vinte a trinta respostas do agente.
2. Peça para alguém da área classificar cada uma como aprovada ou reprovada, sem ver a nota do juiz.
3. Compare as duas colunas.

Cada discordância aponta um de dois problemas: o critério escrito deixou margem para duas leituras, ou o juiz errou. No primeiro caso, reescreva o critério. No segundo, acrescente na instrução do juiz o caso em que ele errou, com a classificação que a pessoa deu e o motivo, e compare de novo.

O juiz está pronto quando as discordâncias que sobram são casos em que a própria pessoa da área hesitou. Se ele continua errando um mesmo tipo de caso, tire esse tipo do juiz e deixe com a pessoa.

Reescrever o critério depois de ver respostas é compatível com a regra de defini-lo antes do teste. O que não se faz é mudar a nota da rodada que já passou para o agente parecer melhor: anote na planilha que o critério mudou e em que data, rode o conjunto inteiro de novo com o critério novo e compare as rodadas seguintes com essa.

A equipe de Berkeley que mostrou que o juiz herda os erros do agente observou também que quem confere as respostas descobre, no meio da conferência, o que o critério deveria ter dito.

Repita a comparação sempre que mudar o critério ou trocar o modelo que faz o papel de juiz.

Quanto custa avaliar (e quanto custa não avaliar)

Montar o primeiro conjunto de teste custa principalmente tempo: alguém que já conhece a área precisa separar de dez a vinte casos reais, incluindo os difíceis, e escrever em poucas linhas o que conta como resposta certa. Não é um projeto de meses, é um exercício que cabe numa tarde, do mesmo jeito que montar o agente coube numa tarde.

O outro lado da conta é menos visível, porque acontece depois, quando o agente já está em produção. No artigo sobre custo de IA nas empresas, mostrei que a conta de IA generativa raramente para no preço por token.

O custo real de um agente mal avaliado aparece no retrabalho, na correção depois que o erro já chegou ao cliente, ou na explicação que alguém precisa dar quando um órgão jurídico ou regulador pergunta como aquela decisão foi tomada.

A conta que toda área de negócio deveria fazer não é “quanto custa testar”, e sim “quanto custa o primeiro erro que um teste teria pego”. Um parecer de crédito que nega errado, um contrato que cita a cláusula desatualizada, uma triagem de currículo que reproduz um viés: cada um desses casos custa mais do que as poucas horas que teriam sido gastas montando um conjunto de teste antes de o agente ir ao ar.

Onde os evals entram no harness engineering

Se você já leu sobre harness engineering, a estrutura de controles que envolve um agente autônomo, vai reconhecer o lugar exato onde evals se encaixa: dentro dos Sensors, o grupo de controles que verifica se cada resposta do agente está dentro do padrão esperado.

Evals é a forma mais concreta dos Sensors: é o teste real que alguém roda, com casos reais, antes de confiar no agente e depois de qualquer mudança nele. Sem evals, “ter Sensors” fica no discurso; com evals, vira prática que se repete toda vez que o agente muda.

A mesma lógica aparece no vocabulário de guardrails e agentes autônomos: guardrail impede que o agente faça algo proibido em tempo real, e eval mede, antes disso, se o agente costuma se comportar bem quando ninguém está olhando por cima do ombro dele.

Na separação em três partes que uso para explicar o harness (o núcleo de controle, o contexto e os testes), evals é a ferramenta principal da terceira e a condição para levar um agente de uma pessoa para uma área inteira. Para registrar isso agente por agente, a ficha do agente tem uma linha para as conferências e outra para o conjunto de teste.

Como montar seu primeiro conjunto de teste sem escrever código

Os passos abaixo são os mesmos independentemente de o agente ter sido construído no Claude Cowork, no Gemini Spark ou no ChatGPT Work: nenhuma das três ferramentas exige código para rodar um conjunto de teste, e o raciocínio de montar o teste não muda de uma para outra.

Separe de dez a vinte casos reais, não inventados. Puxe da própria área: e-mails, tickets, contratos ou currículos que já passaram por ali, incluindo pelo menos três ou quatro que sejam difíceis de propósito (o caso ambíguo, o que quase deu errado da última vez, o que foge do padrão comum).

Quando a decisão do agente puder ser influenciada por idade, gênero, raça ou outro atributo protegido, inclua pelo menos um caso desenhado para revelar isso, como dois currículos equivalentes que só variam nesse atributo.

Escreva o critério de acerto antes de rodar qualquer teste, em linguagem simples, como se estivesse explicando para um estagiário novo o que diferencia uma resposta boa de uma ruim. Frases como “a resposta cita a fonte correta” ou “o parecer não usa idade, gênero ou estado civil como critério” funcionam melhor do que “a resposta deve ser profissional”, porque um critério vago não dá para verificar.

Rode o agente contra cada caso e registre o resultado numa planilha simples, com uma coluna para o caso, uma para o critério esperado, uma para a resposta que o agente deu e uma para aprovado ou reprovado. Para automatizar essa rodada, uma instrução como a abaixo, dada à própria ferramenta ou a um segundo agente no papel de juiz, já resolve:

Aqui está uma lista de casos de teste e o critério de aprovação de cada um.
Para cada caso, rode o agente [nome do agente] com a entrada indicada,
compare a resposta com o critério e classifique como APROVADO, REPROVADO
ou DUVIDOSO. Quando marcar REPROVADO ou DUVIDOSO, explique em uma frase
o que divergiu do critério.

Guarde esse conjunto de casos e rode ele de novo toda vez que mudar alguma instrução do agente, e também quando a ferramenta por trás dele (ChatGPT, Gemini ou Claude) lançar uma atualização de modelo, mesmo sem você ter mudado nada.

Esse é o passo que a maioria pula, porque parece redundante quando o agente “já estava funcionando”. É exatamente o passo que revela se um ajuste resolveu um problema sem criar outro em algum caso que não estava sendo olhado.

Depois da aprovação: o eval continua trabalhando

A aprovação mostra que o agente funcionou nos casos que você conhecia no dia do teste. A partir daí, duas coisas mudam sem aviso: os casos que chegam e o próprio modelo por trás do agente.

Todo erro real vira caso de teste

Quem monta o primeiro conjunto escolhe os casos a partir do que já viu dar errado ou consegue prever. O erro que chega ao cliente costuma vir de uma situação que ninguém da área tinha pensado em testar.

Por isso eu recomendo uma regra só: cada erro que aparecer no uso real, e cada erro que alguém pegou a tempo, vira caso novo no conjunto de teste. O erro pego a tempo é o quase-erro, como o parecer que o gestor corrigiu antes de enviar ao cliente.

O guia da Anthropic sobre evals de agentes recomenda a mesma coisa a quem constrói agentes: transformar em caso de teste as falhas que chegam pela fila de suporte e pelas reclamações, começando pelas que mais afetam o usuário.

Na planilha, uma coluna de origem resolve: “conjunto inicial” ou “uso real”, com a data em que o erro apareceu. Quando essa segunda categoria para de crescer, das duas uma: ou o agente parou de encontrar situação nova, ou ninguém está registrando os erros.

Quando o agente piora sem ninguém mexer nele

Volte ao agente que tria currículos. Ninguém mudou uma instrução, e ele começou a errar mais. Duas explicações possíveis: o fornecedor atualizou o modelo por trás da ferramenta, ou os currículos mudaram, por exemplo porque mais candidatos passaram a escrever com ajuda de IA.

A primeira já foi medida. Pesquisadores de Stanford e da UC Berkeley compararam as versões de março e de junho de 2023 do GPT-4: na mesma tarefa de identificar números primos, o acerto caiu de 84% para 51%. O nome do produto continuava o mesmo, e quem usava não tinha mudado nada do lado dele.

Rodar o conjunto de novo quando você muda alguma coisa, ou quando o fornecedor anuncia um modelo novo, só pega a mudança que alguém avisou. O complemento é uma amostra semanal do uso real:

1. Separe vinte casos que o agente atendeu na semana, de dias diferentes, sem olhar o resultado antes.
2. Passe esses casos pelo mesmo critério, com o juiz já conferido.
3. Compare com a semana anterior.

Mais casos duvidosos, mais correções feitas por pessoas ou queda na taxa de aprovação são o sinal para agir antes que o cliente perceba. Comece rodando o conjunto de teste inteiro. Se ele também piorou, a mudança veio do modelo: avise quem cuida da ferramenta e aumente a revisão humana até o conjunto voltar a passar.

Se o conjunto continua passando, a mudança está nos casos que chegam, e os que falharam na amostra viram casos novos no conjunto. Eu reservaria meia hora por semana, na agenda de uma pessoa da área, para olhar esse resultado.

Por onde começar

Antes de aprovar um agente de IA para operar sozinho na sua área, cinco perguntas separam quem testou de quem só torceu para dar certo:

1. Em quais casos reais, incluindo os difíceis, o agente foi testado, e o critério de acerto foi escrito antes do teste?
2. Se existe juiz automático, alguém da área comparou as notas dele com as suas?
3. A planilha separa o erro que o agente avisou do erro que ele afirmou com convicção?
4. Quem revisa os casos que o juiz marca como duvidosos, e quem coloca cada erro real no conjunto de teste?
5. Quando o conjunto roda de novo, e quem olha a amostra semanal do uso real?

Se alguma resposta for “ninguém” ou “ainda não”, o agente pode entrar em uso com uma pessoa revisando cada resposta antes de ela sair da área. Ele só passa a operar sozinho quando as cinco perguntas tiverem resposta com nome e data.

Se você chegou direto a este artigo: ele faz parte do guia “Harness Engineering”. Para conhecer o guia completo, visite a página de guias.

Comunidade no WhatsApp: as novidades de ferramentas, modelos e uso de dados no trabalho saem todo dia no grupo IA e Dados, sempre com a fonte. Veja como entrar no grupo.

Perguntas frequentes sobre evals de agentes de IA

O que são evals de agentes de IA?

Evals (abreviação de evaluations, avaliações) são o conjunto de testes que mostram se um agente de IA faz o trabalho certo, de forma consistente, antes e depois de entrar em uso real. Em vez de julgar uma resposta isolada, um eval roda o agente contra um conjunto de casos representativos (o golden dataset) e mede o resultado contra um critério definido antes do teste.

Qual a diferença entre avaliar um agente e só testar um prompt?

Testar um prompt é rodar uma instrução algumas vezes e ver se a resposta parece boa. Avaliar um agente é medir o comportamento dele contra um conjunto de casos fixos, com critério de aprovação definido antes do teste, de forma repetível: o mesmo conjunto de casos pode rodar de novo depois de qualquer mudança no agente, para saber se ele melhorou, piorou ou ficou igual.

Quantos casos preciso ter no meu primeiro conjunto de teste?

Um primeiro conjunto de dez a vinte casos reais já é suficiente para começar, desde que inclua os casos comuns e pelo menos três ou quatro difíceis: o ambíguo, o que já deu problema antes e, quando aplicável, um caso desenhado para revelar viés. O número cresce depois: cada erro que aparece no uso real, e cada erro que alguém pegou antes de chegar ao cliente, vira caso novo no conjunto.

Um eval avalia só a resposta final do agente de IA?

Não. Um eval pode medir quatro coisas: se a resposta final está certa, o caminho que o agente percorreu até ela (quais ferramentas usou e em que ordem), os limites de segurança que ele deveria respeitar (não seguir uma instrução escondida dentro de um documento, não repetir um dado sensível na resposta) e se ele avisa quando não tem certeza. Um conjunto de teste inicial pode misturar os quatro tipos.

O que é LLM-as-Judge (juiz automático)?

LLM-as-Judge é o uso de um modelo de IA para avaliar a resposta de outro agente de IA, aplicando um critério escrito por um humano. Serve para escalar a avaliação quando existem centenas ou milhares de casos, o que inviabilizaria revisão humana de cada um. Não substitui a revisão humana nos casos mais delicados nem na criação do próprio critério de avaliação, que continua sendo trabalho humano.

Preciso saber programar para montar evals de um agente de IA?

Não para o primeiro conjunto de teste. Quem constrói agentes em ferramentas como Claude Cowork, Gemini Spark ou ChatGPT Work pode montar um conjunto inicial de casos reais, escrever em linguagem simples o que conta como acerto e erro, e pedir para a própria ferramenta rodar o agente contra esses casos e apontar divergências. Programação entra depois, quando o volume de casos justifica automatizar a rotina.

Evals substituem a revisão humana de um agente de IA?

Não. Evals reduzem quanto um humano precisa revisar caso a caso, mas alguém ainda decide o que é uma resposta certa antes de qualquer teste rodar, define quais casos entram no conjunto de teste e revisa os casos que o próprio sistema de avaliação sinalizar como incertos. A parte que escala é a repetição do teste, não o julgamento inicial do que é qualidade.

Como saber se o juiz automático (LLM-as-Judge) é confiável?

Comparando as notas dele com as de uma pessoa da área. Separe de vinte a trinta respostas do agente, peça para alguém classificar cada uma sem ver a nota do juiz e compare. Onde discordam, ou o critério deixou margem para duas leituras e precisa ser reescrito, ou o juiz errou e precisa ver o caso com a classificação certa. Repita sempre que mudar o critério ou o modelo que faz o papel de juiz.

O que é calibração num agente de IA?

É a capacidade do agente de sinalizar dúvida quando pode estar errando, o quarto tipo de teste de um eval. Quando erra, um agente calibrado costuma avisar que não tem certeza, em vez de responder com a mesma firmeza com que acerta. Para medir, inclua no conjunto de teste casos em que a resposta certa é admitir que falta informação e registre, em cada erro, se o agente sinalizou dúvida.

Preciso continuar avaliando o agente depois que ele foi aprovado?

Sim. O modelo por trás do agente pode ser atualizado pelo fornecedor sem aviso, e os casos que chegam mudam com o tempo. Duas rotinas cobrem isso: todo erro real e todo erro pego a tempo entram como caso novo no conjunto de teste, e uma amostra semanal do uso real passa pelo mesmo critério, para comparar com a semana anterior.

Quanto custa fazer evals de um agente de IA?

Depende do tamanho do conjunto de teste e de quanto dele passa por um juiz automático, mas o primeiro conjunto de dez a vinte casos reais custa principalmente o tempo de quem conhece a área para escrever os casos e o critério de acerto. O outro lado da conta é o custo de não avaliar: o erro que um agente sem teste comete já em uso, na frente de um cliente ou de um órgão regulador.

Onde os evals entram no harness engineering?

O harness tem três partes: o núcleo de controle (o que o agente pode fazer e quando para), o contexto (o que ele sabe ao agir) e os testes. Evals é a ferramenta principal da terceira parte e a forma mais concreta dos Sensors, as conferências que verificam cada resposta. É também o que permite levar um agente de uma pessoa para uma área inteira, porque o mesmo conjunto de teste roda de novo a cada mudança.

Edney “InterNey” Souza atua com tecnologia desde 1990 como professor, palestrante e conselheiro consultivo em tecnologia, IA, dados e inovação. Participou da criação de sete startups ao longo da carreira. É professor na ESPM, Insper, PUCRS, USP e IBGC. É autor do livro gratuito Engenharia de Prompts na Prática: do Zero ao Avançado com ChatGPT, Gemini e Claude.