Deliberação Multi-Agente: Quando o Consenso É o Bug

A saída mais perigosa que meu agente de IA produz não é um erro. Erros são fáceis. Linters detectam erros de sintaxe, suítes de testes detectam regressões, e os 95 hooks que eu construí detectam except: pass e force pushes. A saída perigosa é uma recomendação confiante, bem fundamentada, que por acaso está errada.

Pedi a um único agente para revisar um endpoint de API quanto a problemas de segurança. O agente verificou autenticação, validou sanitização de entrada e verificou cabeçalhos CORS. Atestado de saúde limpo. Um segundo agente, instruído separadamente como testador de penetração, descobriu que o endpoint aceitava parâmetros de consulta ilimitados que poderiam provocar uma negação de serviço por amplificação de consultas no banco de dados. O primeiro agente nunca verificou isso porque nada em seu framework de avaliação tratava a complexidade de consultas como uma superfície de segurança.

Essa lacuna é estrutural. Nenhuma quantidade de engenharia de prompts resolve isso, porque a limitação não está no prompt. A limitação está em ter uma única perspectiva avaliando um problema multidimensional.

Construí um sistema de deliberação multi-agente para fechar essa lacuna. Agentes com diferentes personas pesquisam de forma independente, debatem achados e chegam a um consenso por meio de votação estruturada. O sistema executa 141 testes, impõe isolamento de contexto entre agentes e usa uma arquitetura de validação com duas comportas que bloqueia concordância prematura.

TL;DR

Sistemas de IA com agente único têm um ponto cego estrutural: não conseguem desafiar suas próprias suposições. Um loop Ralph rodando Sonnet produz código a $10/hora, mas cada ponto cego do modelo é entregue na mesma velocidade. A deliberação multi-agente força avaliação independente de múltiplas perspectivas antes que qualquer decisão se consolide. Minha implementação usa 10 personas de pesquisa, uma máquina de estados de 7 fases e duas comportas de validação (consenso + pride check) rodando em hooks do Claude Code. O sistema é acionado em decisões de baixa confiança (abaixo de 0,70) e adiciona aproximadamente 3x o custo de tokens por deliberação. Para decisões de segurança, escolhas de arquitetura e qualquer coisa irreversível, esse custo se paga na primeira vez que detecta algo que um único agente deixou passar. Para correções de documentação e edições rotineiras, pule a deliberação completamente.

A Noite em que Meus Agentes Concordaram em Quebrar Tudo

Fevereiro de 2026. Uma terça-feira. Pedi ao meu agente para “investigar melhorias no sistema de despacho de hooks” e saí para fazer café. O agente avaliou sua própria confiança em 0,58 (abaixo do limite de 0,70), o que acionou a deliberação. O sistema criou 3 agentes de pesquisa. Cada agente de pesquisa avaliou o problema, encontrou subproblemas e criou seus próprios agentes de pesquisa. Esses agentes criaram mais.

Sete minutos depois: 23 processos de agente ativos. $4,80 em créditos de API consumidos. O diretório ~/.claude/state/ enchendo com arquivos JSON de estado enquanto cada agente diligentemente persistia seus achados. Consumo de tokens subindo a aproximadamente $0,70 por minuto sem sinal de convergência.

A proteção contra recursão que eu havia construído para o sistema de qualidade rastreava profundidade (pai cria filho, filho cria neto) mas não largura (pai cria 12 filhos que cada um cria mais 12). O limite de profundidade de 3 nunca disparou porque os agentes se espalharam horizontalmente. Encerrei os processos manualmente e fiquei olhando para os arquivos de estado.

Cada agente concordou que o sistema de despacho de hooks precisava de melhorias. Cada agente propôs mudanças que soavam razoáveis. Nenhum agente questionou se a investigação em si estava com escopo correto. Vinte e três agentes alcançando consenso sobre a pergunta errada.

A correção levou 20 minutos: um orçamento de criação que rastreia o total de filhos ativos por pai, limitado a 12. A lição mais profunda levou mais tempo. A curva de aceleração de infraestrutura que eu havia documentado tornou o sistema de deliberação possível de construir em 2 semanas, precisamente porque a infraestrutura de hooks já existia. Mas construção rápida não previne falhas estruturais. A progressão de pipelines RAG de agente único para sistemas autônomos segue um arco previsível. A deliberação multi-agente fica no final por um motivo: você só a constrói depois que um agente único entrega com confiança a resposta errada.

O consenso, não a discordância, era o modo de falha perigoso.

Anatomia de uma Deliberação

O sistema tem dois componentes estruturais: uma máquina de estados que sequencia o trabalho e duas comportas de validação que impedem que um consenso ruim seja entregue.

