Six Thinking Hats in the Age of LLMs: Parallel Thinking, Multi-Agent Systems and Agent Harnesses

If an LLM can answer almost any question in seconds, why would we need six perspectives? The short answer: because a good answer and a good decision are not the same thing. Complex decisions mix facts, risks, benefits, alternatives and the reactions of affected people — and when all of that arrives blended into a single fluent text, it is hard to tell what was verified, what is an assumption and what was simply forgotten.

This article proposes using a facilitation technique created in the 1980s, Edward de Bono’s Six Thinking Hats, as inspiration for structuring analyses with LLMs, multi-agent systems and agent harnesses. Throughout the text, three things are deliberately kept apart: (1) the original method, (2) what published research shows and (3) an original architecture proposal that still needs validation.

The proposal, then, is not to ask an LLM to “analyze using six hats”. It is to build a protocol that can:

1. separate facts, perceptions, risks, benefits, alternatives and governance in the discussion;
2. keep the first generated argument from prematurely determining the conclusion;
3. make missing evidence, disagreements, assumptions and risks visible;
4. deliver results that are auditable and comparable across runs;
5. distribute steps across multiple instances, tools and validators — only when there is a real need;
6. let a harness control context, cost, limits, permissions, traceability and human participation.

The original method: Six Thinking Hats#

The method was introduced by Edward de Bono in the book Six Thinking Hats (Little, Brown, 1985) and is still used in meetings, facilitation, problem solving and innovation. It organizes a discussion into six distinct modes of attention, each represented by a hat of a different color.

The core contribution is parallel thinking. Instead of each participant defending an opposing position at the same time — one attacking risks while another defends benefits — everyone examines the problem under the same hat, at the same time, and then they switch perspective together. The official summary of the method is explicit: in group discussions, it is essential that everyone uses the same hat at the same time (deBono.com). This discipline keeps criticism, ideas and emotions from competing in a disorderly way.

The six hats, with a possible adaptation for LLM-based systems:

• White Hat

  facts and gaps

  Available information, facts and the data still missing.

  In AI

  Evidence agent: retrieval, fact-checking and sources.

  Output

  Sourced facts, stated assumptions and missing data.

  Risk

  Inventing data or treating assumptions as facts.

• Red Hat

  intuition and reactions

  Feelings, hunches and immediate reactions.

  In AI

  Explicit hypotheses about stakeholder reactions.

  Output

  Likely perceptions, concerns and acceptance, to be validated.

  Risk

  Claiming the AI feels emotions or knows people's real feelings.

• Black Hat

  caution and risks

  Risks, limitations, problems and where things could go wrong.

  In AI

  Critical analysis and red-teaming of hypotheses and threats.

  Output

  Risks with severity, impact and mitigation.

  Risk

  Blanket negativity and unfounded conclusions.

• Yellow Hat

  value and benefits

  Benefits, value, opportunities and grounded optimism.

  In AI

  Mapping plausible gains and conditions for success.

  Output

  Benefits, indicators and dependencies.

  Risk

  Empty optimism and made-up ROI.

• Green Hat

  creativity and alternatives

  Creativity, alternatives and new paths.

  In AI

  Option generation, reframing and experiments.

  Output

  Testable alternatives with trade-offs.

  Risk

  Many ideas with no criteria or feasibility.

• Blue Hat

  process control

  Organizing the thinking and running the method.

  In AI

  Deliberation orchestrator and synthesizer.

  Output

  Scope, sequence, convergence, a decision or a request for more data.

  Risk

  Mistaking synthesis for proof and forcing consensus.

The leap to AI: a hat is not necessarily an agent#

Bringing the method to LLMs requires keeping the difference between a facilitation technique and a software architecture. There are at least four ways to make this transposition, with different costs and degrees of fidelity.

Mode A — Single prompt, six steps#

A single LLM goes through the six perspectives in sequence, in the same conversation. It is simple, cheap and good enough for many exploratory tasks. The limitation is the lack of independence: the same instance carries what it concluded in one step into the next. It is the baseline any more expensive architecture has to beat.

