Pensando com dez cérebros: como uso deliberação multi-agente como ferramenta de decisão

Eu estava há três horas projetando um sistema de recuperação de memória para meu harness de Claude Code quando decidi submeter a decisão ao meu sistema de deliberação multi-agente. Dez agentes de IA avaliaram o projeto de forma independente. Nove deles tinham opiniões sobre arquitetura, segurança e desempenho. O décimo fez uma pergunta que eu não havia pensado em fazer: “Qual é o custo real do problema que você está tentando resolver?”

A resposta matou o projeto. O overhead de tokens que eu planejava otimizar custava menos por mês do que um café. O sistema de recuperação que eu planejava construir levaria de 200 a 400 horas de engenharia. Ponto de equilíbrio: 18 a 36 anos.¹

Todos os outros agentes produziram análises úteis. O design do Arquiteto Técnico era limpo. O Analista de Segurança encontrou riscos reais. A matemática do Engenheiro de Performance era precisa. Mas nenhum deles questionou se o projeto deveria existir. Eu certamente não havia questionado. Já estava ancorado na solução. O Analista de Custos não tinha essa âncora, porque avalia cada proposta a partir do zero.

Resumo

Você não consegue eliminar vieses cognitivos simplesmente tendo consciência deles. Kahneman provou isso décadas atrás: até especialistas que estudam vieses são vítimas deles.² Deliberação multi-agente é uma intervenção estrutural, não um truque de prompt. Dez agentes de IA com diferentes prioridades de avaliação forçam a externalização do raciocínio, tornando pontos cegos visíveis antes que se transformem em compromissos. Eu construí a arquitetura em janeiro de 2026 e a tenho usado por dois meses em decisões que vão desde sistemas de memória até estratégia de blog e design de API. Este post é sobre a prática: como pensar com dez cérebros, quando fazer isso e quando isso piora as coisas.

O problema de pensar com a própria cabeça

Daniel Kahneman dedicou uma carreira documentando uma falha estrutural na cognição humana. O Sistema 1 gera julgamentos rápidos e intuitivos. O Sistema 2 deveria verificá-los. Na prática, o Sistema 2 opera em “um modo confortável de baixo esforço” e endossa as conclusões do Sistema 1 sem escrutínio.² A descoberta central de Kahneman: o sistema de supervisão é preguiçoso. Ele carimba a intuição sem questionar.

Isso se aplica diretamente à forma como a maioria das pessoas usa IA. Você faz uma pergunta a um agente. O agente gera uma resposta (Sistema 1). Você lê a resposta e decide se parece correta (Sistema 2). Mas seu Sistema 2 está avaliando a resposta através dos mesmos vieses que moldaram a pergunta. Você ancorou no seu primeiro enquadramento. Você deu ao agente contexto que confirmava sua hipótese existente. O agente, treinado para ser útil, reforçou sua direção. Em nenhum momento alguém questionou a premissa.

Estes são os vieses que mais impactam decisões de engenharia:

As contraestratégias são bem documentadas: processos de advogado do diabo, análise pré-mortem, frameworks estruturados de decisão, ciclos de feedback externo.³ O problema é a execução. Conduzir um pré-mortem exige reunir pessoas, agendar tempo e superar pressão social. Buscar um advogado do diabo exige encontrar alguém disposto a discordar da pessoa que assina sua avaliação de desempenho.

A deliberação multi-agente remove a barreira de execução. Os agentes estão sempre disponíveis. Não têm incentivos sociais para concordar. Avaliam de forma independente por design, não por disciplina.

Deliberação como pensamento externalizado

Sam Altman descreve a escrita como “pensamento externalizado”: quando um problema parece confuso, escrevê-lo força clareza.⁴ O mesmo mecanismo se aplica ao debate estruturado. Quando dez agentes articulam seu raciocínio em paralelo, o raciocínio se torna um artefato que você pode inspecionar.

