Six Thinking Hats na Era das LLMs: Pensamento Paralelo, Sistemas Multiagentes e Agent Harnesses

Se uma LLM consegue responder a quase qualquer pergunta em segundos, por que precisaríamos de seis perspectivas? A resposta curta: porque uma boa resposta e uma boa decisão não são a mesma coisa. Decisões complexas misturam fatos, riscos, benefícios, alternativas e reações de pessoas afetadas — e, quando tudo isso chega misturado em um único texto fluente, fica difícil saber o que foi verificado, o que é suposição e o que foi simplesmente esquecido.

Este artigo propõe usar uma técnica de facilitação criada nos anos 1980, os Six Thinking Hats de Edward de Bono, como inspiração para estruturar análises com LLMs, sistemas multiagentes e agent harnesses. Ao longo do texto, três coisas ficam separadas de propósito: (1) o método original, (2) o que as pesquisas publicadas mostram e (3) uma proposta autoral de arquitetura, que ainda precisa ser validada.

A proposta, portanto, não é pedir a uma LLM “analise usando seis chapéus”. É construir um protocolo capaz de:

1. separar fatos, percepções, riscos, benefícios, alternativas e governança da discussão;
2. impedir que o primeiro argumento gerado determine prematuramente a conclusão;
3. dar visibilidade a evidências faltantes, divergências, premissas e riscos;
4. oferecer resultados auditáveis e comparáveis entre execuções;
5. distribuir etapas entre múltiplas instâncias, ferramentas e validadores — só quando houver necessidade real;
6. deixar um harness controlar contexto, custo, limites, permissões, rastreabilidade e participação humana.

O método original: Six Thinking Hats#

O método foi apresentado por Edward de Bono no livro Six Thinking Hats (Little, Brown, 1985) e é usado até hoje em reuniões, facilitação, resolução de problemas e inovação. Ele organiza uma discussão em seis modos distintos de atenção, cada um representado por um chapéu de cor diferente.

A contribuição central é o pensamento paralelo. Em vez de cada participante defender uma posição oposta ao mesmo tempo — um atacando riscos enquanto outro defende benefícios —, todos examinam o problema sob o mesmo chapéu, no mesmo momento, e depois mudam juntos de perspectiva. O resumo institucional do método é explícito: em discussões em grupo, é essencial que todos usem o mesmo chapéu ao mesmo tempo (deBono.com). A disciplina evita que críticas, ideias e emoções disputem espaço de forma desordenada.

Os seis chapéus, com uma possível adaptação para sistemas com LLMs:

• Chapéu Branco

  fatos e lacunas

  Informações disponíveis, fatos e dados que ainda faltam.

  Na IA

  Agente de evidências: recuperação, checagem e fontes.

  Entrega

  Fatos com fonte, premissas declaradas e dados ausentes.

  Risco

  Inventar dados ou tratar suposições como fatos.

• Chapéu Vermelho

  intuição e reações

  Sentimentos, palpites e reações imediatas.

  Na IA

  Hipóteses explícitas sobre reações de stakeholders.

  Entrega

  Percepções prováveis, preocupações e aceitação, a validar.

  Risco

  Afirmar que a IA sente emoções ou conhece sentimentos reais.

• Chapéu Preto

  cautela e riscos

  Riscos, limitações, problemas e onde algo pode dar errado.

  Na IA

  Análise crítica e red team de hipóteses e ameaças.

  Entrega

  Riscos com gravidade, impacto e mitigação.

  Risco

  Negatividade generalizada e conclusões sem fundamento.

• Chapéu Amarelo

  valor e benefícios

  Benefícios, valor, oportunidades e otimismo fundamentado.

  Na IA

  Mapeamento de ganhos plausíveis e condições de sucesso.

  Entrega

  Benefícios, indicadores e dependências.

  Risco

  Otimismo vazio e ROI inventado.

• Chapéu Verde

  criatividade e alternativas

  Criatividade, alternativas e novos caminhos.

  Na IA

  Geração de opções, reformulação e experimentos.

  Entrega

  Alternativas testáveis com trade-offs.

  Risco

  Muitas ideias sem critério nem viabilidade.

