O agente que decide demais é tão perigoso quanto o que decide de menos

O primeiro agente que coloquei em produção tinha um problema que eu não conseguia nomear direito.

Ele funcionava. Tomava decisões corretas na maioria das vezes. Mas de vez em quando fazia algo que nenhum humano teria feito sem perguntar antes. Não porque o modelo estava errado. Porque eu nunca defini até onde ele podia ir.

Levei algumas semanas para entender que o problema não era o LLM. Era o design dos limites de autonomia.

O que a maioria chama de "alucinação" não é alucinação

Quando um agente toma uma decisão errada em produção, o diagnóstico mais comum é: "o modelo alucionou". Isso acontece. Mas é a causa menos frequente.

O que acontece mais é o seguinte: o agente foi colocado numa situação ambígua, sem contexto suficiente para distinguir entre dois caminhos possíveis, e escolheu um. O modelo fez exatamente o que foi projetado para fazer. O problema é que você não deveria ter deixado ele chegar nessa encruzilhada sozinho.

Num sistema que construí para automação de conteúdo, o agente tinha acesso a uma tool de publicação. A instrução era "publique quando o conteúdo estiver aprovado". O que eu não defini foi o que "aprovado" significava quando o estado intermediário era ambíguo. O agente interpretou, escolheu, publicou. Estava tecnicamente dentro das regras que eu tinha dado. E foi exatamente errado.

Não foi alucinação. Foi boundary design ausente.

O problema dos dois extremos

Existe uma tensão real no design de agentes que a maioria dos artigos ignora.

De um lado, o agente que decide demais. Ele tem autonomia ampla, interpreta instruções com liberdade, age sem pedir confirmação. Em ambiente de teste, parece impressionante. Em produção, eventualmente faz algo que você não autorizou, num momento que você não esperava, com consequências que você não consegue reverter facilmente.

Do outro lado, o agente que decide de menos. Ele pede confirmação para tudo. Interrompe fluxos que deveriam ser automáticos. Transforma automação em semi-automação sem deixar isso claro. O usuário aprende a clicar "sim" sem ler, que é pior do que deixar o agente decidir sozinho.

A maioria dos times oscila entre os dois sem perceber. Começa restritivo por medo. Afrouxa quando o produto pressiona por autonomia. Não tem um modelo mental claro para onde o limite deveria estar.

Boundary design não é sobre confiança no modelo

Aqui está a parte contraintuitiva: o limite de autonomia de um agente não deveria ser calibrado pela sua confiança no modelo.

Deveria ser calibrado pelo custo de reversão da ação.

Uma ação de leitura tem custo de reversão zero. Uma ação que escreve em banco tem custo baixo se houver soft delete. Uma ação que envia e-mail para mil usuários tem custo altíssimo, talvez irreversível. Uma ação que publica conteúdo público tem custo médio a alto dependendo do contexto.

Quando você pensa em termos de reversibilidade, o design fica mais claro. O agente pode ter autonomia total para ações com custo de reversão baixo. Para ações com custo alto, você precisa de um checkpoint humano ou de uma camada de confirmação explícita no próprio fluxo do agente.

Isso não é sobre não confiar no LLM. É sobre reconhecer que nenhum sistema, humano ou automatizado, deveria ter autonomia irrestrita sobre ações irreversíveis.

O que eu chamo de Armadilha do Agente Confiante

Existe um padrão que eu vi se repetir em sistemas diferentes.

O agente funciona bem em 95% dos casos. O time ganha confiança. A autonomia vai aumentando incrementalmente, cada ajuste pequeno demais para justificar revisão de arquitetura. Seis meses depois, o agente está tomando decisões que ninguém teria aprovado explicitamente se fossem apresentadas de uma vez.

Eu chamo isso de Armadilha do Agente Confiante. A autonomia não foi concedida. Foi acumulada por inércia.

O sintoma é quando alguém do time pergunta "o agente pode fazer X?" e ninguém sabe responder com certeza sem ir ler o código ou os prompts.

O que funciona na prática

A abordagem que faz mais sentido para mim depois de errar algumas vezes é separar claramente três zonas:

Zona de execução autônoma. Ações que o agente pode tomar sem nenhuma confirmação. Leitura, busca, análise, formatação, rascunho. Qualquer coisa que não altera estado externo de forma irreversível.

Zona de execução com log. Ações que o agente executa, mas que geram um registro explícito auditável em tempo real. Não para aprovação, mas para visibilidade. Você não quer parar o fluxo, mas quer saber o que aconteceu.

Zona de aprovação obrigatória. Ações que precisam de confirmação humana antes de executar. Não porque o agente é incompetente, mas porque o custo de reversão justifica o checkpoint.

A parte difícil é classificar cada tool que você dá ao agente nessas três zonas antes de ir para produção, não depois do primeiro incidente.

Contexto é o que determina o limite, não o prompt

Um erro que cometi algumas vezes foi tentar resolver boundary design no prompt. "Não faça X sem confirmar." "Só publique se Y estiver verdadeiro."

Isso funciona até o modelo encontrar uma situação que o prompt não antecipou. E ele sempre encontra.

O que funciona melhor é construir o limite na arquitetura. A tool de publicação simplesmente não existe na lista de tools disponíveis para o agente quando o contexto não satisfaz as pré-condições. Não é o modelo decidindo se deve ou não publicar. É o sistema que nunca oferece essa opção.

Contexto aqui não é só o que você manda no prompt. É o conjunto de ferramentas disponíveis, as permissões ativas, o estado da sessão. O agente decide dentro do espaço que você construiu. Se o espaço está mal definido, o modelo vai explorar as bordas, e as bordas são onde os problemas aparecem.

O que eu faria diferente hoje

Mapearia as tools por reversibilidade antes de começar a implementar o agente. Não como documentação posterior, mas como constraint de design.

Implementaria um modo de dry-run para qualquer ação na zona de aprovação, onde o agente descreve o que vai fazer antes de fazer. Não como confirmação humana obrigatória, mas como mecanismo de observabilidade e de teste de boundary.

E evitaria aumentar autonomia por pressão de produto sem revisar o mapa de reversibilidade junto. Autonomia que cresce sem revisão de boundary é risco acumulado silencioso.

A reflexão que fica

Existe uma crença comum de que o trabalho de engenharia em sistemas de agentes é principalmente sobre o modelo: escolher o certo, ajustar o prompt, melhorar o contexto. Isso importa. Mas não é onde a maioria dos problemas de produção aparece.

O trabalho real é de design de sistema. Onde o agente começa e onde ele para. O que ele pode tocar e o que está fora do alcance dele. Não porque você não confia no modelo, mas porque sistemas confiáveis têm limites claros independentemente de quem está executando.

Um agente sem boundary design claro não é um agente autônomo. É um risco com boa documentação.