Building a Team to Think With
Notes on a Deliberation Practice
Author’s Note: The current version of my deliberation framework is shared in full below.
Treat it as a working snapshot rather than a finished product. It reflects what’s helping me think better right now, and it will continue to evolve. Happy to share a repo link for anyone who is interested.
This post accompanies the deliberation template itself. It’s not a walkthrough, and it isn’t meant to justify every choice. The template is a working artifact. The purpose of this essay is to explain how I think about using it, and what I’ve learned by doing so.
If the previous essay was about why I needed a deliberation model, this one is about how I relate to it in practice.
The template is not the point
The most important thing to understand is that the template isn’t the work. It’s scaffolding.
Each section exists because it solved a real problem in a previous run. If your problem doesn’t have that problem, you can skip or compress the section. The structure is meant to remind you of things you’d otherwise forget, not to make you fill in boxes.
This is why there are multiple versions of the template. I treat each deliberation as a run, and each run as data. Versions change because something broke, surfaced too late, or created unnecessary confidence.
Nothing here is theoretical. It’s all accreted.
Start with framing, or don’t start at all
Most failures I’ve seen using this model come from under‑investing in the framing.
If there isn’t a clear problem statement, real constraints, and at least one open question, the rest of the process produces confident‑sounding analysis of nothing. That’s why there’s a quality gate at the beginning.
This isn’t discipline for its own sake. It’s protection against the model’s most obvious failure mode. Agents will always respond to whatever they’re given. The hardest part of the work has already begun before anyone else gets involved.
Choose hats based on the question, not habit
One of the most common instincts is to reuse the same set of reasoning roles every time. I avoid that.
The hats are not personalities. They’re ways of interrogating the problem. What matters is choosing them based on what you’re trying to learn.
When the risk is unseen failure, inversion matters.
When assumptions may be stale, first‑principles reasoning matters.
When the problem feels novel, analogy often surfaces useful precedent.
You don’t need every perspective. You need the right tension. The goal is not diversity for its own sake, but structural pressure where you’re most likely to skip.
In the template, this shows up as an explicit method‑assignment step and an appendix of suggested pairings by problem type. I treat that appendix as guidance primarily for the human, not the thinking partners. Choosing which hats to put in the room is part of framing the problem, not an implementation detail to be left on autopilot. The appendix exists to help me slow down and choose deliberately, especially when I’m tempted to default to the same perspectives out of habit.
The human lead is not optional
Another design choice that sometimes surprises people is that the human is explicitly named as lead, not just moderator.
That wasn’t ideological. It was practical.
In real use, the most consequential corrections came from context I already had but hadn’t shared. Prior attempts. Data boundaries. Institutional memory. Emotional stopping criteria.
The knowledge interview exists to pull that information forward while it can still shape the work. Treated lightly, it produces polite answers. Treated seriously, it becomes one of the highest‑value steps in the process.
Calibration matters more than coverage
The model rewards calibrated thinking over comprehensive argument.
Each agent is asked not just what they think, but where they’re uncertain and what would change their mind. Empirical checkpoints are deliberately small. They’re not investigations. They’re reality checks meant to stop whole lines of reasoning from growing on bad assumptions.
This is one of the ways the model resists debate‑shaped dynamics. The goal is orientation, not persuasion.
Synthesis is allowed to be lossy
No synthesis is neutral. Naming that turns out to be freeing.
Rather than pretending the synthesis resolves everything, the model asks the synthesizer to preserve tension and propose viable paths. Some questions remain open. Some risks are consciously accepted.
That isn’t a flaw. It’s a constraint made explicit.
Use it, then change it
I don’t expect anyone to use this framework exactly as written. I don’t use it that way myself.
The version below reflects what’s working for me now. When it stops working, it will change. That’s not a failure of the model. That is the model doing its job.
Multi‑Agent Deliberation Template
Revised from Run X deliberation (2026‑03‑26)
Changes from previous version include: a structured knowledge interview in Phase 0, empirical checkpoints in Phase 1, calibration over conviction, explicit recognition of the human as lead, and reflection prompts for all participants.
This template is a thinking tool, not a compliance form.
Every section exists because it solved a real problem in a previous run.
If your problem doesn’t have that problem, skip or compress the section.
The structure should remind you of things you’d otherwise forget.
How to Start a New Deliberation
Each deliberation is a separate run. Don’t overwrite previous runs — they’re the dataset for improving the protocol.
File namingdeliberation-run-<N>-<short-topic>.md
Setup steps
Copy this template into a new file
Fill in the run metadata
Complete Section 0 (including the knowledge interview) and pass the quality gate
Choose method assignments from the appendix (or use the defaults)
Proceed through phases
Run metadata
Run: <N>
Date: <YYYY-MM-DD>
Topic: <short description>
Methods used: <e.g., Analogy / First Principles / Inversion>
Synthesizer: <agent name>
Outcome: <decision made / deferred / abandoned>
Template: v3
0. Problem Framing (Human‑Led)
Quality gate
Before proceeding, confirm this section contains:
a problem statement
at least two constraints
at least one open question
a completed knowledge interview
If any are missing, stop.
1. Initial Positions (Parallel, With Empirical Checkpoint)
Each agent responds independently using their assigned reasoning method.
Each response includes:
Primary read
Method‑driven analysis
Tradeoffs or risks
What feels underspecified
One concrete, testable claim
Confidence and uncertainty
2. Cross‑Reaction (Directed, No Synthesis)
Agents react to each other’s positions and empirical results.
Self‑correction is explicitly valued.
3. Points of Convergence and Tension (Human Lead)
The human names emerging alignment, persistent disagreements, and key tradeoffs.
Agents recommend a synthesizer and name their own bias.
The human decides.
4. Synthesis (Single Agent, Constrained)
The synthesizer preserves unresolved tension, proposes 1–2 viable paths, and names risks and tradeoffs.
5. Decision or Next Move (Human)
Either make a decision or name missing evidence and next steps.
6. Reflection (All Participants)
Where did the agents agree that you wish they hadn’t?
What position did no agent take that someone should have?
Which reasoning method mattered most?
What should change next time?
Appendix: Reasoning Methods and Suggested Pairings by Problem Type
Each agent should have exactly one method assignment. Overlap defeats the purpose.
Available Reasoning Methods
Analogy – What is this most like?
First Principles – What do we actually know versus assume?
Inversion – What would make this fail?
Steelman – What is the strongest case for a position I don’t hold?
Constraint Removal – What would we do if X weren’t true?
Stakeholder Lens – How does this look from a specific role’s perspective?
Temporal – How does this look in 6 months, 2 years, 5 years?
Empirical – What data do we have, and what does it actually say?
Suggested Pairings by Problem Type
Technical architecture or design
→ First Principles + Inversion + Analogy
High‑stakes decision with strong team preference
→ Steelman + Inversion + Stakeholder Lens
Strategy or long‑term planning
→ Temporal + Constraint Removal + Analogy
Cross‑team or organizational decisions
→ Stakeholder Lens + First Principles + Empirical
Stuck or looping decisions
→ Constraint Removal + Steelman + Inversion
How I use this appendix
This section exists primarily for the human lead.
Choosing which roles to assign is part of framing the problem. The appendix helps me pause and ask: What kind of reasoning am I least likely to do well on my own right now?
The value isn’t in covering everything. It’s in choosing deliberately.
Alison + Wiggins + Anitta + Quinn