Mode B — Parallel thinking, faithful to the original#

Several instances analyze the same perspective at the same time — first all on white, then all on green, and so on. Each one produces its contribution independently, and a coordinator consolidates the step before moving on. This is the most literal translation of de Bono’s dynamic.

Mode C — One specialist per hat#

Five distinct roles (white, red, black, yellow and green) are triggered in sequence or in parallel, depending on dependencies, while blue plans, controls and synthesizes. This is an adaptation inspired by the method, not the method itself: the hats become competing or complementary specializations. Without genuinely different inputs, criteria and state, “six agents” may be just six superficial variations of the same prompt.

Mode D — Adaptive, verifiable harness#

An external controller decides whether a case calls for a direct answer, a short sequence of hats or a full deliberation. The system incorporates tools, evidence, memory, budget, logs, validation and human approval. It is the most advanced proposal — and the most expensive to build.

The last row is intentional: none of these options guarantees a better result. Each one has to be measured against the others in its context of use.

What an agent harness is#

Three terms are often used as synonyms, but they are not:

• LLM: the model that interprets instructions and generates answers.
• Agent: a component with instructions, access to tools and the ability to execute steps in a flow.
• Harness: the external structure that wraps the model or agent and governs how it runs — execution, tools, permissions, state, context, failure recovery, limits, observability, evaluation and handoffs between components.

A harness is not “a long prompt” or a specific framework. LangGraph, agent SDKs and in-house systems can implement parts of this orchestration — LangGraph’s Send, for example, distributes work in parallel across nodes and then merges the results (documentation). None of them makes the analysis correct automatically.

The term has gained ground in agent engineering. Anthropic describes the harness as the structure around the model that lets an agent work across many sessions, with progress artifacts and incremental work (Anthropic, 2025), and notes that harness components should be revisited as models evolve, because many of them compensate for limitations newer models may no longer have (Anthropic, 2026). OpenAI’s documentation also uses the term for the layer that runs the loop between model and tools (OpenAI, Agents API: Architecture).

For a hats protocol, the recommended harness responsibilities are:

Proposed architecture: the Six Hats Deliberation Harness#

flowchart TD
A[Problem and decision criteria] --> B[Complexity and risk classifier]
B --> C{Needs extended deliberation?}
C -->|No| D[Single LLM with a short answer]
C -->|Yes| E[Blue Hat: planning and agenda]
E --> F[White Hat: facts and sources]
F --> G[Package of verifiable evidence]
G --> H[Green Hat: options]
G --> I[Yellow Hat: benefits]
G --> J[Black Hat: risks]
G --> K[Red Hat: hypothetical reactions]
H --> L[Structured aggregator]
I --> L
J --> L
K --> L
L --> M[Claims and rules verifier]
M --> N[Blue Hat: synthesis with disagreements]
N --> O{Sensitive or irreversible action?}
O -->|Yes| P[Human approval]
O -->|No| Q[Report and audit trail]
P --> Q
D --> Q

Why does White come before the others? As a suggested rule, because it lowers the risk of evaluating strategies on unverified facts. It is not a universal order in de Bono’s method — the blue hat can plan other sequences.

Parallelism: green, yellow, black and red receive the same validated evidence package and work independently. An optional cycle can let black review yellow’s benefits and green propose a creative mitigation — limited to one round, unless a measured justification exists.

Data contract#

Each run produces a structured record. The example below is an illustrative schema, not a formal JSON Schema or a ready-made API:

