A regra 'primeiro verifique, depois recuse': como tirar do agente de IA o hábito de desistir no primeiro erro

• Tamanho da regra de autonomia do sistema: 5 KB de texto, carregados no início de cada sessão
• Opções obrigatórias a esgotar antes de recusar: 6 frentes (arquivos, navegador, contas, API interna, rotas alternativas, script próprio)
• Limite de persistência por obstáculo: 3–4 tentativas relevantes com ferramentas diferentes
• Perímetro de proteção contra danos: 42 regras de vigilância de comandos, 25 proibições absolutas e um hook de arquivos

Por quase um ano, a mesma cena cômica se repetiu no meu trabalho com agentes de IA. Eu dava uma tarefa — por exemplo, renomear em massa uma lista de registros em algum serviço. O modelo respondia educadamente: 'Infelizmente, isso não pode ser feito pela interface; acesse as configurações e renomeie manualmente.' Eu digitava duas palavras: 'Tenta você mesmo.' O agente buscava no disco, encontrava um arquivo de configuração local, editava três linhas — e a tarefa estava resolvida.

Em algum momento percebi que eu tinha me tornado um treinador motivacional de uma rede neural: sentado na beira do ringue com uma toalha, tentando convencê-la a acreditar em si mesma.

Por que a frase 'isso é impossível' dita por um modelo de linguagem é

uma alucinação, e não um fato?

A raiz do problema está em como interpretamos as respostas das LLMs. Se um agente escreve 'todos os testes passaram com sucesso', nenhum engenheiro sensato acredita sem ver o log do test runner. Mas quando o mesmo agente escreve 'isso não pode ser feito, sem acesso', as pessoas tratam essa recusa como um fato médico comprovado.

Na verdade, o modelo nunca verificou o acesso. Ele simplesmente cruzou probabilidades estatísticas do conjunto de treinamento e apresentou um palpite na forma de afirmação categórica. Para eliminar esse hábito, escrevi um módulo de regras compacto de cinco kilobytes. Seu invariante principal diz o seguinte: antes de pronunciar qualquer frase de recusa ('não posso', 'não tenho essa ferramenta', 'faça manualmente'), o agente precisa apresentar um par concreto: qual ferramenta usou para verificar e qual código de erro ou saída obteve. Sem uma chamada de ferramenta de verdade, ele não tentou — apenas chutou.

Quais são os 6 caminhos alternativos que o agente deve checar antes de

recorrer a um humano?

Em vez de desistir prematuramente, o agente agora segue uma checklist rígida de seis níveis: 1. Arquivos e bancos de dados locais: quase tudo que um aplicativo desktop exibe está salvo em disco como JSON, SQLite ou cache, e pode ser lido e editado diretamente. 2.

Automação de navegador: cinco circuitos independentes (de um navegador instantâneo via CLI a perfis com cookies ativos e motores stealth) abrem qualquer painel administrativo ao qual eu teria acesso visualmente. 3. Contas já configuradas: as credenciais de e-mail, armazenamento em nuvem, calendários, mensageiros e servidores já estão guardadas em um cofre seguro; basta solicitá-las pela ponte de integração.

4. APIs web internas: a falta de documentação pública não é um beco sem saída; o agente abre a aba de rede do DevTools, examina os cabeçalhos da requisição de saída e a reproduz via script. 5.

Troca de rota em caso de bloqueio externo: se uma requisição direta bate num antibot ou timeout, usa-se um provedor alternativo ou espelho. 6. Criação de uma microferramenta própria: quando não existe uma utilidade pronta, o agente escreve em dois minutos um script Python descartável e resolve a tarefa.

Para que a busca não se transforme num loop infinito, existe um limitador: depois de 3 a 4 tentativas relevantes com métodos diferentes, o agente para e entrega um relatório técnico preciso de cada caminho verificado.

Como dar liberdade total de ação a um agente e garantir que ele não

vai quebrar o sistema?

Deixar um agente autônomo buscar caminhos alternativos por conta própria, sem confirmação constante no botão 'Sim', só é seguro quando existe um perímetro de segurança à prova de falhas ao redor dele.

Na minha configuração, essa proteção está dividida em três camadas: um vigilante de comandos de terminal com 42 regras checa cada chamada antes da execução, uma lista negra de 25 proibições absolutas bloqueia permanentemente a exclusão de diretórios raiz, a formatação de discos, o drop de tabelas de banco de dados e o `git push --force` forçado, e um hook de arquivos separado protege senhas e núcleos de configuração contra sobrescrita. Além disso, qualquer texto externo vindo de e-mails e chats é marcado como dado não confiável, para descartar prompt injection.

Você pode conseguir esse módulo de regras junto com os vigilantes de segurança no meu canal [@jemal_hamidun](https://t.me/jemal_hamidun). Toda essa arquitetura de autonomia segura já vem embutida de fábrica no [Nomad AI](https://nomadnet.ai). Você pode aprender a configurar esses ambientes para suas próprias tarefas na [Hamidun Academy](https://academy.hamidun.com) (com teste gratuito de 72 horas), e a base completa com mais de 370 habilidades e masterminds em tempo real esperam por você no [Vibe Club](https://hamidun.com/club).