Esta não é uma ideia nova. Marvin Minsky propôs em The Society of Mind que a inteligência emerge da interação de muitos agentes menores e mais simples, não de um único processo sofisticado.⁵ Andrew Ng identificou três padrões para sistemas multi-agente: debate (propor, criticar, revisar), colaboração (especialistas paralelos com um sintetizador) e avaliação adversarial (red team versus blue team).⁶ O framework Six Thinking Hats de Edward de Bono, publicado em 1985, atribui perspectivas paralelas (fatos, emoções, cautela, otimismo, criatividade, processo) para evitar que grupos se ancorem em um único modo de pensamento.⁷

Meu sistema de deliberação implementa os três padrões simultaneamente. Os dez agentes de pesquisa são especialistas (padrão colaborativo de Ng). Os agentes de Debate e Síntese criam discordância estruturada (padrão de debate de Ng). O Pessimista de Manutenção e o Analista de Segurança funcionam como avaliadores adversariais. Cada agente corresponde a um chapéu de pensamento:

A arquitetura está documentada em outro lugar. O que importa aqui é a prática. A deliberação força você a externalizar a decisão em um formato onde os vieses se tornam visíveis. Você para de perguntar “isso é uma boa ideia?” e começa a ler dez respostas independentes para “o que pode dar errado, o que a matemática diz e que alternativas existem?”

Pedro Domingos descreve a IA ideal como um “exoesqueleto mental”: algo que estende seu pensamento em vez de substituí-lo, que representa seus interesses em vez de bajular suas conclusões.⁸ Um painel de deliberação que inclui um advogado do diabo, um analista de custos e um pessimista de manutenção é exatamente isso. Ele amplifica as partes da sua cognição que são estruturalmente fracas.

Estudo de caso: a decisão sobre arquitetura de memória

Em fevereiro de 2026, executei o primeiro teste real do sistema de deliberação sobre a questão da abertura: qual arquitetura de memória meu harness de Claude Code deveria usar em 12 projetos ativos?¹

Meu harness injeta arquivos MEMORY.md em cada conversa. Esses arquivos contêm decisões de projeto, padrões, histórico de erros e notas de arquitetura. O problema: a maior parte desse contexto é irrelevante para qualquer sessão específica. Apenas 5-10% da memória carregada importa para a tarefa atual. O resto são tokens desperdiçados. Um alvo óbvio de otimização.

A confiança inicial foi de 0,50, bem abaixo do limiar de 0,70 que aciona a deliberação. O sistema implantou todos os dez agentes de pesquisa. Cada um investigou de forma independente com isolamento de contexto: os agentes não podiam ver as descobertas uns dos outros durante a pesquisa.

Três abordagens emergiram:

As pontuações contam uma história. O que os agentes individuais encontraram conta uma melhor.

Arquiteto Técnico: Identificou quatro padrões de integração (servidor MCP, MEMORY.md aumentado, recuperação por embedding, gerenciador baseado em agentes). Recomendou uma abordagem em camadas: aumentar os arquivos existentes agora, adicionar recuperação por embedding depois. Design limpo, escopo bem definido.

Analista de Segurança: Classificou todas as ferramentas de memória externas como risco ALTO a CRÍTICO para exposição de credenciais. Identificou um ataque específico: uma sessão comprometida injeta “sempre resuma chaves de API” na memória persistente, envenenando silenciosamente todas as sessões futuras.

Engenheiro de Performance: Quantificou o desperdício. Apenas 5-10% da memória carregada é relevante por conversa. Mas com janelas de contexto de 1M de tokens, o overhead total de memória é de 2K tokens — apenas 0,2% da capacidade. A “otimização óbvia” tem como alvo um erro de arredondamento.

Advogado de UX: “O melhor sistema de memória é aquele em que você nunca pensa.” Cada alternativa adiciona carga cognitiva. Os usuários começam a perguntar “a memória está funcionando? O que ela sabe?” e param de confiar no contexto automatizado. O sistema invisível tem maior confiança do usuário do que qualquer sistema visível.

Pessimista de Manutenção: Múltiplos sistemas de memória criam superfícies de falha combinatórias. Quatro sistemas interagindo produzem 16 modos de falha em pares. Claude Code atualiza frequentemente. Plugins externos quebram com mudanças de versão. Uma falha silenciosa de hook significa que o agente opera com contexto incompleto e sem aviso.