A Máquina de Estados

Sete fases, cada uma condicionada pela anterior:

IDLE -> RESEARCH -> DELIBERATION -> RANKING -> PRD_GENERATION -> COMPLETE
                                                                    |
                                                              (or FAILED)

RESEARCH: Agentes independentes investigam o tópico. Cada agente recebe uma persona diferente (Technical Architect, Security Analyst, Performance Engineer e 7 outras). O isolamento de contexto garante que os agentes não possam ver os achados uns dos outros durante a pesquisa. L0 (regras do sistema) e L1 (contexto do projeto) são compartilhados. L2 (foco específico do agente) é privado. L3 (padrões de domínio) carrega bibliotecas de padrões relevantes por persona.¹

DELIBERATION: Os agentes veem todos os achados de pesquisa e geram alternativas. O agente Debate identifica conflitos entre perspectivas. O agente Synthesis combina achados não contraditórios.

RANKING: Cada agente pontua cada abordagem proposta em 5 dimensões ponderadas:

As pontuações ponderadas são agregadas em uma pontuação de consenso. O limite é adaptativo por tarefa: 0,85 para decisões de segurança, 0,80 para arquitetura, 0,70 padrão, 0,65 para refatoração, 0,50 para documentação.²

As Duas Comportas

Comporta 1: Validação de Consenso (hook PostToolUse:Task). Quatro verificações são executadas após cada agente de deliberação completar:

1. A fase deve ter alcançado pelo menos RANKING
2. Mínimo de 2 agentes concluídos (configurável)
3. A pontuação de consenso atende ao limite adaptativo por tarefa
4. Se algum agente discordou, suas preocupações devem estar documentadas

Falhar em qualquer verificação bloqueia o avanço da deliberação.³

Comporta 2: Pride Check (hook Stop). Cinco verificações de qualidade são executadas antes que a sessão possa ser encerrada:

1. Métodos Diversos: Múltiplas personas únicas representadas
2. Transparência de Contradições: Discordâncias têm razões documentadas
3. Tratamento de Complexidade: Pelo menos 2 alternativas geradas
4. Confiança do Consenso: Pontuação classificada como forte (acima de 0,85) ou moderada (0,70-0,84)
5. Evidência de Melhoria: Confiança final excede a confiança inicial

A arquitetura de duas comportas detecta problemas em estágios diferentes. A Comporta 1 previne convergência prematura durante o processo. A Comporta 2 previne a entrega de resultados que parecem completos mas carecem de rigor.

Analistas de Inteligência Tiveram Esse Problema Primeiro

Construí o sistema de deliberação em janeiro de 2026. Duas semanas depois, encontrei Psychology of Intelligence Analysis de Richards Heuer em uma lista de leitura sobre tomada de decisão estruturada. O Capítulo 8 descreve a Análise de Hipóteses Concorrentes (ACH): analistas avaliam evidências contra múltiplas hipóteses simultaneamente, em vez de construir um caso para sua conclusão preferida.⁴

O paralelo foi desconfortável. O framework de Heuer, publicado em 1999 para a CIA, abordava a mesma falha estrutural que eu estava depurando: pessoas inteligentes convergindo em uma única explicação porque nunca se forçaram a avaliar alternativas.

Veja como a ACH funciona na prática. Um analista de inteligência investigando um suposto programa de armas não pergunta “isso é um programa de armas?” (viés de confirmação). Em vez disso, o analista lista todas as hipóteses plausíveis (programa de armas, pesquisa civil, instalação de uso duplo), avalia cada evidência contra cada hipótese e identifica qual evidência melhor distingue entre as hipóteses.

Meu sistema faz a mesma coisa com vocabulário diferente. Três agentes avaliam uma mudança proposta de esquema de banco de dados. O Agente A (Technical Architect) escreve: “Esquema está limpo, normalizado até 3NF.” O Agente B (Performance Engineer) escreve: “Os padrões de consulta vão exigir joins em 4 tabelas em cada leitura.” O Agente C (Security Analyst) escreve: “Campos PII não estão criptografados em repouso.” Mesmo esquema, três avaliações diferentes, três evidências distinguidoras. A fase de ranking avalia a abordagem proposta contra essas avaliações independentes da mesma forma que a ACH avalia hipóteses contra evidências.

Não projetei o sistema a partir do framework de Heuer. Reinventei um subconjunto da ACH por tentativa e erro, e depois descobri que alguém já havia escrito o livro-texto. A versão honesta é mais útil que a lisonjeira: chegar à mesma arquitetura independentemente confirma que o problema subjacente é real, não teórico.