{
  "decision_id": "case-001",
  "question": "Should we launch the new product?",
  "constraints": ["budget", "privacy regulation", "deadline"],
  "evidence": [
    { "id": "ev-01", "claim": "Assumption to verify", "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 }
}

Note the blue hat’s unresolved field: the synthesis has an explicit place for what was not resolved.

Execution protocol#

SDK-independent pseudocode — the LLM and validation functions need real adapters before they can run:

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

Adaptive routing#

Not every problem deserves six LLM calls. The router picks the protocol by problem class:

A small, well-evaluated protocol can beat a more expensive and ornate architecture. The same intuition appears in agent engineering: the recommendation is to start with the simplest solution that works and add complexity only when measured results justify it (Anthropic, 2024).

Applied example: an AI assistant for financial services#

A company wants to offer an LLM-based assistant to answer customer questions and guide navigation across products, without approving credit automatically. Should it launch?

• White — facts and gaps: records the approved knowledge base, request types, personal data handled and current service indicators. Points out what is missing: there are no security tests and no known resolution rate.
• Red — hypothetical perceptions: customers may like fast answers or distrust automated information; agents may fear losing autonomy. These are hypotheses to validate through interviews and experience research, not observed feelings.
• Black — risks: hallucinations about products, data exposure, inappropriate advice, prompt injection and failures in escalation to humans. Requires tool scoping, logs, access filters and robustness tests.
• Yellow — conditional benefits: extended service hours and a potential reduction in response time, if the resolution rate, errors and total cost are acceptable. Proposes metrics instead of announcing savings.
• Green — options: an information-only pilot, hybrid service, answers citing the internal knowledge base, human confirmation before sensitive operations and tightly scoped A/B tests.
• Blue — synthesis and next steps: does not decide by counting “votes”. Recommends a pilot conditioned on tests, risk review and acceptance criteria, and records the open questions and who is responsible for validating them.

The expected harness output is a document with an evidence matrix, opportunities, risks, alternatives, launch conditions and the status requires_human_approval.

Applications across domains#

The principle applies to multi-perspective problems in many areas. Performance, however, depends on the domain, the quality of the evidence and the evaluation design.

The proposal is not that a facilitation technique “improves any LLM on any task”. It is that a multi-dimensional analysis protocol, backed by sources and validations, is potentially useful in domains with similar characteristics: decision-making, creativity and trade-off evaluation.

What the evidence supports#

The literature on the topic falls into three groups: studies that directly combine Six Hats with generative AI, adjacent studies on debate and diversity of perspectives among LLMs, and negative or conditional evidence about cost and performance.

Two details from these studies speak directly to the proposal. In Rachmann’s prototype, the blue hat chose the alternative backed by most of the other hats — exactly the “voting” behavior a harness should avoid when there are justified disagreements. And Kim, Yang & Jung’s work shows that “creating characters” is not enough: roles must impose observable criteria, not role-play.

Costs are real too. Describing its multi-agent research system, Anthropic reports that these systems use about 15 times more tokens than a regular chat and only make economic sense for tasks whose value justifies that spending (Anthropic, 2025).

An honest conclusion from the review: there are early experiences directly tied to Six Hats and AI, adjacent studies on debate and agent engineering, and negative or conditional evidence on cost and performance. A Six Hats architecture with a harness still has to be validated empirically for each relevant class of application.

Limitations and risks#

1. Correlation between agents: instances of the same model, with the same data, can repeat the same mistakes. Several “hats” are not independent validation.
2. Conformity and premature convergence: blue may synthesize a superficial consensus and hide justified disagreements.
3. Persona role-play: a role labeled “critical expert” may produce rhetoric without real analysis.
4. Hallucination dressed up as method: an organized structure can increase perceived credibility without improving factuality.
5. Cost and latency: parallelism cuts part of the wall-clock time but does not remove token and tool costs.
6. Error cascades: wrong assumptions in White contaminate every following hat.
7. Prompt injection: retrieved material may contain adversarial instructions; external content must be treated as untrusted data.
8. Privacy and confidentiality: documents and stakeholder perspectives may contain sensitive information.
9. False sense of neutrality: criteria and sequences are human choices; prompts do not remove bias.
10. Lack of evaluation: without experimental control, an attractive demo can be mistaken for a proven gain.

When not to use it#

• Trivial or factual questions: a direct answer with a source check is cheaper and just as useful.
• Deterministic tasks: calculations, validations and business rules belong in code, not in deliberation.
• Environments without validation: if facts cannot be checked and results cannot be measured, the structure only provides the appearance of rigor.

How to test it without inventing results#

The way to demonstrate value is a comparative experiment with published results — including the negative ones.

Research questions#

• RQ1: does applying the hats increase the coverage of relevant aspects compared with a direct answer?
• RQ2: does splitting roles across multiple instances improve results more than a single LLM going through six steps?
• RQ3: does adding source retrieval and verification improve factual accuracy?
• RQ4: does an adaptive harness preserve quality at a lower cost than running all six hats every time?
• RQ5: on which task types does the method have a positive, neutral or negative effect?

Experimental conditions#

The task set should be a diverse custom benchmark — architecture decisions, product ideation, education, operational planning, customer service, AI governance and risk analysis — with both easy and hard problems, and cases with incomplete facts, conflicting requirements and deliberately false assumptions.

Evaluation protocol#

Benefits as measurable hypotheses#

Cost and risk metrics are mandatory in any comparison: input and output tokens, cost per case, p50/p95 latency, timeout rate, tool calls, factual quality, hallucination, schema failures, inter-rater agreement and impact on users. And a warning: more arguments or longer answers do not mean more correctness.

A prompt template to get started#

To try Mode A — one LLM, six steps — this template already includes the safeguards discussed above:

You act as the facilitator of a session inspired by
Edward de Bono's Six Thinking Hats method.

PROBLEM:
[describe the problem and the real options]

RULES:
1. Start with the blue hat, defining scope, criteria and sequence.
2. White: separate proven facts, assumptions and gaps.
   Do not invent data; say when a source would be needed.
3. Red: present hypotheses about how affected groups may perceive it.
   Do not attribute real emotions to people without evidence.
4. Black: examine failures, limitations and risks, with mitigation.
5. Yellow: state conditional benefits and how to measure them.
6. Green: propose concrete alternatives and experiments.
7. Blue: synthesize trade-offs, disagreements, sources and next steps.
8. Do not treat an AI conclusion as a final human decision.
9. Do not expose private reasoning; give concise justifications,
   observable assumptions and references when available.
10. For essential facts without a source, write "not verified".

OUTPUT:
- One short section per hat.
- Final matrix: alternative | value | risks | dependencies.
- A conditional recommendation with uncertainties and validation actions.

For the multi-agent version, reuse these responsibilities as independent worker specifications and use blue as the coordinator. Instead of hoping diversity emerges from a hat’s name, define contracts, evidence and output metrics for each one.

Each role should receive the problem, the criteria, the allowed evidence, the prompt version, its limits and a single objective — and return a validatable structure with claims, sources, uncertainties, conditional recommendations and next steps. Blue receives every contribution without erasing its contradictions, and the final answer separates:

• proven facts;
• hypotheses and perceptions;
• conditional opportunities;
• risks and mitigations;
• alternatives and experiments;
• disagreements still open;
• the proposed decision and who has the authority to validate it.

Conclusion#

Six Thinking Hats offers something many LLM applications lack: discipline. Separating facts from perceptions, risks from benefits and creativity from process control makes the analysis more explicit and easier to audit. That discipline can be brought to AI systems in a simple way — one LLM going through steps — or with specialized agents and a full harness. In every case, the real value has to be demonstrated with evidence, comparative evaluation and human oversight.

The differentiator is not putting six personalities in a conversation; it is designing a disciplined deliberation and making sure the software records, verifies and exposes each perspective — including the ones that disagree.

AI can broaden the number of perspectives considered. But a good decision depends less on the number of voices generated and more on the quality of the evidence, the transparency of the conflicts and the accountability of whoever decides.

The natural next step is a small proof of concept comparing the five experimental conditions with human evaluation — and publishing the results, including the negative ones.

References#

Original method

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

Six Hats and generative AI

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 · Code
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 and multi-agent debate

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

Harnesses and agent engineering

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. Documentation
18. OpenAI. Safety in building agents. Documentation
19. LangChain. LangGraph — Send. Documentation