• Chapéu Azul

  controle do processo

  Organização do pensamento e condução do método.

  Na IA

  Orquestrador da deliberação e sintetizador.

  Entrega

  Escopo, sequência, convergência, decisão ou pedido de mais dados.

  Risco

  Confundir síntese com prova e forçar consenso.

O salto para a IA: um chapéu não é, necessariamente, um agente#

Levar o método para LLMs exige preservar a diferença entre técnica de facilitação e arquitetura de software. Há pelo menos quatro formas de fazer essa transposição, com custos e graus de fidelidade diferentes.

Modo A — Prompt único, seis etapas#

Uma única LLM percorre as seis perspectivas, em sequência, na mesma conversa. É simples, barato e suficiente para muitas tarefas exploratórias. A limitação é a falta de independência: a mesma instância carrega para a etapa seguinte o que concluiu na anterior. É o baseline que qualquer arquitetura mais cara precisa superar.

Modo B — Pensamento paralelo fiel ao original#

Várias instâncias analisam a mesma perspectiva ao mesmo tempo — primeiro todas no branco, depois todas no verde, e assim por diante. Cada uma gera sua contribuição de forma independente, e um coordenador consolida a etapa antes de seguir. É a tradução mais literal da dinâmica proposta por de Bono.

Modo C — Especialistas por chapéu#

Cinco papéis distintos (branco, vermelho, preto, amarelo e verde) são acionados em sequência ou em paralelo, conforme as dependências, e o azul planeja, controla e sintetiza. É uma adaptação inspirada no método, não o método em si: os chapéus passam a funcionar como especializações concorrentes ou complementares. Sem entradas, critérios e estados realmente diferentes, “seis agentes” podem ser só seis variações superficiais do mesmo prompt.

Modo D — Harness adaptativo e verificável#

Um controlador externo decide se o caso pede uma resposta direta, uma sequência curta de chapéus ou uma deliberação completa. O sistema incorpora ferramentas, evidências, memória, orçamento, logs, validação e aprovação humana. É a proposta mais avançada — e a mais cara de construir.

A última linha é proposital: nenhuma dessas opções garante resultado melhor. Cada uma precisa ser medida contra as outras no contexto de uso.

O que é um agent harness#

Três termos costumam ser usados como sinônimos, mas não são:

• LLM: o modelo que interpreta instruções e gera respostas.
• Agente: um componente com instruções, acesso a ferramentas e capacidade de executar etapas em um fluxo.
• Harness: a estrutura externa que envolve o modelo ou o agente e governa seu funcionamento — execução, ferramentas, permissões, estado, contexto, recuperação de falhas, limites, observabilidade, avaliação e passagem de tarefas entre componentes.

O harness não é “um prompt longo” nem um framework específico. LangGraph, SDKs de agentes e sistemas próprios podem implementar partes dessa orquestração — o Send do LangGraph, por exemplo, permite distribuir trabalho em paralelo entre nós e depois consolidar os resultados (documentação). Nenhum deles torna a análise correta automaticamente.

O termo ganhou espaço na engenharia de agentes. A Anthropic descreve o harness como a estrutura em volta do modelo que permite a um agente trabalhar ao longo de muitas sessões, com artefatos de progresso e trabalho incremental (Anthropic, 2025), e observa que componentes do harness devem ser revistos à medida que os modelos evoluem, porque muitos compensam limitações que modelos mais novos podem não ter (Anthropic, 2026). A documentação da OpenAI também usa o termo para a camada que executa o ciclo entre modelo e ferramentas (OpenAI, Agents API: Architecture).

Para um protocolo de chapéus, as responsabilidades recomendadas do harness são:

Arquitetura proposta: Six Hats Deliberation Harness#

