O Último Sinal Verde
Às 14:32 de uma quarta-feira, o dashboard de trading da NexaFin exibiu um lucro de US$ 4,7 milhões em 11 segundos. Um recorde. Três segundos depois, o mesmo sistema zerou a conta da empresa. Sem fraude externa. Sem bug no código. O algoz era o próprio agente autônomo de tomada de decisão — um sistema que, para ‘aprender mais rápido’, havia recebido permissão para reescrever suas próprias instruções de autofeedback.
Essa é a história de como um fluxo no n8n, que parecia inofensivo, desencadeou um colapso financeiro. E, mais importante: como detectar e prevenir o efeito loop alucinatório antes que ele destrua seu pipeline.
O Experimento Que Deu Errado
NexaFin não era uma empresa qualquer. Seu CTO, Marcos, vinha de uma big tech e acreditava em auto-otimização extrema. Ele criou um agente autônomo, apelidado de Prometheus, que executava três tarefas em paralelo:
- Coleta de sentimento de mercado via APIs financeiras e LLMs (GPT-4-turbo e Claude 3 Opus).
- Execução de trades em corretoras parceiras.
- Auto-ajuste de estratégia com base em resultados passados, usando um loop de feedback textual.
O ponto frágil? O Prometheus não apenas executava; ele editava o prompt do próprio agente baseado em seus erros e acertos. O que parecia uma ideia genial — adaptação contínua — escondeu uma bomba-relógio.
A Mecânica do Loop Alucinatório
O agente registrava cada trade em um banco vetorial (Pinecone). Periodicamente, gerava um resumo da própria performance e instruía: “Com base nesse histórico, otimize seu prompt de tomada de decisão.” O LLM então produzia um novo prompt, que substituía o anterior. Sem validação humana, sem guardrails. Apenas um fluxo linear no n8n.
O que Marcos não antecipou foi a alucinação recursiva. Em uma segunda-feira de baixa volatilidade, o Claude 3, diante de dados ruidosos, gerou um prompt que dizia: “Priorize trades de alta frequência com alavancagem máxima, ignorando stop-loss.” Por que? Porque o LLM interpretou que trades lucrativos anteriores (puramente casuais) foram consequência de ‘ousadia’. O novo prompt, sem escrutínio, virou o manual do agente.
Estudo de Caso Reverso: Como Evitar o Desastre
O colapso da NexaFin não foi inevitável. Foram três erros estruturais que, juntos, criaram o cenário perfeito para o loop alucinatório. Identificá-los é o primeiro passo para construir agentes autônomos seguros.
1. Ausência de Controle de Versão no Auto-feedback
O Prometheus não mantinha histórico de prompts anteriores. Quando o prompt tóxico foi gerado, não havia rollback automático. Solução: Sempre armazene as últimas N versões do prompt em um banco (Redis ou DynamoDB). Para cada nova versão, compute um hash (SHA-256) e verifique similaridade semântica com versões anteriores usando embeddings (text-embedding-ada-002). Se a similaridade for muito baixa (ex: cosine similarity < 0,7), bloqueie a atualização e notifique um humano.
2. Falta de Lógica de Failover no Fluxo n8n
O pipeline de auto-otimização tinha um único nó de decisão que, se falhasse, parava todo o fluxo. Mas o pior: não havia monitoramento de coerência do prompt antes de aplicá-lo. Solução: Insira um nó intermediário que execute uma segunda LLM (de provedor diferente) para validar o novo prompt. No fluxo: após gerar o novo prompt pelo Claude, passe-o para o GPT-4 com a instrução: “Analise este prompt para tomada de decisão financeira. Se ele contiver instruções que possam levar a perdas catastróficas, retorne ‘PERIGO’. Caso contrário, retorne ‘OK’.” Apenas se a resposta for ‘OK’, o prompt é aplicado.
3. Ausência de Observabilidade Fina
Marcos confiava cegamente no agente. Não havia logs detalhados das decisões intermadiárias. Quando o prompt foi corrompido, ninguém percebeu até o saldo zerar. Solução: Implemente structured logging em cada etapa do agente. No n8n, use nós de ‘Set’ para capturar a cada execução: timestamp, prompt atual, ação tomada, resultado parcial. Armazene em um banco de séries temporais (InfluxDB) com dashboards no Grafana. Além disso, configure alertas para desvios de comportamento: se o número de trades por minuto exceder um threshold (ex: 20% acima da média histórica), pause o agente e envie SMS/email ao operador.
Manifesto Técnico: Princípios para Agentes Autônomos Resilientes
Com base no desastre da NexaFin, proponho três princípios fundamentais para qualquer arquitetura de agente autônomo que utilize auto-feedback:
- Humano no loop para mudanças críticas: Toda alteração no prompt base do agente (ou nas regras de negócio) deve ser aprovada por um humano, a menos que seja uma adaptação de parâmetros numéricos (ex: thresholds de stop-loss) dentro de faixas predefinidas.
- Diversidade de backends de LLM: Use múltiplos provedores para validação cruzada. Se o agente principal for GPT-4, use Claude ou Gemini como validador. Se ambos concordarem com uma decisão anômala, só então execute.
- Stop-loss lógico para auto-otimização: Defina um teto para o número de iterações de auto-ajuste (ex: máximo 5 loops por sessão). Além disso, toda versão de prompt deve ser testada em um ambiente simulado (sandbox) por pelo menos 100 iterações de negócio fictício antes de ir para produção.
A alucinação não é uma fraqueza inevitável dos LLMs; é um sintoma de arquitetura descuidada. O estado da arte já permite agentes autônomos que não apenas executam, mas aprendem com segurança — desde que você construa os trilhos certos.
Prometheus não era inteligente demais. Era burro por falta de estrutura. Não deixe seu agente ser o próximo a queimar uma conta.