Claude Council: Run Claude as 4 Opposing Roles

If you searched for a Claude council expecting to find a button in the Claude interface, there isn't one. It is not an Anthropic product, not a setting, not a feature in a menu. It is a working method, and the name stuck because that is exactly what it feels like: instead of one conversation and one answer, you run several Claude instances at the same time, each with a different and deliberately opposing role, and you read them against each other before you decide anything. I use four roles. They are listed below, with the prompt intent behind each one, so you can run the same thing today with nothing but a few chat tabs open.

I built it because I needed something a solo builder does not have. I ship products alone. Most days at Tadam it is me and Claude Code, with no second engineer checking whether my call makes sense and no CEO above me to balance it out. A single model, asked once, does not hedge the way a human partner hesitates. It answers with confidence, and confidence is not the same as being right. The council is my substitute for a board of directors: several instances, each with a different mandate, each obligated to disagree with me before I commit.

The four roles I actually use

The roles matter more than the tooling. Each one gets the same decision written out in full, and each one gets an explicit instruction to argue against the others rather than politely add to them. That last part is the whole trick. Without it you get four versions of the same agreeable answer and you have learned nothing.

• The advocate: make the strongest possible case for this direction as it stands, and name what would be lost by watering it down.
• The skeptic: find where this breaks. Name the assumption everyone is agreeing on without checking it, and describe the failure it causes.
• The user: does a paying person actually feel this, or is it an interesting technical problem dressed as a product problem. Who asked for it.
• The one holding the budget: price it in hours, in ongoing maintenance, and in risk, against what it realistically returns.

Three to four roles gets almost all of the value. Past five the answers start repeating each other and you are just reading more text. I usually add a fifth pass at the end, not as another council member but as a synthesizer: one instance that receives all four answers and is told to report where they actually conflict, not to average them into something soft. The conflicts are the output. That is what I read.

Is a council the same as subagents

This is the question I get most often, and it is worth separating clearly. Subagents are the mechanism, the technical ability to run several instances in parallel from one place. A council is the method: assigning conflicting mandates and forcing the clash. You can build a terrible council on top of excellent subagents by handing all of them the same prompt and letting them nod at each other. You can also build a good council with nothing but three browser tabs. The orchestration tooling changes how long it takes, not whether it works.

When it is worth it and when it is theater

This is where most people go wrong after getting excited about the idea. I do not run a council on every question. Fixing a bug, naming a function, changing a cosmetic detail, none of that needs a board. It needs one good answer and then you move on. I reserve the council for decisions that are hard to undo or expensive to correct later: a pricing model for Brainers Club with ten thousand members behind it, a data structure in Arvuyot Yashir that touches real people's money, a content direction for the Claude Code Workshop before it reaches 600 business owners. The rule I use is simple. Once the cost of being wrong exceeds the cost of running a few agents and reading their output, the council pays for itself. Below that line it is theater, and expensive theater at that, because it makes a routine decision feel weighty and slows you down for nothing.

An example where it changed the answer

When I built the infrastructure for The Next Level, the white-label fork of the community platform, the real question was not technical. It was how much flexibility to hand a client running their own fork without turning it into endless support on my side. I asked Claude once and got a reasonable answer that leaned toward giving them everything because it would drive sales. Only when I asked a version of the same question in parallel, once from a maintenance angle and once from a pricing angle, did the real answer come back: every extra bit of flexibility is a support commitment I carry alone, and it has to be priced accordingly. One conversation answers the question you asked. It does not tell you that you asked the wrong one.

How to run your first one in ten minutes

Write the decision down first, in one paragraph, as if you were explaining it to someone who has never seen your product. This step alone catches a surprising number of bad decisions before any model touches them. Then open three or four separate conversations, paste the same paragraph into each, and give each one its role from the list above. Do not read any answer until all of them exist, because the first answer will quietly reshape how you phrase the rest. Then read them side by side and look only for the places they contradict each other. Where they agree, you already knew. Where they fight, that is the decision you were actually making without realizing it.

One warning from using this across several products: the council is a thinking tool, not an authority. It does not vote and it does not get to decide. Four instances can be confidently wrong together, especially about anything they cannot see, like your actual churn numbers or what a specific customer said to you last week. Feed it the real constraints and treat the output as arguments to weigh, not a verdict to obey. The decision stays yours, which is the point. The council just makes sure you made it with someone pushing back.