flowchart TD
A[Problema e critérios de decisão] --> B[Classificador de complexidade e risco]
B --> C{Precisa de deliberação extensa?}
C -->|Não| D[LLM única com resposta curta]
C -->|Sim| E[Chapéu Azul: planejamento e agenda]
E --> F[Chapéu Branco: fatos e fontes]
F --> G[Pacote de evidências verificáveis]
G --> H[Chapéu Verde: opções]
G --> I[Chapéu Amarelo: benefícios]
G --> J[Chapéu Preto: riscos]
G --> K[Chapéu Vermelho: reações hipotéticas]
H --> L[Agregador estruturado]
I --> L
J --> L
K --> L
L --> M[Verificador de alegações e regras]
M --> N[Chapéu Azul: síntese com divergências]
N --> O{Ação sensível ou irreversível?}
O -->|Sim| P[Aprovação humana]
O -->|Não| Q[Relatório e trilha de auditoria]
P --> Q
D --> Q

Por que o Branco vem antes dos demais? Como regra sugerida, porque reduz o risco de avaliar estratégias a partir de fatos não verificados. Não é uma ordem universal do método de de Bono — o chapéu azul pode planejar outras sequências.

Paralelismo: verde, amarelo, preto e vermelho recebem o mesmo pacote validado de evidências e trabalham de forma independente. Um ciclo opcional pode permitir que o preto revise os benefícios do amarelo e que o verde proponha uma mitigação criativa — limitado a uma rodada, salvo justificativa medida.

Contrato de dados#

Cada execução gera um registro estruturado. O exemplo abaixo é um esquema ilustrativo, não um JSON Schema formal nem uma API pronta:

{
  "decision_id": "case-001",
  "question": "Devemos lançar o novo produto?",
  "constraints": ["orçamento", "LGPD", "prazo"],
  "evidence": [
    { "id": "ev-01", "claim": "Premissa a verificar", "source_url": null, "status": "unverified" }
  ],
  "hats": {
    "white": { "facts": [], "unknowns": [], "sources": [] },
    "red": { "stakeholder_hypotheses": [], "validation_needed": [] },
    "black": { "risks": [], "mitigations": [] },
    "yellow": { "benefits": [], "assumptions": [], "metrics": [] },
    "green": { "alternatives": [], "experiments": [] },
    "blue": { "synthesis": "", "tradeoffs": [], "unresolved": [], "next_steps": [] }
  },
  "checks": { "source_validation": "pending", "policy_review": "pending" },
  "human_approval_required": true,
  "execution": { "prompt_version": "v1", "model_ids": [], "token_usage": 0, "elapsed_ms": 0 }
}

Repare no campo unresolved do chapéu azul: a síntese tem um lugar explícito para o que não foi resolvido.

Protocolo de execução#

Um pseudocódigo independente de SDK — as funções de LLM e de validação precisam de adaptadores reais antes de serem executadas:

def deliberate(problem, config):
    route = assess_complexity_and_risk(problem, config)
    if route == "direct":
        return direct_answer(problem)

    agenda = blue_plan(problem, config)
    evidence = white_research(problem, agenda, allowed_tools=["retrieval"])
    evidence = verify_sources(evidence)

    opinions = run_parallel({
        "green": lambda: green_alternatives(problem, evidence),
        "yellow": lambda: yellow_value(problem, evidence),
        "black": lambda: black_risks(problem, evidence),
        "red": lambda: red_stakeholder_hypotheses(problem, evidence),
    }, timeout_seconds=config.max_runtime_seconds)

    checked = validate_claims_and_schema(evidence, opinions)
    report = blue_synthesize(problem, evidence, checked, agenda)

    if config.high_stakes or report.needs_human_approval:
        report.status = "awaiting_human_review"

    persist_audit_artifacts(report, evidence, checked, config)
    return report

Roteamento adaptativo#

Nem todo problema merece seis chamadas de LLM. O roteador escolhe o protocolo pela classe do problema:

Um protocolo pequeno e bem avaliado pode superar uma arquitetura mais cara e ornamentada. Essa intuição também aparece na engenharia de agentes: a recomendação é começar pela solução mais simples que funciona e só adicionar complexidade quando resultados medidos justificarem (Anthropic, 2024).

