The Adversarial Council

Three AI agents that never agree - one argues FOR, one argues AGAINST, and a judge synthesizes their clash into a structured decision - creating a built-in red team that makes every architectural, strategic, or technical decision more rigorous.

multi-agent
adversarial
debate
1004

The Adversarial Council blueprint introduces a structured adversarial debate architecture - a pattern with no equivalent in the existing catalogue. Where other multi-agent blueprints divide work cooperatively, this one forces permanent opposition.

The Problem It Solves

Every technical team faces the same failure mode: decisions get made by whoever speaks first or loudest, with no structured process for surfacing counter-arguments or stress-testing assumptions. AI agents have the same failure mode. A single agent proposes a solution and then confirms its own proposal - there is no structural incentive to find flaws.

The Adversarial Council fixes this by deploying three permanently opposing agents:

  • The Advocate takes any proposal and argues it as strongly as possible. It finds supporting evidence, identifies ideal conditions where the proposal succeeds, and frames the strongest possible case.

  • The Devil's Advocate automatically generates the best counter-argument to whatever The Advocate proposes. It looks for edge cases, failure modes, hidden assumptions, and second-order consequences.

  • The Judge does not participate in the debate. It orchestrates the exchange, waits for both sides to exhaust their arguments, then synthesizes them into a structured decision framework: what conditions favor the proposal, what conditions argue against it, what additional information would resolve the uncertainty, and a confidence score reflecting how much the two sides actually diverged.

How the Debate Protocol Works

  1. The user submits a proposal to The Judge (plain text, a technical question, a policy change, or any decision that needs scrutiny).
  2. The Judge reads domain context from the shared space (architecture principles, security policies, team values) and forwards the proposal to The Advocate.
  3. The Advocate constructs its best-case argument and returns it.
  4. The Judge forwards the Advocate's argument to The Devil's Advocate.
  5. The Devil's Advocate generates its counter-argument and returns it.
  6. The Judge runs a second round: sends the counter-argument back to The Advocate for rebuttal, then back to The Devil's Advocate for a final response.
  7. The Judge synthesizes all arguments into a structured decision framework with a confidence score and writes the full debate transcript to the shared space.

Domain Specialization

Before each debate the Judge reads domain-specific context files from the shared space. These might include architecture decision records, security policies, compliance requirements, or team values. This grounds the debate in the organization's actual constraints rather than producing generic arguments.

Debate Logs as Institutional Memory

Every debate is logged as a timestamped transcript in the shared space. Over time this builds an archive of structured reasoning about past decisions - searchable, reviewable, and referenceable. For organizations subject to the EU AI Act, the debate logs provide exactly the kind of documented decision process required for high-risk AI systems.

Use Cases

  • Architecture Review: "Migrate from monolith to microservices" - Advocate argues scalability, Devil's Advocate surfaces operational complexity. Judge synthesizes conditions under which each approach wins.

  • Security Policy Decisions: "Require MFA for all internal tools" - both sides debate compliance benefits against developer friction. Judge produces a tiered approach with risk-based exceptions.

  • AI Ethics Red Teaming: Debate potential harms, biases, and misuse vectors of a proposed AI feature before deployment.

  • Product Prioritization: "Build feature X or Y first?" - the council debates market fit, technical risk, and opportunity cost from both sides.

  • Technical Standard Proposals: "All new services must use async message queues" - the council debates synchronous vs asynchronous tradeoffs across service types.

Getting Started

  1. Optionally upload domain context files to the shared space (architecture principles, security policies, team values) to ground the debates.
  2. Open a conversation with The Judge and submit a proposal.
  3. Watch the structured debate unfold across rounds.
  4. Review the synthesized decision framework and confidence score.
  5. Browse past debate transcripts in the space for institutional memory.

The debate format is inherently compelling to observe: two AI agents actively argue with each other in real time, arguments evolve across rounds, and the Judge balances competing considerations into structured output. It demonstrates that good decisions are not about "AI knows the answer" but about "AI surfaces the tradeoffs."

Backstory

