IA agentic confiável: os padrões que uso em produção (não o hype)

Rodo dois sistemas com IA no núcleo em produção: o Tamperlens, que analisa documentos, e um agente interno que coordena a operação de um negócio pequeno por WhatsApp — hoje o meu, com um piloto de cliente provisionado. Nenhum dos dois é impressionante de olhar. Não têm um chat mágico que faz tudo. O que eles têm é um punhado de decisões de engenharia que os deixam confiáveis — e confiável, num sistema com IA, quer dizer uma coisa específica: o pior caso é seguro, não que o caso médio é bonito.

Este post é sobre esses padrões. Nenhum deles é sobre “prompt mágico”. Todos são sobre o que acontece quando o modelo erra, quando o processo morre no meio, quando a resposta demora, quando o silêncio poderia ser confundido com um “sim”. Porque num demo o modelo acerta; em produção ele erra, e o sistema tem que continuar seguro quando ele erra.

Padrão 1: o número publicado deriva de um teste, não de uma opinião

Começo pelo mais barato de descrever e o mais caro de manter. Nenhum número que eu publico sobre o comportamento de um sistema pode ser digitado à mão. Ele tem que ser produzido por um teste que roda, e o teste tem que quebrar quando o número deixa de ser verdade.

No Tamperlens isso é literal. A matriz que descreve quais técnicas de evasão derrotam quais sinais não é uma tabela que escrevi olhando o código — cada célula veio de rodar um arquivo por uma ferramenta real (qpdf, Ghostscript, exiftool) e reinspecionar o resultado, com o relógio fixado num instante conhecido para o teste ser determinístico. O resultado bruto é gravado num JSON versionado, e existe um teste que compara esse JSON contra o engine e contra o post publicado. Quando a versão do engine passa da versão gravada no arquivo, a suíte falha e nomeia o comando que precisa rodar de novo.

Por que isso importa? Porque a alternativa — um número que já foi verdade, escrito num post que ninguém revalida — é como a documentação apodrece. E num sistema de IA a tentação é dobrada, porque o modelo é fluente: ele produz um número confiante sem esforço, e a fluência é indistinguível de correção até alguém checar. Quando fiz essa reinspeção, aliás, seis das células que eu tinha deduzido do código estavam erradas. A dedução era plausível. A medição era outra coisa. É por isso que a régua é: o número publicado deriva do teste, e o teste é a fonte da verdade — não a minha leitura do código, não a resposta do modelo, o teste.

Padrão 2: subagentes que verificam adversarialmente

A arquitetura do agente do dono não é um cérebro só. É um coordenador que roteia para subagentes por área — marketing, suporte, finanças, ops, jurídico — cada um definido por arquivo (um manifesto, pastas de conhecimento, skills), não por código. Implantar em outra empresa é preencher pastas e apontar uma inbox, não editar Python. Isso roda sobre deepagents em cima do LangGraph, que dá planejamento, subagentes e um sistema de arquivos de trabalho prontos.

Mas a parte que torna isso confiável não é a divisão de trabalho — é usar um subagente para atacar o que outro produziu, antes de um humano ver. Antes de uma reunião com um cliente-piloto, rodei um subagente cuja única função era ser adversarial: criticar o produto como um cético faria, procurar o que quebra. Ele achou coisas que o fluxo otimista nunca acharia — incluindo que uma migração de banco planejada perderia registros em silêncio, sem erro, sem log, só sumindo.

Esse é o ponto geral: um agente perguntado “isto está bom?” tende a concordar consigo mesmo — é fluente e cooperativo por construção. Um agente cuja tarefa é “encontre o que está errado aqui” opera com o incentivo invertido, e o incentivo invertido é o que expõe a falha. É a mesma lógica do code review adversarial entre humanos, aplicada dentro do loop de IA: você não confia na primeira saída; você confia na saída que sobreviveu a um segundo agente tentando derrubá-la.

Padrão 3: aprovação humana no loop, e o firewall de capacidades

A regra mais importante do sistema é a mais simples de enunciar: toda ação que sai da empresa é uma ferramenta explícita, e toda ferramenta que envia, publica ou dispara algo interrompe e espera um humano. Ler é livre; agir sobre o mundo não é. O agente pode buscar e-mail, ler saldo bancário, rascunhar uma resposta, montar uma nota fiscal — sem pedir licença. Enviar o e-mail, emitir a nota, disparar a automação, marcar na agenda — cada uma dessas interrompe e vira uma pergunta ao dono no WhatsApp.