Por Que o Consenso É o Modo de Falha Perigoso

Charlan Nemeth estudou a dissidência minoritária de 1986 até seu livro de 2018, In Defense of Troublemakers. Grupos com dissidentes tomam decisões melhores do que grupos que alcançam concordância rápida. O dissidente não precisa estar certo. O ato de discordar força a maioria a examinar suposições que de outra forma seriam ignoradas.⁵

James Surowiecki, em The Wisdom of Crowds, identifica quatro condições para decisões coletivas sábias: diversidade de opinião, independência de julgamento, descentralização e um mecanismo de agregação.⁶ Viole a independência (deixe os agentes verem o trabalho uns dos outros durante a pesquisa) e você obtém comportamento de manada. Viole a diversidade (use prompts idênticos para cada agente) e você obtém câmaras de eco.

Testei a condição de independência diretamente. Dois agentes avaliando a mesma estratégia de implantação com visibilidade dos achados um do outro: o Agente A pontuou risco em 0,45. O Agente B viu essa pontuação e produziu 0,48. Os mesmos agentes sem visibilidade: 0,45 e 0,72. A diferença entre 0,48 e 0,72 é o custo do comportamento de manada. A avaliação independente do Agente B sinalizou um risco de orquestração de contêineres que desapareceu quando a pressão social entrou na avaliação.

Trabalhos recentes confirmam que ambos os padrões se mantêm para agentes LLM. Choi et al. no NeurIPS 2025 descobriram que votação majoritária entre agentes instruídos independentemente captura a maior parte dos ganhos de qualidade de sistemas multi-agente.⁷ Kaesberg et al. no ACL 2025 quantificaram a divisão: votação melhora tarefas de raciocínio em 13,2%, enquanto protocolos de consenso melhoram tarefas de conhecimento em 2,8%.⁸ Isso sugere que a escolha deve depender do tipo de tarefa. É por isso que meu sistema usa limites adaptativos por tarefa em vez de um único número de consenso.

Wu et al. testaram se agentes LLM conseguem genuinamente debater e descobriram que, sem incentivos estruturais para discordância, os agentes convergem para a resposta inicial que soa mais confiante, independentemente da correção.⁹ Wynn et al. foram além: o debate pode ser ativamente prejudicial. Modelos mudam de respostas corretas para incorretas em resposta ao raciocínio de pares, mesmo quando modelos mais fortes superam em número os mais fracos.¹⁰ Liang et al. identificaram a causa raiz como “Degeneração de Pensamento”: uma vez que um LLM estabelece confiança em uma posição, a autorreflexão não consegue gerar contra-argumentos novos, tornando a avaliação multi-agente estruturalmente necessária.¹¹

Meu sistema aborda a independência por meio de isolamento de contexto (camadas L2 são privadas do agente durante a pesquisa). A diversidade vem de 10 personas distintas com diferentes prioridades de avaliação. A agregação usa pontuação ponderada em 5 dimensões em vez de votação simples. O incentivo estrutural para discordância é mais fraco: eu rastreio se a discordância está documentada, mas não recompenso agentes por discordar. O módulo de detecção de conformidade tenta abordar essa lacuna, com resultados mistos.

Detectando Discordância Falsa

O módulo de conformidade rastreia padrões que sugerem que os agentes estão concordando sem avaliação genuína. Preocupações documentadas que repetem a mesma linguagem entre agentes, pontuações que se agrupam suspeitamente perto do limite, ou apoio unânime de todas as personas (um Security Analyst e um Performance Engineer raramente concordam em tudo) disparam alertas.

O que ele detecta: discordância genérica (agentes copiando a linguagem de preocupação uns dos outros), agrupamento de pontuações (cada agente pontuando dentro de 0,3 pontos em uma escala de 10 pontos) e perspectivas minoritárias ausentes (aprovação unânime de personas com prioridades conflitantes).

Um exemplo dos meus logs: cinco agentes avaliaram uma refatoração de autenticação. Todos os cinco pontuaram risco de segurança entre 7,1 e 7,4. O detector de conformidade sinalizou o agrupamento. Quando reexecutei com isolamento de contexto novo (limpando caches L2), as pontuações se espalharam para 5,8-8,9. O agrupamento original refletia contaminação de contexto compartilhado, não concordância genuína.

O que ele não detecta: concordância sofisticada onde os agentes genuinamente avaliam da perspectiva de sua persona, mas por acaso chegam à mesma conclusão por razões diferentes. O módulo não consegue distinguir consenso real de comportamento de manada quando o raciocínio parece independente. Tentei treinar um classificador com exemplos de concordância genuína vs. fabricada, mas os dados de treinamento eram muito pequenos (menos de 50 sessões de deliberação) e o sinal muito fraco. O detector de conformidade detecta os casos óbvios e perde os sutis.