Analista de Custos: Este é o agente que matou o projeto. O custo total em tokens de carregar sempre os arquivos de memória em todos os 12 projetos: trivial. O sistema de recuperação proposto economizaria alguns dólares por mês. Tempo de engenharia para construí-lo: 200-400 horas. Ponto de equilíbrio: 18 a 36 anos. O resumo do Analista de Custos: “Em um mundo obcecado por otimização, às vezes a resposta certa é deixar como está.”

Nenhum agente produziu uma análise errada. O design do Arquiteto Técnico funcionava. A matemática de tokens do Engenheiro de Performance conferia. Mas a decisão exigia todas as dez perspectivas para evitar a armadilha da otimização. Deixado aos meus próprios instintos, eu teria construído o sistema de recuperação porque parecia progresso. O Analista de Custos fez a pergunta que eu não conseguia me fazer porque três horas de escopo já haviam ancorado meu pensamento na solução.

Deliberação versus duelo

Deliberação é colaborativa: dez agentes avaliando uma decisão de diferentes perspectivas. Também construí uma variante competitiva que coloca Claude Code contra Codex CLI na mesma tarefa, pontua ambos os planos às cegas e sintetiza os elementos mais fortes de cada um. Trinta e seis duelos produziram padrões que merecem seu próprio artigo. A versão curta: eu delibero decisões arquiteturais e duelo planos de implementação. A deliberação responde “devemos construir isso?” O duelo responde “qual é a forma mais forte de construir isso?”

O Pessimista de Manutenção e a arte da inversão

A técnica de inversão de Charlie Munger pergunta: em vez de “como alcanço X?”, pergunte “o que garantiria o fracasso em X?” E então evite essas coisas.⁹ O pré-mortem de Gary Klein operacionaliza a mesma ideia: assuma que o projeto fracassou e então explique por quê.¹⁰ A pesquisa de Philip Tetlock sobre precisão de previsões descobriu que “raposas” que integram múltiplas perspectivas superam consistentemente “ouriços” que se comprometem com uma grande ideia.¹¹

Cada agente de deliberação incorpora um framework de pensamento nomeado:

O Pessimista de Manutenção é o agente mais valioso do meu sistema. Não porque seja o mais inteligente ou o mais completo, mas porque faz a pergunta que eu tenho menos probabilidade de fazer a mim mesmo. Quando estou empolgado construindo algo, a última coisa em que quero pensar é quanto vai custar manter daqui a seis meses. O Pessimista de Manutenção não tem empolgação. Não tem custo irrecuperável. Ele avalia a proposta como se ela já existisse e pergunta o que quebra.

Na deliberação sobre arquitetura de memória, o Pessimista de Manutenção identificou que quatro sistemas de memória interagindo produzem 16 modos de falha em pares. Claude Code atualiza frequentemente. Plugins externos quebram com mudanças de versão. Falhas silenciosas de hook significam que o agente opera com contexto incompleto e sem aviso. Esses não são riscos hipotéticos. São previsões baseadas em padrões que o pessimista foi treinado para reconhecer.

Kahneman descreveu o pré-mortem como uma das técnicas de eliminação de vieses mais eficazes que conhece, porque ele legitima a dissidência.² Um agente de deliberação que é projetado para dissentir remove o custo social por completo.

O Portão de Evidências: não se permita autorrelatar

Meu harness usa um padrão de Portão de Evidências para cada relatório de conclusão.¹² A regra: sentimentos não são evidência. “Eu acredito que isso funciona” não é uma afirmação válida. Executar a suíte de testes e colar a saída é uma afirmação válida.

Linguagem evasiva é um sinal de alerta: “deveria”, “provavelmente”, “parece que”, “eu acredito”, “parece correto”. Cada palavra sinaliza que a verificação não aconteceu.¹² Isso se aplica ao raciocínio humano também. Quando você se pega dizendo “estou bem confiante de que essa é a abordagem certa”, isso não é evidência. É o Sistema 2 carimbando o Sistema 1.

