🪤 Anti-padroes e Armadilhas

A armadilha multiagente e o anti-padrao mais perigoso porque parece intuitivamente correto: "se um agente e bom, cinco devem ser melhor". A realidade e que especializar demais sem governanca gera sistemas frageis, lentos e caros. De acordo com a Gartner (previsao 2025), mais de 40% dos projetos de IA agentica serao cancelados ou drasticamente reduzidos ate 2027. As causas principais nao sao tecnicas — sao de engenharia: over-engineering, custos descontrolados e incapacidade de demonstrar valor de negocio claro.

O padrao se repete: uma equipe entusiasmada cria um swarm com 8-12 agentes para resolver um problema que 2-3 resolveriam. Cada agente adicional aumenta latencia (comunicacao inter-agente), custo (mais chamadas de LLM) e complexidade de debugging (mais pontos de falha). O artigo "The Multi-Agent Trap" do Towards Data Science documenta esse fenomeno em detalhes: equipes que comecam simples e adicionam complexidade sob demanda tem taxa de sucesso 3x maior do que equipes que projetam swarms complexos desde o inicio. A regra de ouro: comece com o menor numero de agentes possivel e adicione mais apenas quando os dados mostrarem necessidade.

De todos os motivos pelos quais projetos de swarm sao cancelados, custo descontrolado e o mais comum e o mais evitavel. O problema e matematico: cada agente faz N chamadas de LLM por tarefa, cada chamada consome tokens de input e output, e swarms processam centenas ou milhares de tarefas por dia. Um agente que custa $0.05 por chamada, fazendo 10 chamadas por tarefa, em 5 agentes, processando 1000 tarefas/dia = $2.500/dia ou $75.000/mes. Sem monitoramento, essa conta so aparece na fatura mensal da API.

A solucao exige tres componentes: token budgets (limites rigidos por tarefa e por agente), alertas proativos (notificacao quando custos ultrapassam limiares) e fallback para modelos mais baratos (se o budget esta acabando, troque Opus por Haiku automaticamente). Um padrao especialmente perigoso e o "loop de refinamento sem limite" — quando o critico reprova o trabalho e manda refazer, e o refazer e reprovado novamente, ad infinitum. Sempre defina um maximo de iteracoes (geralmente 2-3) e aceite o melhor resultado disponivel.

Este anti-padrao foi documentado em um caso real alarmante: o projeto opencode-swarm foi analisado e descobriu-se que continha 268 assertions que testavam texto fixo de prompts em vez de comportamento real. Os testes verificavam coisas como "o system prompt contem a palavra 'analista'" ou "o prompt tem mais de 100 caracteres" — testes que passam sempre, nao detectam nenhum bug e criam uma falsa sensacao de seguranca. Este fenomeno, chamado de "testing theater", e especialmente prevalente em projetos com codigo gerado por IA, onde o modelo gera testes que "parecem profissionais" mas nao validam nada relevante.

O problema e conceitual: testes para sistemas de IA precisam testar comportamento, nao estrutura. Em vez de verificar se o prompt contem certas palavras, voce deveria verificar se o agente produz o output correto para um conjunto de inputs conhecidos. Em vez de testar se o modelo retorna JSON valido, teste se o agente toma a decisao correta em cenarios de borda. A abordagem correta usa testes comportamentais (behavioral testing) com datasets de "golden examples" — inputs cujo output esperado voce conhece — e mutation testing para verificar se seus testes realmente detectam mudancas que quebram funcionalidade.

Quando agentes de IA geram codigo, eles frequentemente produzem funcoes gigantescas que fazem tudo em um unico bloco — as chamadas "God Functions". Uma funcao de 500 linhas que busca dados, processa, valida, formata e salva tudo no mesmo lugar. O codigo "funciona" no sentido estrito (produz o output correto), mas e impossivel de manter, testar e debugar. Quando algo quebra numa funcao de 500 linhas, voce precisa entender todo o contexto para achar o problema. Quando precisa mudar um comportamento, corre o risco de quebrar outros 10.

Este anti-padrao e especialmente insidioso em swarms porque o proprio sistema que deveria "escrever codigo bom" produz codigo que viola principios basicos de engenharia. A causa raiz e que LLMs otimizam para completar a tarefa no menor numero de interacoes, nao para produzir codigo manutenivel. A solucao e incluir no prompt do agente de codigo instrucoes explicitas sobre decomposicao: "cada funcao deve ter no maximo 30 linhas", "extraia funcoes auxiliares para logica reutilizavel", "siga o principio de responsabilidade unica". Melhor ainda: tenha um agente revisor dedicado que recusa PRs com funcoes acima de um limiar.

Este e o anti-padrao mais traicoeiro: o agente encontra um erro, mas em vez de falhar explicitamente, ele produz um resultado parcial que parece completo. O buscador nao consegue acessar 3 de 5 fontes, mas retorna os resultados das 2 que funcionaram sem avisar. O sintetizador perde 40% dos dados por estouro de contexto, mas gera um resumo com o que tinha. O escritor nao encontra citacao para uma afirmacao, mas a inclui mesmo assim sem marcacao. O resultado e um output que parece profissional e completo, mas esta fundamentalmente incompleto ou incorreto.

Falhas silenciosas sao piores que falhas explicitas porque nao disparam nenhum alerta. Um erro que retorna HTTP 500 e detectado imediatamente pelo monitoring. Um agente que retorna 60% dos dados esperados sem sinalizar que os outros 40% faltam passa despercebido por dias ou semanas. A solucao e implementar o padrao fail-fast com estados de erro explicitos: cada agente retorna nao apenas o resultado, mas tambem um campo de status com {status: "complete|partial|failed", missing: [...], errors: [...], confidence: 0.0-1.0}. O orquestrador usa esses metadados para decidir se o resultado e aceitavel ou se precisa reprocessar.

A maioria dos swarms em producao hoje opera sem governanca cognitiva — o conjunto de controles que garantem reproducibilidade, auditabilidade e comportamento deterministico. Quando seu CEO pergunta "por que o sistema tomou essa decisao?", voce precisa ser capaz de reconstruir exatamente o que cada agente recebeu, processou e decidiu. Quando um regulador exige evidencia de compliance, voce precisa de audit trails completos. Quando um bug aparece, voce precisa reproduzir exatamente as condicoes que o causaram. Sem governanca cognitiva, seu swarm e uma caixa preta que "funciona as vezes".

Enterprise nao aceita "funciona as vezes". Os controles necessarios incluem: reproducibilidade (fixar seeds, temperatures e versoes de modelo para que a mesma entrada produza saida previsivel), auditoria completa (cada decisao de cada agente logada com input, output, timestamp e justificativa), determinismo configuravel (modo "strict" para producao com temperature 0 e sem sampling aleatorio) e compliance automatizado (verificacao automatica de que outputs nao violam politicas da empresa, regulamentacoes setoriais ou leis de protecao de dados).