Five advisors. One decision.
No flattery.
Ask a single AI assistant whether your plan is good and it will find reasons it is. The Council is built on the opposite premise — five adversarial AI advisors with distinct mandates interrogate the same question independently, with no knowledge of each other's answers, followed by three peer reviewers who stress-test the quality of the advice itself, followed by a Chairman who delivers the one thing a polite AI never does: a declared verdict.
What this project is — and what it demonstrates
What it demonstrates
Multi-agent orchestration across 9 sequential API calls. Structured prompt engineering as an architectural pattern. Complex async state management in vanilla JavaScript. Phase-gated rate limit management. Client-side document intelligence — all without a backend, a framework, or a build step.
What it delivers
A structured deliberation that takes any consequential business decision from question to declared verdict — with an action plan, kill risks, and a review trigger — in under 12 minutes. Any document type. Any decision domain.
This was built as a skills project — to understand what is possible with structured multi-agent orchestration using only a browser, vanilla JavaScript, and the Anthropic API. It is complete. It works. Improvements are planned. The architecture document is as interesting as the application.
12 API calls per full session · 5 advisors · 5 reviewers · 1 Chairman · Zero backend · Single HTML file
The problem The Council solves
AI assistants are agreeable by design. That is the problem.
The six most common decision-making failures are not solved by getting more information. They are solved by getting adversarial challenge from structurally different perspectives. The Council's architecture is a direct response to each one — not a feature list, a set of structural constraints built into the system.
Confirmation bias
"Seeking input from people who already agree"
The Contrarian exists specifically to find every reason this fails — regardless of how compelling the idea sounds.
The politeness problem
"Real views softened to avoid conflict"
Advisors have no relationship with the user. The Contrarian has no social incentive to soften. The architecture removes the social cost of honesty.
Blind spots
"No single advisor sees every dimension"
Five advisors with structurally different mandates. The Outsider sees what experts miss. The Executor sees what theorists miss.
Groupthink
"Advisors who know each other's views converge"
Advisors receive no knowledge of each other's responses. The Stress-Test phase anonymises and shuffles before reviewers read them.
Curse of expertise
"Domain experts miss what is obvious to outsiders"
The Outsider has zero prior context by design. Reads everything as a smart stranger encountering it for the first time.
Speed pressure
"Proper deliberation skipped under time pressure"
The 65-second cooldowns between phases are mandatory and visible. The architecture enforces deliberation time — it cannot be skipped.
How it works — three phases
Five advisors. Five reviewers. One Chairman. In that order. Always.
The architecture is sequential and gated. Phase I must complete before Phase II starts. A 65-second cooldown separates each phase — not a UX choice but an engineering requirement: the Anthropic API enforces a 30,000 input token per minute limit. The cooldown gives each phase a fresh window. This is visible to the user as a countdown with a progress bar, not an opaque wait.
Pre-Phase · 1 API call · max_tokens: 3,000
Document Intelligence — Council Briefing
Before any advisor deliberates, a dedicated API call reads all uploaded documents and extracts a structured briefing across twelve mandatory sections. The briefing — not the raw documents — is what every advisor receives. This solves the token limit problem while ensuring all material information is available to the full council.
12 mandatory briefing sections
Absent sections marked "Nothing disclosed" — never silently skipped.
Phase I · 5 API calls · max_tokens: 750 per advisor
The Five Advisors
Five AI advisors with adversarial mandates deliberate independently and sequentially. Each receives the question and the Council Briefing. No advisor knows what the others said. Each returns Key Points, a Stance (Bearish → Bullish), a Vote (STOP → ACCELERATE), a six-word signal phrase, and a full analysis. After all five complete: the Stance Heatmap renders — every advisor's position in one visual, readable in ten seconds.
The Contrarian
STOP / PAUSEFinds every reason this could fail. Exposes assumptions, risks, and ways this goes badly wrong. Does not soften.
The First Principles Thinker
RECONSIDERStrips all received wisdom. Rebuilds from the ground up. Asks whether this is even the right question.
The Expansionist
PROCEED / ACCELERATEFinds the upside being missed. Identifies adjacent opportunities and undervalued potential.
The Outsider
RECONSIDER / PROCEEDZero prior context. Reads everything as a smart stranger encountering it for the first time. Catches the curse of knowledge.
The Executor
PROCEED / PAUSEOne question only: what do you actually do next? Exposes the gap between compelling idea and workable execution plan.
Phase II · 5 API calls · max_tokens: 550 per reviewer
Council Stress-Test
Three peer reviewers read all five advisor responses — anonymised and shuffled, so no reviewer knows which advisor said what. Reviewers receive no documents and no briefing — only the anonymised advisor responses and the question. This is intentional: Phase II evaluates reasoning quality, not source material. The phase tests the advisors, not the decision.
The Fact-Checker
SOLID / SHAKY / FLAWEDInterrogates reasoning quality. Where was logic lazy? Where were claims made without evidence?
The Integrator
CONVERGENT / SPLIT / DIVERGENTReads all five responses as a whole. What pattern emerges? What does the collective picture say that no individual advisor said?
The Devil's Advocate
MINOR GAP / SIGNIFICANT GAP / CRITICAL OMISSIONIdentifies the important argument that NO advisor made — the genuine collective blind spot. Makes the argument, not just points at the gap.
The Risk Ranker
LOW / MEDIUM / HIGH / CRITICALTakes every risk raised by every advisor and ranks by severity: likelihood × impact. What is the single risk most likely to kill this?
The Opportunity Scout
MINOR / NOTABLE / SIGNIFICANTFinds the upside the council collectively underweighted or ignored. Even bearish councils miss positive signal.
Phase III · 1 API call · max_tokens: 1,400
The Chairman's Decision
The Chairman receives everything: the question, the Council Briefing, all five advisor responses, all five stress-test results. The Chairman's output is not a summary. It is a declared decision — the one output AI assistants are trained to avoid giving.
Declared verdict
GO / NO-GO / CONDITIONAL GO — a single declared position, not a balanced summary
Conditions to proceed
If CONDITIONAL GO: specific, numbered conditions that must be met before proceeding
Action plan
5–7 prioritised next actions — sequenced, specific, actionable
Kill risks
The top 3 risks most likely to cause failure — with early warning signals for each
Review trigger
The specific event that should bring the Council back together — not a date, an event
Round II (optional)
All five advisors respond to the Chairman's verdict. Chairman delivers a Final Word.
Zero-backend architecture
No server. No database. No framework. No build step. One HTML file.
Every architectural decision was made to eliminate infrastructure overhead during the skills phase — while keeping the transition to a commercial hosted application a known, planned step rather than a rebuild. When user accounts, session history, and payment processing are required, four components change. Everything else carries forward.
Why single-file HTML over Next.js
No server to provision, no CI/CD pipeline, no backend to secure, no database to back up. The entire application ships as one `.html` file that opens in any browser. For a product in active development, this eliminates an entire category of operational overhead. React would add a build step, component lifecycle, and virtual DOM diffing for no functional benefit in a sequential async flow.
Why vanilla JavaScript over any framework
The application has a linear, phase-gated execution model. Phase I completes, then Phase II, then Phase III. This is a sequential async flow, not a reactive component tree. Vanilla async/await with direct DOM manipulation is the simplest correct tool. There are no shared state subscriptions, no component re-renders, no virtual DOM diffing needed. The entire state model is one `S{}` object mutated in-place.
Why named-section prompt engineering over JSON mode
JSON mode is brittle for long-form prose — advisors must return a mix of bullets and paragraphs. Named sections (`KEY POINTS:`, `STANCE:`, `ANALYSIS:`) serve as regex anchors: `/SECTION:\s*\n([\s\S]+?)(?=NEXT_SECTION:|$)/i`. The parse layer is deterministic — a regex match either succeeds or falls back to raw text. A malformed response does not crash the session.
Why BYOK (Bring Your Own Key) over a managed backend key
BYOK eliminates the need for a payments and auth system during the skills phase. Users pay Anthropic directly. No key storage liability on CenturionAI's side. The trade-off — key visible in browser network dev tools during API calls — is disclosed and acceptable during beta. The commercial launch replaces BYOK with a backend API key proxy and PayFast billing.
Full execution flow — per session
Browser Input
Question + documents + API key (DOM only)
buildCouncilBriefing()
×1 call · 3,000 tokens12-section structured extraction from all documents
Phase I — 5 Advisors (sequential)
×5 calls · 750 tokens eachPhase II — 5 Reviewers (anonymised)
×5 calls · 550 tokens eachPhase III — Chairman
×1 call · 1,400 tokensGO / NO-GO / CONDITIONAL GO · Action Plan · Kill Risks · Review Trigger
Round II (optional)
×5 advisors + ×1 Chairman
Follow-ups (optional)
×1 per question · single or broadcast
Export: S{} → Markdown (.md)
Full decision record · human-readable · version-controllable
Why Claude Sonnet 4 — and not the alternatives
GPT-4o
Lower format adherence — more prone to adding preamble before structured sections. PDF handling requires separate preprocessing.
Claude Haiku
Insufficient instruction following for complex multi-section structured outputs. Suitable for simple classification, not adversarial reasoning.
Claude Opus 4
4–6× more expensive with no meaningful quality improvement for structured advisory outputs at this token length.
Gemini 1.5 Pro
Direct browser API access is more restricted. Lower structured output fidelity in testing.
Claude Sonnet 4
Best structured output adherence at mid-tier price point. Native PDF document input. Strong multi-section format enforcement. The right tool.
What building this taught
The engineering problems that made this interesting.
The five problems below are not in the product document. They are in the architecture document — and they are the reason the architecture document is worth reading. Each one required a design decision that is non-obvious until you have encountered the failure it was built to prevent.
Rate limit management without a backend
The failure
The first version silently failed partway through Phase II. The Anthropic API's 30,000 input token per minute limit was being exhausted by Phase I's five sequential calls — leaving the next phase with no available window.
The solution
Phase-gated 65-second cooldowns between Phase I→II and Phase II→III. Each cooldown guarantees a fresh 60-second token window with a 5-second buffer. Per-call delays do not reset the window. A backend queue would work but adds infrastructure not warranted here. `const COOLDOWN_SECS = 65` — adjustable for higher API tiers.
Why this approach
Phase cooldowns guarantee a clean window per phase. No server required.
Structured output from 9 sequential API calls
The failure
Each advisor, reviewer, and the Chairman must return responses in exact, parseable formats. Any deviation — preamble before sections, section headers misspelled, sections reordered — degrades the parse layer and produces broken UI cards.
The solution
Named-section prompt engineering as an architectural pattern. Every system prompt enforces exact section labels (`KEY POINTS:`, `STANCE:`, `ANALYSIS:`, `VERDICT:`). Parser uses anchored regex: `/SECTION:\s*\n([\s\S]+?)(?=NEXT_SECTION:|$)/i`. Graceful degradation: missing sections render raw text. Per-advisor retry: on first failure, 15-second wait, one retry, then `renderAdvisorFailed()` — session continues regardless.
Why this approach
Named sections are robust to minor model deviations. JSON mode is brittle for long-form prose.
Document intelligence without token bloat
The failure
Sending raw uploaded documents (PDF, DOCX, TXT) to all 11 downstream calls would multiply token cost 11×. On a large business plan, this would either exceed context limits or cost R30+ per session in API fees alone.
The solution
One pre-session briefing call extracts a 12-section structured brief from all documents. All downstream calls receive the brief text — not the raw documents. Token cost per session becomes predictable regardless of document volume. The brief itself is visible to the user as a collapsible section for verification before the Council deliberates.
Why this approach
One briefing call normalises token usage. The brief is what every advisor actually needs.
Preventing reviewer bias toward known advisors
The failure
Early testing of Phase II revealed that reviewers were deferring to "the analyst" or "the strategist" when they could identify which advisor had written which response — producing evaluations of the advisor's reputation rather than the quality of their reasoning.
The solution
Advisor responses are anonymised (names and role labels removed) and shuffled before being passed to Phase II reviewers. The shuffle is seeded per session, not fixed — reviewers see Advisors A–E in a different order each time. Reviewers receive no documents and no briefing, only the anonymised responses and the question.
Why this approach
Reviewers must evaluate reasoning quality, not source identity.
Session state across 14+ API calls without a database
The failure
A full session with Round II and follow-ups makes 20+ sequential API calls across three phases, an optional feedback loop, and follow-up questions. State must accumulate cleanly across all of them without a backend to persist or coordinate.
The solution
A single global `S{}` object accumulates results phase by phase, mutated in-place throughout the session. The export function reads this object directly and produces a complete Markdown record. Session state is intentionally ephemeral — tab close clears everything. `resetCouncil()` sets all fields to empty initial values. No residual session data. No POPIA liability from accidental retention.
Why this approach
Linear sequential state does not need a reactive model. One object, one source of truth.
Tech stack
What it is built on.
Architecture
Single self-contained HTML file — zero backend, zero build step, zero node_modules
JavaScript
Vanilla ES2022+ — async/await, native DOM manipulation, no framework
AI model
Anthropic Claude claude-sonnet-5-5 — direct browser API calls via fetch()
Document parsing
Mammoth.js 1.6.0 (cdnjs CDN) — client-side DOCX → plain text extraction
File handling
Native browser FileReader API — PDF as base64, DOCX as ArrayBuffer, TXT/MD/CSV as plain text
Typography
Google Fonts CDN — Cinzel (authority), EB Garamond (editorial depth), DM Mono (technical precision)
State management
Single S{} in-memory object — no persistence, no localStorage, tab close = data destruction
Output format
Named-section prompt engineering + regex parsing — robust to minor model deviations
Export
Browser Blob + URL.createObjectURL — full session exported as Markdown (.md) download
Authentication
User-supplied API key (BYOK) — DOM input only, never persisted, cleared on tab close
Rate limiting
65-second phase cooldowns — mandatory between Phase I→II and Phase II→III
Deployment
Single .html file — local, any static host, CDN, or embedded in a web app
What comes next
Complete as a skills project. The commercial path is clear.
Four known development steps separate the current standalone HTML application from a commercial product. The architecture decisions made during the skills phase were made with this transition in mind — nothing about moving to a hosted web application requires rewriting the core session logic, the prompt engineering, or the parse layer.
Web deployment
Move from standalone HTML file to a hosted web application with URL, user accounts, and session history. Supabase for auth and PostgreSQL session storage. pgvector for semantic search over past Council sessions.
Commercial pricing layer
PayFast integration, session credits, and subscription tiers. The underlying API cost per full session is approximately USD $0.10–$0.25 at Claude Sonnet 4 pricing. Significant margin at R99–R199 per session.
SA regulatory context packs
Pre-loaded briefing context for specific South African sectors — financial services, property, retail, healthcare — including relevant regulatory landscape, common failure modes, and sector-specific risk frameworks.
Team and collaborative mode
Multiple users contributing to and reviewing the same Council session. Shareable session links. Useful for investor groups, founding teams, and strategy consultants presenting to clients.
Have a decision that deserves more than a gut call?
The Council is open.
Bring your question.
Business decisions. Investment decisions. Strategic decisions. Partnership decisions. Market entry decisions. Any consequential, irreversible, or expensive decision that deserves real challenge before you commit.
What you need to use it
When to use The Council