Resumo
- Para um piloto de agente existir, ele precisa ser aprovado. Para ser aprovado, precisa de uma demo. E o agente que funcionaria em produção é justamente o que faz a pior demo.
- Uma análise de 73 incidentes reais mostra do que se morre: falhas banais de ferramenta e contexto. E a causa que ninguém registra: o provedor caiu, ou o filtro de política mudou, e não havia plano B.
- Os sobreviventes se parecem entre si: escopo fechado, recusa explícita, rastro completo e prova.
- Eval é o CI do agente. As três perguntas estão na seção 5, e dá para responder numa reunião.
1. O problema é a demo
A estatística de que a maioria dos pilotos de agente nunca chega à produção aparece em todas as pesquisas, e circulou tanto que virou papel de parede. Papel de parede não muda decisão: todo mundo concorda e segue fazendo igual.
Então, em vez de repetir a estatística, vale olhar as premissas. Imagine o seguinte: um projeto de um agente que será implantado na área X com o time Y. Parece que vai trazer eficiência, redução de custos, escala… certo. Mas como esse projeto é aprovado? Para ter alguma chance, inclusive de falhar, ele precisa ser aprovado. Para ser aprovado, precisa de um patrocinador. Patrocinador quer ver planejamento, estimativa, prazo, algum número de retorno. Alguém monta o deck, alguém defende na reunião. E tem uma coisa que não pode faltar.
Uma demo, claro. Ao vivo, de preferência.
E a demo tem as próprias leis. Ela roda no caminho feliz, com o dado ensaiado, na conta de teste, com a API de bom humor. Ela tem uns cinco minutos para convencer gente ocupada, então quanto mais coisas o agente fizer nesses cinco minutos, melhor ela cumpre o papel dela. Ninguém se levanta da cadeira com o slide do escopo fechado; a sala se levanta quando o agente responde o cliente, consulta o CRM e agenda a reunião sem ninguém encostar no teclado.
Esse é o problema. A demo.
O critério que decide se o projeto nasce não tem relação nenhuma com o critério que decide se ele sobrevive. O mesmo agente que funcionaria em produção não é o mais atraente numa demo. Agentes que sobrevivem são justamente os que fariam a pior demo.
O agente que brilha na demo é outro bicho. É o bot de WhatsApp que responde ao cliente, consulta o CRM, gera a arte da promoção, agenda a reunião e promete resolver tudo. São dez habilidades na apresentação, e nenhuma delas tem critério de sucesso, dono ou teste. Quando vai para produção, cadastra errado no CRM, manda a arte para o cliente errado, e quando alguém reclama, ninguém consegue dizer qual das dez habilidades quebrou primeiro.
No fim, a sala aprova o agente que surpreende. Só que a produção é o lugar onde sobrevive quem se comporta igual todo dia.
2. Do que os agentes morrem de verdade
Em dados públicos, a melhor radiografia disponível é uma análise de 73 incidentes de agentes em produção, entre janeiro e maio de 2026, todos em sistemas rodando de verdade.
O ranking das causas é surpreendentemente banal. Um terço dos incidentes começou em uma chamada de ferramenta: a API mudou, o contrato quebrou e o agente seguiu em frente como se nada tivesse acontecido. Outro quarto veio de um contexto de má qualidade, ou seja, o agente decidiu de forma razoável com base em uma informação errada. E 19% foram de planejamento, a tarefa grande quebrada em subtarefas que não levavam ao resultado.
O dado mais valioso do estudo é o custo de investigação: incidentes sem rastro de decisão levaram, em média, 4,2 horas para resolver. Com instrumentação, menos de 1 hora.
As duas maiores causas têm o mesmo formato: a falha de entrada é boba, e o estrago vem do que o agente faz depois dela, porque ele não para quando algo quebra. Ele improvisa em torno da resposta quebrada e mantém o fluxo com o contexto corrompido. Nos dados, 61% das falhas de contexto geraram uma segunda falha em outra camada, e a causa original ficou escondida por trás dela.
É aqui que a demo mais engana. Ela mostra como o agente se comporta quando tudo funciona, e o que decide a vida dele em produção é como ele se comporta quando algo já veio quebrado.
Tem ainda uma causa de morte que nem aparece nessas estatísticas, porque ninguém registra como incidente do agente: o provedor caiu. A maioria dos pilotos roda inteira em cima de um único provedor, e diante da pergunta "o que acontece se a OpenAI ficar fora do ar agora?", a resposta costuma ser uma política de retry ou algo do gênero.
Retry não cobre o caso real. Os filtros de política desses modelos são voláteis: de uma hora para outra, um prompt legítimo pode ser sinalizado como malicioso, e isso costuma acontecer na madrugada anterior à apresentação importante. A resposta que se sustenta é fallback de modelo — com os prompts do caminho alternativo versionados e testados como os do principal. Não é trivial.
Nesse desenho, a disponibilidade do agente é a do fornecedor. A mitigação é uma linha de fallback no roteamento apontando para um segundo provedor, mas ela precisa existir antes da queda.
3. Os quatro traços do agente chato
Os agentes que ficam em produção convergem para o mesmo desenho, e ele é o oposto do da demo.
O primeiro traço é o escopo fechado. Uma tarefa com critério de sucesso que se verifica olhando. O agente de triagem tria e pronto. Cada habilidade a mais que impressiona na apresentação é um modo de falha a mais, à espera do pior momento.
O segundo é a recusa explícita. Quando o pedido está fora do domínio, o agente devolve, encaminha ou escala para um humano, em vez de tentar. A recusa é a proteção mais barata que existe e, curiosamente, é a primeira coisa que a empolgação corta do projeto, porque, em demo, ela parece uma limitação.
O terceiro é o rastro (trace) completo. Cada chamada de ferramenta logada, cada decisão reconstituível depois. É o que separa a investigação de 4,2 horas da de menos de 1 hora, e o que separa uma reunião de incidente com fatos de uma reunião de incidente com opiniões.
O quarto traço é ter prova de que funciona, detalhado na seção 4.
Onde o chato já venceu
Os casos públicos mais citados de agentes que operam em escala são todos hiperespecializados. A migração de milhões de linhas de ETL que saiu em dois meses, num case conhecido de banco digital, era um agente fazendo um único tipo de mudança, com formato conhecido, e um engenheiro aprovando cada uma. As 30 mil aplicações migradas de Java numa big tech rodaram num pipeline de transformação em que o teste era o critério de aceite. Nenhum dos dois promete resolver tudo. Os dois fazem uma coisa, milhares de vezes, com a verificação embutida no processo.
E o escopo fechado abre uma porta interessante: o modelo hiperespecializado. Tarefa estreita, com critério claro, é o terreno onde um modelo pequeno alcança o modelo de fronteira. Foi o que medimos na prática ao trocar um LLM proprietário por um modelo aberto de 9B destilado para a tarefa: a conta caiu 36 vezes. Um agente que promete fazer tudo nunca vai conseguir usar um modelo assim, porque "tudo" não se destila. O agente de uma tarefa só consegue, e aí o custo por execução despenca, junto com a imprevisibilidade. De bônus, um modelo que só sabe fazer uma coisa já nasce com a recusa embutida.
4. Eval é o CI do agente
Ninguém mergeia código sem passar pelo CI. Agora, considere: o que acontece entre uma mudança no prompt do agente e a produção?
Muitas vezes nada. O prompt que toma decisão em produção é editado; alguém passa o olho e vai. Troca de modelo na configuração segue o mesmo caminho. E as pesquisas com líderes de engenharia confirmam que isso não é detalhe: a falta de avaliação aparece como o principal bloqueio para agente chegar em produção, citada por 64%, à frente de governança e de confiabilidade do modelo.
A versão mínima que funciona é parecida com um teste de software, com uma diferença: como a saída do modelo varia, o critério de aprovação é uma taxa de acerto, e não igualdade exata.
Na prática, é montar uma suíte de casos reais, com entradas representativas do que o agente vê no dia a dia e com o resultado esperado especificado. Somar os casos adversariais, que são justamente as entradas quebradas em que os agentes morrem: a API que mudou, o contexto vazio, o pedido fora do escopo. Rodar essa suíte a cada mudança de prompt, ferramenta, modelo ou contexto. E fechar o ciclo com uma regra simples: incidente de produção vira caso novo da suíte, para o agente que caiu ontem nunca mais cair do mesmo jeito.
Sem isso, cada ajuste de prompt é um deploy sem teste. Com isso, o agente ganha o que o código ganhou há vinte anos: a liberdade de mudar sem medo.
5. As três perguntas
Dá para responder as três numa reunião, sem consultar ninguém.
A primeira: o que o agente recusa? Peça a lista do que ele não faz. Se a resposta for "ele é geral" ou um silêncio, o escopo não existe. E, sem escopo, não tem critério de sucesso, não tem caso de teste possível e não tem limite de estrago. A lista de recusa é o documento de design mais importante de um agente.
A segunda: dá para reconstruir por que ele fez o que fez ontem? Escolha uma execução de ontem e tente remontar a cadeia: que contexto entrou, que ferramentas foram chamadas, o que cada uma devolveu, o que ele decidiu com isso. Se, em algum momento, a resposta for "seria preciso adicionar log", a operação está do lado das 4,2 horas. Instrumentação só serve se for feita antes do incidente.
A terceira: o que roda entre uma mudança e a produção? Se a resposta for "testamos na mão com dois ou três exemplos", é o equivalente a testar código clicando na tela. Funciona até o dia em que deixa de funcionar. A suíte não precisa nascer grande. Ela só precisa nascer antes do próximo deploy.
Vale dizer que o contrário também existe: protótipo interno, risco baixo, sem acesso a nada irreversível, não precisa de tanta preparação. Esse rigor se paga quando o agente toca em cliente, em dinheiro ou em dados de produção. Antes disso, ele só atrapalha o aprendizado.
6. O charme está no lugar errado
A demo otimiza para surpresa. A produção premia o comportamento de amanhã ser igual ao de hoje, principalmente quando a entrada chega quebrada.
Por isso, a pergunta certa para avaliar um agente não é o que ele consegue fazer. É o que ele garante que não faz, e como se sabe disso. O agente que responde bem é chato de demonstrar e barato de operar. O outro rende uma ótima demo e uma péssima madrugada.
Como ajudamos times a adotar IA
Trabalhamos com times de engenharia que buscam incorporar IA ao dia a dia de desenvolvimento, não como experimento, mas como parte real do fluxo de trabalho.
Isso passa por escolher as ferramentas certas para o contexto do time, configurá-las de forma que façam sentido para a política de dados da empresa e garantir que os desenvolvedores saibam usá-las de um jeito que realmente aumente a produtividade, em vez de gerar mais fricção.
Se você tem um time de desenvolvimento e está tentando colocar IA para trabalhar de forma séria, fale com a gente.