A avaliação honesta: a detecção de conformidade adiciona uma verificação de sanidade útil nos 10-15% das deliberações onde os agentes convergem rápido demais. Para os outros 85-90%, as comportas de consenso e pride check fornecem validação suficiente. Considerei construir um sistema de conformidade mais sofisticado e decidi que o esforço de engenharia não compensaria a melhoria marginal.

O Que Não Funcionou

Beco Sem Saída 1: Rodadas de Debate de Forma Livre

A primeira versão fazia os agentes escreverem longas réplicas aos achados uns dos outros: 3 rodadas de texto de ida e volta. Assisti a uma deliberação sobre estratégia de indexação de banco de dados se desenrolar ao longo de 7.500 tokens de debate. Rodada 1: discordância genuína sobre índices compostos vs. coluna única. Rodada 2: posições reafirmadas com elaboração menor. Rodada 3: argumentos quase idênticos embrulhados em palavras diferentes. O sinal atingiu o pico na rodada 1 e degradou a partir daí.

O custo de tokens por deliberação chegou a $2-4, e a densidade de informação útil caiu a cada rodada. A correção: pontuação estruturada por dimensão substituiu o debate de forma livre. Os agentes pontuam propostas em 5 dimensões com valores numéricos em vez de escrever ensaios. Custo e tempo caíram aproximadamente 60%, e a qualidade do ranking final realmente melhorou porque pontuações numéricas forçam uma precisão que a prosa obscurece.

Beco Sem Saída 2: Recursão Baseada em Profundidade para Deliberação

O incidente de criação infinita expôs um erro fundamental de modelagem. A proteção contra recursão rastreava profundidade: pai na profundidade 0 cria filho na profundidade 1, filho cria neto na profundidade 2, profundidade máxima 3. Mas agentes de deliberação deveriam se expandir em largura (10 agentes de pesquisa no mesmo nível), não em profundidade (um agente criando um filho criando um neto). O limite de profundidade de 3 nunca disparou porque 23 agentes na profundidade 1 ainda é “profundidade 1.”

A correção foi um modelo de orçamento de criação: agentes de deliberação herdam a profundidade do pai em vez de incrementá-la, e compartilham um orçamento total de criação de filhos limitado a 12. O modelo de orçamento mapeia para o modo de falha real (muitos agentes no total) em vez de uma métrica proxy (muitos níveis de aninhamento). A linhagem de agentes é rastreada em um arquivo JSON para que o orçamento persista entre completações assíncronas de agentes.¹²

Beco Sem Saída 3: Uma Única Comporta de Validação

A primeira implementação executava um único hook de validação no final da sessão, combinando verificações de consenso com verificações de qualidade. O modo de falha apareceu na primeira semana. Um agente completou a deliberação com uma pontuação de consenso de 0,52 — abaixo do limite de 0,70. Ele então continuou em tarefas não relacionadas por 20 minutos antes que o hook de final de sessão sinalizasse a falha. Vinte minutos de trabalho construídos sobre uma base que não havia passado na validação.

Dividir em duas comportas resolveu o problema de temporização. A Comporta 1 (validação de consenso) roda como um hook PostToolUse:Task, detectando consenso ruim imediatamente após o agente de deliberação completar. A Comporta 2 (pride check) roda no final da sessão, detectando problemas de qualidade que se acumularam ao longo das etapas. Dois hooks em pontos diferentes do ciclo de vida correspondem a como as falhas realmente ocorrem: algumas são instantâneas (pontuação ruim) e algumas são graduais (baixa diversidade, documentação de discordância ausente).

A Matemática Honesta

Deliberação custa tokens. Cada agente de pesquisa processa aproximadamente 5.000 tokens de contexto e gera 2.000-3.000 tokens de achados. Com 3 agentes (mínimo para deliberação útil) são 15.000-24.000 tokens adicionais por decisão. Com 10 agentes (painel completo de pesquisa), aproximadamente 50.000-80.000 tokens.

Com preços do Opus ($15/$75 por milhão de tokens), uma deliberação de 3 agentes custa aproximadamente $0,68-0,90. Uma deliberação de 10 agentes custa $2,25-3,00. Meu sistema aciona deliberação em aproximadamente 10% das decisões (aquelas com pontuação abaixo de 0,70 de confiança), então o custo amortizado entre todas as decisões é de $0,23-0,30 por sessão.

