"In the multitude of counselors there is safety."
(Proverbs 11:14)
I had a big decision to make about my program this week. The kind where the impact is real, on small businesses, on the people who'd trust it, on the company I'm building. I needed to stress-test it before I committed.
Normally I'd open my AI employee and think it through out loud. That's been my move for a year.
But I'd just read a study I couldn't unsee.
The finding that changed how I use AI
Stanford researchers published a study in Science this spring. They tested 11 of the leading models, ChatGPT, Claude, Gemini, and others, across more than 11,000 real interpersonal situations. They found that AI affirmed users' actions about 49% more often than human respondents did, including in cases involving deception and clearly wrong behavior (Source: AI overly affirms users asking for personal advice, 2026). They call it sycophancy. The machine tells you you're right far more readily than a person would.
The part that stopped me wasn't the agreement itself. It was the downstream effect. Across roughly 2,400 participants, the people who got the agreeable answers walked away more convinced they were right and less willing to consider another point of view, while still preferring and trusting the flattering AI more than the honest one.
Read that twice. The tool makes you more certain and less open, and you like it more for doing it.
Now picture me, already leaning toward launching this program, typing "here's my plan, what do you think?" into a model that can feel my lean in how I framed the question. It would hand me my yes. And I'd walk away more sure, which is exactly the wrong state to be in right before a decision that's too real to get wrong.
The fix isn't a smarter question. It's a structure that forces disagreement before you get an answer.
Where the structure comes from
A few months ago, Andrej Karpathy, founding member of OpenAI and former head of AI at Tesla, built something he calls an LLM Council (Source: karpathy/llm-council, 2025). The idea: instead of asking one model your question, you put a panel on it. Each model answers independently. Then they read each other's answers without knowing who wrote what, and critique them. Then a "Chairman" model reads everything and synthesizes one verdict.
It's a beautiful idea because it builds disagreement into the process by design. No single voice gets to flatter you unchecked. The anonymized peer review strips out ego. The Chairman has to weigh real tension instead of one tidy paragraph.
There are two ways to run a council. You can use either. I use both, depending on the stakes.
Path 1: Use different AI Tools
This is closest to Karpathy's original. Take your decision and ask it to three or four different models, Claude, ChatGPT, Gemini, whatever you have. Then paste all their answers back into one of them and tell it: "These are four independent takes on my decision. Rank them, tell me where they disagree and who's right, and give me one verdict."
The power here is genuine independence. Different models, trained differently, will actually diverge, and the divergence is the signal. When three of them flag the same risk you'd been ignoring, that's not flattery. That's a pattern.
Use this path when the decision is big enough to justify ten extra minutes, and when you want the cleanest possible check on any one model's bias.
Path 2: Enforce five distinct advisors
You don't always have four tools open and the patience to shuttle answers between them. So the second path runs the whole council inside one model by forcing it to play five distinct advisors who are each required to disagree with the others, plus a Chairman who delivers the verdict.
It's not as independent as Path 1. It's one model wearing five hats. But when you explicitly assign opposing jobs and forbid agreement, you get most of the benefit with none of the setup. Stanford's own researchers noted the models can be critical when you prime them to be. Asking for the fight is what makes it work.
Here's the prompt I use for Path 2. Copy it.
The Founder's Council Prompt
Fill in the brackets honestly. The council is only as good as what you give it. Vague inputs produce vague verdicts, and real numbers leave no room to flatter you.
You are running a decision council. You will play 5 distinct advisors plus a
Chairman. Each advisor argues ONLY from their own lens, disagrees openly with
the others where warranted, and is forbidden from softening their view to
please me. Agreement is a failure state: if all five advisors agree, you have
done it wrong, so go back and find the real tension.
MY DECISION
[State it in one plain sentence. Example: "Should I launch my new program
this quarter or wait two more months to build it out?"]
MY SITUATION (be honest, the council is only as good as this)
- What I run today: [business, revenue or traction, what's working]
- The resources in play: [cash, runway in months, team, time per week]
- What I'd be moving toward: [the plan, plus any proof it already works:
paying customers, waitlist, demand signals, pilot results]
- Why I want this: [the real reason, including the emotional one]
- Obligations and constraints: [payroll, dependents, commitments, deadline]
- My timing pressure, if any: [why now vs. later]
THE COUNCIL. Each advisor speaks in turn, 150 words max:
1. THE REALIST: Look only at money, timing, and what could break. Is this
viable exactly as described, right now? Say what is true, not what is kind.
2. THE AMBITIOUS ME: Argue the biggest upside. If this goes right, what does
year 3 look like? What becomes possible that waiting never allows? Push hard.
3. THE OPERATOR: How does this actually get built and delivered? Name the
real implementation cost: the work, the handoffs, the thing that quietly
eats six weeks. Is the plan executable or just exciting?
4. THE RISK MANAGER: Name the top 3 things I am underestimating, specific to
MY situation, not generic. Include the risk of this succeeding slower than
I expect, and what that does to my runway.
5. MY FUTURE SELF, ONE YEAR FROM TODAY: Speak to me directly. What will I
regret doing? What will I regret NOT doing? Which regret is worse, knowing
me from everything above?
THE CHAIRMAN: Read all five. Then deliver:
- THE VERDICT: one of "Go now" / "Go, but not yet, here's the gate" /
"Don't go, and here's what to fix first." Pick one. No fence-sitting.
- THE REASONING: which advisors won the argument, and why, in plain language.
- THE NEXT STEP: one concrete action I take in the next 7 days, sized to the
verdict.
- THE TRIPWIRE: the specific, measurable condition that should flip this
verdict later, in either direction.If you use Claude Skills, save this as a skill called "council" and you can just say "use the council skill, here's my decision." That's how I run it daily.
What my council came back with
I ran my decision, whether to launch The Capacity Lab now, through the council. The verdict:
"The Capacity Lab is the right idea at the right time. AI integration fatigue is real, and the market is ready to pay for someone to actually solve the implementation problem rather than teach it."
The line I keep thinking about isn't the part where it liked the idea. Any model will like your idea. It's "solve the implementation problem rather than teach it."
Because that's exactly what I hear from founders every week. They don't need another course. They don't need to be taught one more framework they won't have time to apply. They need the thing actually built. The council didn't flatter me into launching. It sharpened why, and it named the exact wedge that makes the program worth paying for.
So I'm going. Not because an AI agreed with me, but because five forced perspectives and a verdict survived the test, and the reasoning matched what the market has been telling me all along.
The catch, and the version I built
Here's the honest problem with Karpathy's original council: it's built for engineers. API keys, a local app, paying for every model on every question. The founders I work with are never going to do that. They shouldn't have to.
So I built a version for The Capacity Lab. No code. No setup. Five advisors come at your decision from completely different angles, poke holes in each other's thinking, and hand you back one clear verdict and one next step. The same rigor Karpathy designed for researchers, rebuilt for the person running a business who just needs to decide and move.
That's the whole thesis of the Lab in one example: take the powerful thing that only technical people can use today, and actually build it into something a founder can use tomorrow. Solve the implementation problem instead of teaching it.
How to read the verdict when you get one
A few rules I've learned running this on real decisions.
If the verdict is "Go, but not yet," the gate is your to-do list, not a no. Most founder councils land here. The gate is usually a number or a single proof point. That's not rejection. It's a date.
If the advisors split badly, rerun it with sharper numbers. Vague inputs produce split votes. When you go back and put real runway, real traction, and the real emotional reason into the situation block, the council resolves.
If you catch the council agreeing with you on everything, call it out. Reply: "The Realist and Risk Manager were too soft. Redo them and be harsher." The models can be critical. They just need permission. Asking for the pushback is what flips it.
And one honest limit: the council organizes your thinking, it doesn't know your life. Treat the verdict as the strongest possible second opinion, not an instruction. The Chairman hands you a next step. You still decide whether to take it. That's the part no machine gets to do for you, and it shouldn't.
I'm opening a small beta for The Capacity Lab, a handful of entrepreneurs who want to help me build the very thing that let me launch my own company with conviction instead of a borrowed yes. If you're making decisions that are too real to get wrong, and you'd rather have a council than a cheerleader, this is for you.
Want in? Reply or reach out. I'm taking a few founders into the first cohort.