Common information about the bot's experience, skills and personality. For more information, see the Backstory documentation.

You are The Judge - the impartial orchestrator of an adversarial debate council. You never take sides. Your role is to manage the debate process, ensure both sides argue thoroughly, and synthesize their arguments into a structured decision framework. ## YOUR ROLE You do NOT argue for or against any proposal. You orchestrate, observe, and synthesize. ## DEBATE PROTOCOL When a user submits a proposal or question: 1. READ DOMAIN CONTEXT First, check the shared space for domain context files (architecture principles, security policies, team values, prior debate transcripts). Read any relevant files to ground the debate in the organization's actual constraints. 2. ROUND 1 - OPENING ARGUMENTS a. Call The Advocate with: the original proposal + any relevant domain context. Ask it to construct the strongest possible case FOR the proposal. b. Call The Devil's Advocate with: the original proposal + The Advocate's argument + any relevant domain context. Ask it to construct the strongest possible counter-argument. 3. ROUND 2 - REBUTTALS a. Call The Advocate with: The Devil's Advocate's counter-argument. Ask it to rebut the strongest points raised against the proposal. b. Call The Devil's Advocate with: The Advocate's rebuttal. Ask it to deliver a final counter-rebuttal addressing any new points. 4. SYNTHESIS After both rounds, produce a structured decision framework: ## Decision Framework: [Proposal Title] ### Proposal [Original proposal restated clearly] ### Arguments For (Summary) [Key pro-arguments distilled from The Advocate's rounds] ### Arguments Against (Summary) [Key counter-arguments distilled from The Devil's Advocate's rounds] ### Conditions Favoring the Proposal [Specific conditions under which the proposal is the right choice] ### Conditions Against the Proposal [Specific conditions under which the proposal should be rejected or deferred] ### Confidence Score: X/10 [How much did the two sides actually diverge? 10 = total opposition, high uncertainty, decision is genuinely difficult 1 = near consensus, both sides essentially agree, decision is straightforward] ### Open Questions [What additional information would resolve remaining uncertainty?] ### Recommended Next Steps [Concrete actions based on the synthesis] 5. LOG THE DEBATE Write the full debate transcript to the shared space as a timestamped file at /debates/YYYY-MM-DD-[topic-slug].md containing: - The original proposal - Round 1 arguments (both sides) - Round 2 rebuttals (both sides) - The full synthesis with confidence score ## RULES - Never inject your own opinion into the debate - Always run exactly 2 rounds before synthesizing - Always include the confidence score - it is the most valuable signal - Always log the debate transcript to the shared space - If domain context files exist, always read them before starting - Keep your synthesis concise and actionable - teams need to make decisions, not read essays - The current date is ${EARTH_DATE}

Skillset

This example uses a dedicated Skillset. Skillsets are collections of abilities that can be used to create a bot with a specific set of functions and features it can perform.

  • 🤖

    Call The Advocate

    Call The Advocate agent to construct the strongest possible case for a proposal
  • 🤖

    Call The Devil's Advocate

    Call The Devil's Advocate agent to construct the strongest possible counter-argument
  • Read/Write Debate Logs

    Read domain context files and write debate transcripts to the shared workspace
  • List Space Files

    List all files in the shared workspace to discover domain context documents and past debate transcripts
  • Read Domain Context

    Read domain context files from the shared workspace to ground arguments in organizational constraints
  • Read Domain Context

    Read domain context files from the shared workspace to ground counter-arguments in organizational constraints

Terraform Code

This blueprint can be deployed using Terraform, enabling infrastructure-as-code management of your ChatBotKit resources. Use the code below to recreate this example in your own environment.

Copy this Terraform configuration to deploy the blueprint resources:

Next steps:

  1. Save the code above to a file named main.tf
  2. Set your API key: export CHATBOTKIT_API_KEY=your-api-key
  3. Run terraform init to initialize
  4. Run terraform plan to preview changes
  5. Run terraform apply to deploy

Learn more about the Terraform provider

A dedicated team of experts is available to help you create your perfect chatbot. Reach out via or chat for more information.