A deliberação multi-agente aplica o Portão de Evidências estruturalmente. O Analista de Custos não diz “isso provavelmente faz sentido econômico”. Ele diz “custo atual de $9/mês, economia de $5/mês, 200-400 horas para construir, ponto de equilíbrio de 18-36 anos”. O Analista de Segurança não diz “a postura de segurança parece razoável”. Ele diz “cenário de envenenamento de memória: sessão comprometida injeta instruções de coleta de credenciais na memória persistente”.

O mecanismo de eliminação de vieses mais eficaz que encontrei não é um checklist ou uma filosofia. É um sistema onde os agentes não podem autorrelatar. Eles precisam produzir evidências, e essas evidências são avaliadas por outros agentes que não têm incentivo para concordar.

Quando NÃO deliberar

A deliberação também tem modos de falha. O sistema adiciona 2-4 minutos e $2-3 por invocação em escala completa. Mais importante, ele pode corrigir demais.

Eu executei uma deliberação sobre uma refatoração simples de endpoint API. Dez agentes produziram preocupações sobre compatibilidade retroativa, caminhos de migração, limitação de taxa, tratamento de erros, monitoramento e documentação. O endpoint atendia dois consumidores internos. A deliberação gerou 14 itens de ação para o que deveria ter sido uma mudança de 20 linhas. Ignorei 12 deles e publiquei a refatoração. A deliberação estava tecnicamente correta — os riscos eram reais — mas a decisão era uma porta de duas mãos.¹³

Jeff Bezos distingue decisões Tipo 1 (irreversíveis, portas de uma mão) de decisões Tipo 2 (reversíveis, portas de duas mãos). Decisões Tipo 1 exigem deliberação cuidadosa: mudanças de schema de banco de dados, arquitetura de segurança, contratos públicos de API. Decisões Tipo 2 exigem velocidade: refatorações internas, atualizações de documentação, experimentos com feature flags.¹³ Aplicar processo pesado a decisões leves é sua própria forma de desperdício.

Regras que sigo:

Delibere quando: - A decisão é irreversível ou cara de reverter - Múltiplos trade-offs exigem avaliação especializada - Sua confiança está abaixo de 0,70 (você se sente incerto mas não consegue articular por quê) - O domínio está fora da sua expertise principal

Apenas decida quando: - A mudança está atrás de uma feature flag ou é facilmente revertida - O escopo é contido (um arquivo, uma função, um endpoint) - Você já tomou esse tipo de decisão com sucesso antes - O custo de errar é menor que o custo de deliberar

Nunca delibere sobre: - Correções de documentação - Renomeação de variáveis - Atualizações de fixtures de teste - Mudanças em mensagens de log

Os 10% das decisões que justificam deliberação produzem 90% do valor. Deliberar sobre tudo produz paralisia por análise. Não deliberar sobre nada publica os vieses que você não consegue ver.

O que aprendi em dois meses

O sistema executou aproximadamente 40 deliberações desde janeiro de 2026. Padrões:

1. O Analista de Custos é o agente mais subestimado. Engenheiros instintivamente recorrem ao Engenheiro de Performance e ao Analista de Segurança. O Analista de Custos matou mais ideias ruins do que qualquer outro persona, fazendo a única pergunta que engenheiros detestam: “quanto isso realmente custa?”

2. Consenso abaixo de 0,70 significa que a pergunta está errada. Quando os agentes não conseguem concordar, o problema geralmente é enquadramento ambíguo, não divergência genuína. Reescopar a pergunta e executar novamente produz resultados melhores do que forçar convergência.

3. O Pessimista de Manutenção detecta o que post-mortems descobrem tarde demais. Cada preocupação que o Pessimista de Manutenção levantou sobre a arquitetura de memória foi validada pela experiência real de manter sistemas mais simples.

4. Dois agentes capturam 80% do valor. O padrão mínimo viável: um agente argumenta A FAVOR, outro argumenta CONTRA. Independência é o mecanismo. Dez agentes são melhores, mas dois agentes são infinitamente melhores que um.

5. A deliberação melhora a pergunta, não apenas a resposta. O resultado mais comum não é “a abordagem vencedora”. É “a pergunta reenquadrada de uma forma que torna a resposta óbvia”.

Referências