Exemplo aplicado: um assistente de IA para serviços financeiros#

Uma empresa quer disponibilizar um assistente com LLM para tirar dúvidas de clientes e orientar a navegação por produtos, sem aprovar crédito automaticamente. Deve lançar?

• Branco — fatos e lacunas: registra a base de conhecimento aprovada, os tipos de solicitação, os dados pessoais tratados e os indicadores atuais de atendimento. Aponta o que falta: não há testes de segurança nem taxa de resolução conhecida.
• Vermelho — percepções hipotéticas: clientes podem gostar de respostas rápidas ou desconfiar de informações automatizadas; atendentes podem temer perda de autonomia. São hipóteses a validar com entrevistas e pesquisa de experiência, não sentimentos constatados.
• Preto — riscos: alucinações sobre produtos, exposição de dados, aconselhamento inadequado, prompt injection e falhas no escalonamento para humanos. Exige escopo de ferramentas, logs, filtros de acesso e testes de robustez.
• Amarelo — benefícios condicionais: atendimento ampliado e potencial redução do tempo de resposta, se a taxa de resolução, os erros e o custo total forem aceitáveis. Propõe métricas em vez de declarar economias.
• Verde — opções: piloto apenas informativo, atendimento híbrido, respostas com citação da base interna, confirmação humana antes de operações sensíveis e testes A/B com escopo restrito.
• Azul — síntese e próximos passos: não decide pela quantidade de “votos”. Recomenda um piloto condicionado a testes, revisão de riscos e critérios de aceite, e registra as perguntas sem resposta e quem é responsável por validá-las.

A saída esperada do harness é um documento com matriz de evidências, oportunidades, riscos, alternativas, condições de lançamento e o status requer_aprovacao_humana.

Aplicações em diferentes áreas#

O princípio vale para problemas com múltiplas perspectivas em muitas áreas. O desempenho, porém, depende do domínio, da qualidade das evidências e do desenho da avaliação.

A proposta não é que uma técnica de facilitação “melhore qualquer LLM em qualquer tarefa”. É que um protocolo multidimensional de análise, apoiado em fontes e validações, seja potencialmente útil em domínios com características parecidas: decisão, criatividade e avaliação de trade-offs.

O que a evidência sustenta#

A literatura sobre o tema se divide em três grupos: estudos que combinam diretamente Six Hats e IA generativa, estudos adjacentes sobre debate e diversidade de perspectivas entre LLMs, e evidências negativas ou condicionais sobre custo e desempenho.

Dois detalhes desses estudos conversam diretamente com a proposta. No protótipo de Rachmann, o chapéu azul escolheu a alternativa apoiada pela maioria dos outros chapéus — exatamente o comportamento de “votação” que um harness deveria evitar quando há divergências justificadas. E o trabalho de Kim, Yang & Jung mostra que “criar personagens” não basta: os papéis precisam impor critérios observáveis, não encenação.

Os custos também são reais. Ao descrever seu sistema de pesquisa multiagente, a Anthropic relata que esses sistemas usam cerca de 15 vezes mais tokens do que uma conversa comum e que só fazem sentido econômico em tarefas cujo valor justifique esse gasto (Anthropic, 2025).

Conclusão honesta da revisão: existem experiências iniciais diretamente ligadas a Six Hats e IA, estudos adjacentes sobre debate e engenharia de agentes, e evidência negativa ou condicional sobre custo e desempenho. Ainda é preciso validar empiricamente uma arquitetura de Six Hats com harness para cada classe de aplicação relevante.

Limitações e riscos#

