Claude Council: How I Turned Claude Into an Advisory Board Instead of a Single Assistant

A Claude council isn't an Anthropic product or a menu feature. It's a working method I built for myself after noticing how often I'd ask Claude a question, get a convincing answer, and implement it with nobody around to say "wait, did you check this from another angle?" The idea is simple: instead of opening one conversation and getting one answer, I run several Claude instances in parallel, each with a distinct and sometimes opposing role, and let them argue before I decide. It's not a prompt trick. It's how I compensate for not having a cofounder or a board that pushes back before a big call.

Why I ended up here

I build products solo. Most days at Tadam it's me and Claude Code, no second engineer sanity-checking my calls and no CEO above balancing me out. At the same time I mentor founders at nCode and see the same pattern with 600 students and business owners at the Claude Code Workshop: one person at a screen, one answer from an AI, a decision made on top of it. The problem isn't that the answer is bad. The problem is that a single language model, asked once, doesn't hedge the way a human partner would. It just answers with confidence. So I built myself a substitute for a board of directors: several Claude instances, each with a different mandate, obligated to disagree with me before I decide.

What it looks like in practice

It's not just writing "pretend you're an expert in X" in one prompt. It's a parallel run of several agents, each with a defined role, usually with an explicit instruction to try to refute what the others say rather than simply agree. I reach for it when the decision is expensive or hard to reverse, not for a routine bug. The simplest form: I write out the decision, send it to several distinct roles at once, and read the answers against each other before anyone synthesizes a conclusion for me.

• The advocate: what's strongest about this direction, and why it's worth running with as-is
• The skeptic: where does this break, what's the false assumption everyone's agreeing on without checking
• The user: does this actually solve a real problem for someone paying, not just an interesting technical problem
• The one holding the budget: what this costs in time, maintenance, and risk, against what it returns

When it's worth the time, and when it's waste

I don't run a council on every question, and that's exactly what most people miss when they get excited about the idea. Fixing a bug, phrasing a function, a cosmetic change, none of that needs a board, it needs one good answer and moving on. I reserve a Claude council for decisions that are hard to undo or expensive to fix later: a pricing model for Brainers Club with ten thousand members, a data structure in Arvuyot Yashir that touches real people's money, or a content direction for the Claude Code Workshop before it goes out to 600 business owners. Once the cost of a wrong call exceeds the time it takes to run a few agents, the council pays for itself. Below that, it's just theater.

An example from the field

When I was building the infrastructure for The Next Level, the white-label fork of the community platform, the real question wasn't technical, it was business: how much flexibility to give a client running their own fork without it turning into endless support on my end. I asked Claude once and got a reasonable answer that leaned toward "give them everything, it'll drive sales." Only when I asked a version of the same question in parallel from a maintenance angle and a pricing angle did I get back what actually mattered: every extra bit of flexibility is a support commitment I carry alone, and it needs to be priced accordingly. That's not an insight one conversation would have surfaced, because one conversation tends to answer the question you asked, not the question you should have asked.