Isso se chama firewall de capacidades, e a escolha de projeto é deliberada: a fronteira não é “o quão confiante o modelo está”, é “esta ação é reversível?”. O acesso ao Stripe é somente leitura por desenho — não porque o agente é burro, mas porque não há razão para ele ter a capacidade de cobrar alguém, então ele não tem. A confiança no modelo nunca é a variável que decide se uma ação irreversível acontece. A capacidade simplesmente não existe do lado errado do firewall.

E a aprovação é uma conversa de verdade: a resposta do dono na conversa é a decisão. “Sim” aprova; “não” rejeita; qualquer outro texto rejeita com aquele texto como motivo. A própria conversa, com as notas do sistema de atendimento, é a trilha de auditoria — não há um painel de aprovação paralelo que alguém esquece de checar.

Padrão 4: o agente não pode se aprovar por silêncio

Este é o padrão que eu defenderia acima de todos, e é uma linha de código. Quando o sistema traduz a resposta do humano em decisão, o default é rejeitar. Resposta vazia? Rejeita, com o motivo “sem resposta do dono”. Timeout, mensagem perdida, ambiguidade que não casa nem com “sim” nem com “não”? Rejeita.

O silêncio nunca é consentimento. Um sistema que interpreta “não respondeu” como “pode ir” é um sistema que vai executar sua ação mais perigosa exatamente no momento em que o humano estava distraído, offline ou confuso demais para responder — o pior momento possível. Ao fazer o silêncio significar “não”, a falha se inclina para o lado seguro: o pior caso de uma aprovação perdida é uma ação que não aconteceu e precisa ser repetida, nunca uma ação irreversível que aconteceu sem ninguém decidir.

É o inverso exato de como a maioria dos sistemas empolgados é construída, onde a fricção é o inimigo e o caminho feliz é assumir o “sim”. Num sistema que mexe com dinheiro e comunicação de cliente, a fricção no lugar certo é a feature.

Padrão 5: at-least-once, porque o processo vai morrer no meio

O último padrão é o menos glamouroso e o que mais separa demo de produção. Os webhooks que acordam o agente chegam de um sistema que reentrega: se ele não recebe seu “200 OK” a tempo, ele manda de novo. Isso é uma garantia at-least-once, e ela força duas obrigações.

Primeiro, idempotência: cada mensagem carrega um id, e o sistema registra os ids já processados. A mesma mensagem chegando duas vezes é processada uma vez. Sem isso, uma reentrega vira uma nota fiscal emitida em duplicata ou um e-mail enviado duas vezes — e o pior caso de concorrência aqui é precisamente esse: uma ação irreversível repetida. (Por isso também há um lock por conversa: dois webhooks da mesma conversa — o “sim” e o áudio que vem logo atrás — não rodam em paralelo e embaralham a decisão pendente.)

Segundo, durabilidade contra o restart. O payload de cada webhook aceito é gravado antes de a tarefa em background ser agendada, com status “recebido”. Se o processo morre no meio — deploy, crash, o que for — ao subir de novo o serviço varre os eventos que ficaram em “recebido” (aceitos com 200, nunca concluídos) e os reprocessa, do mais antigo ao mais novo. Uma mensagem que foi aceita nunca é silenciosamente perdida porque o container reiniciou.

Repare que nada disso é IA. É engenharia de sistemas distribuídos de sempre — at-least-once, idempotência, durabilidade, locks — aplicada ao redor do modelo. E é exatamente aí que mora a confiabilidade. O modelo é o componente menos previsível do sistema; a confiabilidade vem de cercá-lo com componentes que são previsíveis, e de fazer o pior caso de cada um deles ser seguro.

O fio que costura tudo

Se há um princípio único por trás dos cinco padrões, é este: em cada ponto onde o sistema pode falhar, a falha se inclina para o lado seguro. O número não medido não é publicado. A saída não atacada não é confiada. A ação irreversível não acontece sem um humano. O silêncio não vira sim. A mensagem aceita não se perde no restart.

Nada disso é sobre o modelo ser mais esperto. É sobre projetar o sistema de forma que a esperteza do modelo seja opcional para a segurança dele. Essa é a diferença entre um agente que demonstra bem e um agente em que você deixa rodar sobre o dinheiro e os clientes de outra pessoa — e é a única parte da “IA agentic” que vale a pena levar a sério.

Se você quer um agente construído assim para o seu negócio — não um chatbot, um agente com firewall de capacidades, aprovação no loop e o pior caso projetado — é esse tipo de trabalho que eu faço.