1. Correlação entre agentes: instâncias do mesmo modelo, com os mesmos dados, podem repetir os mesmos erros. Vários “chapéus” não são validação independente.
2. Conformismo e convergência precoce: o azul pode sintetizar um consenso superficial e esconder discordâncias justificadas.
3. Encenação de persona: uma função rotulada “especialista crítico” pode produzir retórica sem análise efetiva.
4. Alucinação com aparência de método: uma estrutura organizada pode aumentar a credibilidade percebida sem melhorar a factualidade.
5. Custo e latência: o paralelismo reduz parte do tempo de parede, mas não elimina o custo de tokens e ferramentas.
6. Cascata de erros: premissas erradas no Branco contaminam todos os chapéus seguintes.
7. Prompt injection: materiais recuperados podem conter instruções adversariais; conteúdo externo deve ser tratado como dado não confiável.
8. Privacidade e confidencialidade: documentos e perspectivas de stakeholders podem conter informações sensíveis.
9. Falso senso de neutralidade: critérios e sequências são escolhas humanas; prompts não eliminam vieses.
10. Falta de avaliação: sem controle experimental, uma demonstração atraente pode ser confundida com ganho comprovado.

Quando não usar#

• Perguntas triviais ou factuais: uma resposta direta com checagem de fonte é mais barata e igualmente útil.
• Tarefas determinísticas: cálculos, validações e regras de negócio pertencem a código, não a deliberação.
• Ambientes sem validação: se não há como verificar fatos nem medir resultados, a estrutura só dá aparência de rigor.

Como testar sem inventar resultados#

A forma de demonstrar valor é um experimento comparativo, com resultados publicados — inclusive os negativos.

Questões de pesquisa#

• RQ1: aplicar os chapéus aumenta a cobertura de aspectos relevantes em comparação com uma resposta direta?
• RQ2: dividir os papéis em múltiplas instâncias melhora os resultados mais do que uma única LLM percorrendo as seis etapas?
• RQ3: adicionar recuperação e verificação de fontes melhora a precisão factual?
• RQ4: um harness adaptativo preserva a qualidade com custo menor do que acionar os seis chapéus em todos os casos?
• RQ5: em quais tipos de tarefa o método tem efeito positivo, neutro ou negativo?

Condições experimentais#

O conjunto de tarefas deve ser um benchmark próprio e diverso — decisões de arquitetura, ideação de produto, educação, planejamento operacional, atendimento, governança de IA e análise de riscos —, com problemas simples e difíceis e casos com fatos incompletos, requisitos conflitantes e premissas deliberadamente falsas.

Protocolo de avaliação#

Benefícios como hipóteses mensuráveis#

As métricas de custo e risco são obrigatórias em qualquer comparação: tokens de entrada e saída, custo por caso, latência p50/p95, taxa de timeout, chamadas de ferramentas, qualidade factual, alucinação, falhas de esquema, concordância entre avaliadores e impacto sobre usuários. E um alerta: mais argumentos ou respostas mais longas não significam mais correção.

Um template de prompt para começar#

Para experimentar o Modo A — uma LLM, seis etapas —, este template já incorpora as regras de cuidado discutidas acima:

Você atua como facilitador de uma sessão inspirada na metodologia
Six Thinking Hats, de Edward de Bono.

PROBLEMA:
[descrever o problema e as opções reais]

REGRAS:
1. Comece no chapéu azul definindo escopo, critérios e sequência.
2. Branco: separe fatos comprovados, premissas e lacunas.
   Não invente dados; diga quando uma fonte seria necessária.
3. Vermelho: apresente hipóteses de percepção de grupos afetados.
   Não atribua emoções reais a pessoas sem evidência.
4. Preto: examine falhas, limitações e riscos com mitigação.
5. Amarelo: explicite benefícios condicionais e como mensurá-los.
6. Verde: proponha alternativas concretas e experimentos.
7. Azul: sintetize trade-offs, divergências, fontes e próximos passos.
8. Não trate uma conclusão de IA como decisão humana definitiva.
9. Não exponha raciocínio privado; forneça justificativas concisas,
   premissas observáveis e referências quando disponíveis.
10. Para fatos essenciais sem fonte, indique "não verificado".

SAÍDA:
- Uma seção curta por chapéu.
- Matriz final: alternativa | valor | riscos | dependências.
- Recomendação condicional com incertezas e ações de validação.

Para a versão multiagente, reutilize essas responsabilidades como especificações independentes de workers e use o azul como coordenador. Em vez de esperar que a diversidade surja do nome do chapéu, defina contratos, evidências e métricas de saída para cada um.