Se isso vale a pena depende do custo de uma decisão ruim. Uma vulnerabilidade de segurança não detectada em um deploy de produção custa horas de resposta a incidentes. Uma escolha de arquitetura ruim custa semanas de refatoração. Um erro de digitação na documentação não custa nada.

O módulo de confiança determina quais decisões acionam deliberação. Quatro dimensões (ambiguidade, complexidade, risco e dependência de contexto) produzem cada uma uma pontuação de 0 a 1. Múltiplas dimensões precisam pontuar alto para que a confiança geral caia abaixo de 0,70 e acione a deliberação. Problemas unidimensionais (“isso é complexo mas não ambíguo”) ficam acima do limite e pulam a deliberação.¹³

Dois Agentes, Uma Regra

Você não precisa de 10 personas de pesquisa, 8 módulos Python ou 141 testes para obter valor da deliberação multi-agente. Comece com 2 agentes e 1 regra: os agentes devem avaliar independentemente antes de ver o trabalho um do outro.

Deliberação Mínima Viável

Decision arrives
  |
  v
Confidence check: is this risky, ambiguous, or irreversible?
  |
  ├── NO  -> Single agent decides (normal flow)
  |
  └── YES -> Spawn 2 agents with different system prompts
             Agent A: "Argue FOR this approach"
             Agent B: "Argue AGAINST this approach"
             |
             v
             Compare findings
             |
             ├── Agreement with different reasoning -> Proceed
             ├── Genuine disagreement -> Investigate the conflict
             └── Agreement with same reasoning -> Suspect herding

O fluxograma de decisão acima cobre 80% do valor. Aqui está a implementação mínima:

# Minimum viable deliberation: 2 agents, 1 rule
def deliberate(decision_description):
    agent_for = spawn_agent(
        f"Argue FOR this approach: {decision_description}",
        persona="advocate"
    )
    agent_against = spawn_agent(
        f"Argue AGAINST this approach: {decision_description}",
        persona="critic"
    )

    if same_reasoning(agent_for, agent_against):
        return "WARNING: Suspect herding. Verify independently."
    elif genuine_conflict(agent_for, agent_against):
        return "Investigate the specific disagreement."
    else:
        return "Proceed. Independent agreement with different reasoning."

Todo o resto adiciona melhoria incremental: o ranking de 5 dimensões, limites adaptativos por tarefa, detecção de conformidade. O insight central permanece simples: duas perspectivas independentes detectam falhas que uma única perspectiva não percebe.

Agente Único vs. Multi-Agente: O Que Muda

O Que Deliberar

Testando a Deliberação

O sistema executa 141 testes em três camadas:¹⁴

• 48 testes de integração bash: Validação de sintaxe de hooks, fluxo de consenso, comportas de pride check, aplicação de proteção contra recursão e compatibilidade entre configurações
• 81 testes unitários Python: Todos os 7 módulos de biblioteca (máquina de estados, confiança, isolamento de contexto, ranking, agentes, conformidade, geração de PRD)
• 12 testes ponta a ponta: Simulação completa do pipeline desde avaliação de confiança até saída de PRD

Testar um sistema projetado para discordância requer testar duas categorias. O caminho feliz: agentes discordam produtivamente e alcançam consenso. Os caminhos de falha: agentes convergem rápido demais, nunca convergem ou excedem orçamentos de criação. Os testes E2E simulam cada cenário com respostas determinísticas de agentes, verificando que as duas comportas detectam cada modo de falha documentado.

Comece com o padrão de 2 agentes. Adicione complexidade quando a versão de 2 agentes deixar passar algo específico. Cada agente, limite e comporta de validação adicional no meu sistema existe porque a versão mais simples falhou em uma tarefa específica. Suas falhas serão diferentes, e o sistema que você construir para detectá-las deve refletir suas falhas, não as minhas.

Principais Conclusões

• Consenso é o modo de falha perigoso. Agentes únicos não conseguem desafiar suas próprias suposições. Dois agentes independentes com diferentes prioridades de avaliação detectam pontos cegos estruturais que comportas de qualidade e filosofia não conseguem abordar.
• Duas comportas são melhores que uma. Validação de consenso durante o processo detecta problemas cedo. Pride check no final da sessão detecta problemas que se acumularam ao longo das etapas. Dividir a validação em dois hooks em pontos diferentes do ciclo de vida corresponde a como as falhas realmente ocorrem.
• Delibere seletivamente. O módulo de confiança aciona deliberação em aproximadamente 10% das decisões. Deliberar tudo desperdiça tokens. Não deliberar nada perde as decisões onde perspectivas independentes mais importam.

FAQ

Referências