Cada função deve receber o problema, os critérios, as evidências permitidas, a versão do prompt, os limites e um objetivo único — e devolver uma estrutura validável com afirmações, fontes, incertezas, recomendações condicionais e próximos passos. O azul recebe todas as contribuições sem apagar suas contradições, e a resposta final separa:

• fatos comprovados;
• hipóteses e percepções;
• oportunidades condicionais;
• riscos e medidas de mitigação;
• alternativas e experimentos;
• discordâncias ainda em aberto;
• a decisão proposta e quem tem autoridade para validá-la.

Conclusão#

Six Thinking Hats oferece algo que falta em muitas aplicações com LLMs: disciplina. Separar fatos de percepções, riscos de benefícios e criatividade de condução torna a análise mais explícita e mais fácil de auditar. Levar essa disciplina para sistemas com IA pode ser feito de forma simples — uma LLM percorrendo etapas — ou com agentes especializados e um harness completo. Em todos os casos, o valor real precisa ser demonstrado com evidências, avaliação comparativa e supervisão humana.

O diferencial não é colocar seis personalidades para conversar; é projetar uma deliberação disciplinada e garantir que o software registre, verifique e exponha cada perspectiva — inclusive as que discordam.

A IA pode ampliar o número de perspectivas consideradas. Mas uma boa decisão depende menos da quantidade de vozes geradas e mais da qualidade das evidências, da transparência dos conflitos e da responsabilidade de quem decide.

O próximo passo natural é uma prova de conceito pequena, comparando as cinco condições experimentais com avaliação humana — e publicando os resultados, inclusive os negativos.

Referências#

Método original

1. de Bono, E. (1985). Six Thinking Hats. Little, Brown. Google Books
2. de Bono, E. (2016). Six Thinking Hats. Penguin Life. Editora
3. de Bono Group. Six Thinking Hats. Site oficial
4. deBono. Six Thinking Hats Summary. debono.com

Six Hats e IA generativa

5. Rachmann, A. (2024). Six Thinking Chatbots: A Creativity Technique deployed via a Large Language Model. Joint Proceedings of REFSQ-2024 Workshops, CEUR-WS Vol. 3672. PDF · Código
6. Yu, M., Liu, Z., Long, T., Li, D., Deng, L., Kong, X. & Sun, J. (2025). Exploring cognitive presence patterns in GenAI-integrated six-hat thinking technique scaffolded discussion: an epistemic network analysis. International Journal of Educational Technology in Higher Education, 22, 48. DOI

LLMs e debate multiagente

7. Du, Y., Li, S., Torralba, A., Tenenbaum, J. B. & Mordatch, I. (2024). Improving Factuality and Reasoning in Language Models through Multiagent Debate. ICML 2024, PMLR 235. Link
8. Liang, T. et al. (2024). Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate. EMNLP 2024. DOI
9. Smit, A. P., Grinsztajn, N., Duckworth, P., Barrett, T. D. & Pretorius, A. (2024). Should we be going MAD? A Look at Multi-Agent Debate Strategies for LLMs. ICML 2024, PMLR 235. Link
10. Yoa, S. et al. (2026). Efficient Multi-Agent Reasoning via Confidence-Guided Adaptive Debate. ICML 2026, PMLR 306. Link
11. Kim, J., Yang, N. & Jung, K. (2024). Persona is a Double-edged Sword: Mitigating the Negative Impact of Role-playing Prompts in Zero-shot Reasoning Tasks. arXiv:2408.08631. Link

Harness e engenharia de agentes

12. Anthropic (2024). Building Effective Agents. Link
13. Anthropic (2025). How we built our multi-agent research system. Link
14. Anthropic (2025). Effective harnesses for long-running agents. Link
15. Anthropic (2026). Harness design for long-running application development. Link
16. OpenAI (2026). Introducing the Agents API. Link
17. OpenAI. Agents API: Architecture. Documentação
18. OpenAI. Safety in building agents. Documentação
19. LangChain. LangGraph — Send. Documentação