Practices surfaced by cohort members during live sessions. Credited to the people who brought them into the room. This document grows as cohorts progress.
Before starting any substantive conversation, declare what you know, what you don't know, and what you don't know you don't know. This gives the model a map of your uncertainty - not just your objectives - and surfaces blind spots early rather than late in the conversation.
Add a standing rule to your Claude Project asking it to disclose all assumptions it is currently working with before proceeding. Models fill gaps silently by default. This instruction forces those assumptions into the open where you can correct them before they compound.
For technical work - especially SQL - front-load the conversation with the full database structure, table relationships, and validation tests before asking any questions. The quality of every output is bounded by the context you start with.
Open new project conversations by including organizational context, an explicit request for direct and critical feedback, and relevant project files before stating the task. The model behaves differently when it knows you want hard pushback rather than validation. Set that expectation at the top.
After building a proposal, plan, or argument collaboratively with AI, instruct the model to switch roles and attack what you just built together. Because it helped construct the work, it knows exactly where the weak points are. Andy applied this to a business development proposal and surfaced objections he would not have found on his own.
Tiku — Cohort C — brought in the executive vocabulary for this practice: murder board and red team. Same discipline, different register for participants with strategy, consulting, or military backgrounds.
After reaching a useful outcome, ask the model to evaluate the conversation itself — assign a grade, identify what worked and what didn't, and offer a better prompt you could have used. This turns every session into a prompting lesson. Dawg took the model's suggested prompt to Perplexity, which then built a four-criteria weighted analytic rubric from it.
When a conversation gets long or stale, ask Claude to generate a handoff summary in markdown — capturing what matters and discarding the clutter. Drop that file into a new conversation within the same Project. You get a clean start with crystallized context and none of the accumulated drift. This technique became the foundation of the Module 4 conversation architecture unit.
Four signals that a conversation needs a branch or fresh start. The conversation feels circular and stale, with no forward movement. You find yourself coaching the model's behavior within the conversation itself. The model is agreeing with everything and not surfacing problems with your reasoning. You are growing frustrated instead of making progress. Any one of these is enough to stop, do a summary checkpoint, and start fresh.
Jennifer is Co-Founder at Andus Labs and brings legal background to the program. Her guidance (which is not legal advice) from this session is worth carrying into every cohort.
The core issue is this: when employees use AI tools - including free tiers that train on user inputs - they may be exposing confidential company information whether they intend to or not. This is not a hypothetical risk. It is an active compliance and fiduciary concern. This is why having an AI governance framework/policy in place is something every company needs.
An NDA between participants does not solve the problem, because your company almost certainly did not authorize you to share that information outside of the company, even in a trusted group setting like this one.
The practical guidance: any problem you bring to collaborative work should be one you can describe without including information your company would consider confidential. In many cases, the real problem can be abstracted - you can teach the model and your peers what you are trying to solve without disclosing the underlying data, the client, or the internal context that surrounds it. This is not a reason to avoid the work. It is a discipline that makes the work more rigorous.
Choosing which AI tool to use is not just a workflow preference — it is a governance decision. The platform you use determines whose terms you operate under, how your data is handled, and whether the company behind the tool has made enforceable commitments to the principles it claims to follow.
Jennifer's approach when evaluating a provider: look past the marketing and ask whether the company's structure creates real accountability. Is there a published acceptable use policy? Does the company's legal structure — a public benefit corporation, for instance — create obligations that a standard for-profit does not? Has the company published research on how its models behave, not just how they are intended to behave?
Her framing on Anthropic specifically: a company that publishes its system cards, operates as a PBC, and makes its safety research public has put its commitments in writing where they can be evaluated and challenged. That is a different category of trust than marketing language.
The principle generalizes: before building a workflow around any AI tool, spend fifteen minutes on the company's documentation. What they have written down — and what they have not — tells you something real about how they think about their users.
Tell Claude to bold or notate any numerical data in the output with its source at the point of generation - so trust verification is built into the output rather than chased afterward. Instead of auditing a finished document, you can see at a glance which figures are sourced and which are synthesized. Vinnie framed it as speeding up the trust-and-verify process by making sourcing visible where it matters most.
Craig put the setup frame discipline to a direct test on a live RFP proposal - deliberately and intentionally more detailed in the setup, specifying the audience, who would review it, the goal, pricing parameters for travel, and other constraints. The result: a 17-page document on the second output that needed only minor tweaks. The time investment in the setup frame paid for itself in reduced iteration cycles.
The principle: describe who you are, who the audience is, what you are trying to accomplish, the domains you want covered, and any hard constraints like length or format. The gap between a bare request and a full setup frame is not a small improvement - it is the difference between a draft you rework three times and one you ship.
When researching a company, competitor, or industry topic, explicitly instruct the model to search Reddit alongside conventional sources. Reddit surfaces employee perspectives, internal frustrations, and candid information that organizations are slow to find and remove. CIOs and marketing teams rarely monitor the platform with enough speed to scrub what surfaces there. Vinnie raised this at the close of a session as a specific research discipline: when you want unfiltered signal on a company or topic, Reddit is often where it lives.
Every AI model is trained to produce answers, not to feel doubt. When you ask a single model a question, it will provide a confident, coherent response regardless of whether it actually knows. Before accepting an AI output on any decision where being wrong has real consequences, apply the Deliberation Threshold test: is this question high-stakes enough to run through more than one model independently? If yes, submit the same question to two or more models without showing them each other's answers first. Where they agree, that convergence is a genuine signal. Where they disagree, the disagreement is the finding.
Thor's platform Pythia implements two structurally distinct approaches. Consensus mode (anonymous): models answer independently, then receive a synthesis and refine or hold their positions. Produces roughly 65 percent agreement on average. Good for research questions and factual claims. Debate mode (attributed): models see each other's named responses. Agreement drops to roughly 50 percent. Use this when you need the full range of informed disagreement rather than a synthesis.
The shared confabulation caveat: multi-model consensus is better signal than single-model output. It is not a truth oracle. Thor demonstrated this with a fabricated study citation. One model invented the entire paper. The other four caught it. Cross-model review helps because different models fail differently. It does not guarantee every failure will be surfaced.
The common framing for AI model choice is: which model should I use for this task? Thor's experimental work suggests this is the wrong question. Running the same five models under different conversation architectures produced fundamentally different outputs from identical models answering identical questions. In one demonstration, Claude said nothing notable when models were anonymous. In full-attribution mode, it spontaneously flagged that unanimous fast agreement across five models should raise suspicion. That behavior emerged from the structure of the conversation, not from any change to the model itself.
Before starting any significant AI-assisted project, ask how you are going to set up the conversation rather than which model you will use. Will you ask the model to surface its own assumptions? Will you have it argue the opposing view? Will you run the same question through two models independently? Will you tell it to flag where it is uncertain? These structural choices are available in any model, with any tool, right now.
This extends the Setup Frame (Module 3) and the assumption-disclosure instruction (Cohort A, Module 2) into the multi-model context. The setup frame asks: what does Claude need to know before we start? Structure Before Selection asks: what does the conversation architecture need to produce that a single exchange cannot?
On why a degraded conversation cannot be saved by asking the model to forget what just happened: "It's like trying to give somebody a suit that has previously been tailored, and at a certain point it's just too messed up and you gotta throw it out and start over." The frustrating part is you don't know when it's going to happen - but the moment it degrades, you recognize it immediately. The answer is the same as the tailor problem: start with fresh material, not the same worn cloth.
After running the same work through ChatGPT and then Claude back-to-back, Jeff arrived at a working model for platform selection: ChatGPT for creative outputs and image generation, Claude for thought partnership and analytical depth, Perplexity for troubleshooting and verifying things other platforms have gotten wrong. Not a permanent framework - the landscape shifts - but a useful starting point for deciding which tool to reach for first.
The most reliable signal that a conversation has run its course: you start cussing at it. Not a technical metric - a human one. When Claude stops iterating and starts repeating itself, responses get shorter and more generic, and it keeps saying "you're right" to everything, the instinct is to push harder. That instinct is wrong. The conversation has collapsed. The answer is not more prompts. It is a markdown and a fresh start.
Michele's indicator works because it is honest. Most people notice the frustration before they can articulate what has technically gone wrong. Trust the frustration. It is telling you something accurate.
When a conversation is not working, there are two paths: iterate with more instruction, or scrap it entirely and rebuild with a better setup frame. Michele ran both in the same week - one she iterated to a dramatically different result, one she scrapped and found the rebuilt version was wildly different in quality. If the setup itself was wrong, iteration will not save it. Rebuild from the frame up.
When Claude started agreeing with everything on an automation decision - "you're right" to every prompt - Seth pushed back explicitly: give me both sides of the fence. Why should I automate? Why shouldn't I? That forced reframe produced the substantive analysis the conversation had stopped providing. When the model stops pushing back, make it push back by design.
Josh built a blog post through seven distinct adversarial passes - loading the source material, generating a first draft, asking for the three strongest objections, rewriting with those objections addressed, then reading it again as a complete and total skeptic, repeating until the output had genuinely absorbed the criticism rather than just acknowledged it. Each pass raises the floor of the next.
Diona went from struggling with a basic business plan to building real-time bid engine requirements with objections from financial, IT, vendor, and marketing perspectives - in one week. The unlock was bringing her full domain expertise into the setup: pacing controls, identity verification attributes, partner bid engine tradeoffs, reinsurance pricing risk. Claude's output quality is bounded by the context it receives. When you bring deep professional knowledge to the setup frame, the model surfaces insights at the level of that knowledge - not below it.
Her observation after the session: "I could literally go do this right now because of the work." That is the outcome the setup frame is designed to produce.
When a question comes up in conversation that feels genuinely contested — something where the answer depends on perspective, values, or incomplete information — do not wait to verify it later. Open Arena in the moment and run it live.
In Module 3, Lu raised a question about Constitutional AI that did not have a clean answer. Steve navigated to lmarena.ai without being prompted and ran the question through multiple models in real time. The group watched different models handle the same question differently. That live comparison did more to illustrate how models reason — and where they diverge — than any prepared example could have.
The behavior worth reinforcing: Arena is not just a research tool you use before a conversation or a verification step you run after. It is a live thinking instrument. When you are in a conversation and the answer matters, run it in the room.
Vinnie built a personal AI operating system on his iPad driven entirely by voice. The workflow runs through ChatGPT and covers meeting preparation, daily task management, and end-of-day voice journaling — with a downstream email recap that feeds into other tools. No keyboard required at any point in the loop.
The principle underneath it: if you design the system correctly, the cognitive load of managing your day shifts from your brain to the stack. You are not transcribing or typing — you are speaking, and the system processes, organizes, and delivers.
Vinnie demonstrated this live at a cross-cohort field trip on April 10, 2026, attended by all three cohorts.
Full walkthrough available in the Module 8 Systems Building session.
Prompt a model for its best work on a problem. Then instruct it to critique that work as a hostile competitor finding every weakness, gap, and bad assumption. Then take both the original output and the critique and ask the model to rebuild from scratch, incorporating the objections into a stronger version. This is the creator-critic relay as a disciplined three-step sequence rather than an informal back-and-forth, and the rebuild step is what most people skip.
When deciding what to hand to an autonomous agent first, pick the task where the trigger is easy to identify, the failure mode is easy to detect, and getting it wrong carries low consequence. This sequencing prevents over-automation before you understand how an agent performs under real conditions. Start with the task where the cost of a bad autonomous decision is easy to catch and easy to fix.
Ask Claude to display the current architecture of your workflow, configuration, or connected system as an HTML output. This produces a visual diagram showing what sources the system pulls from, how they connect, and what outputs it produces. Complexity that felt manageable in prose becomes visible as a diagram, and redundancy across platforms you are touching becomes obvious.
When Claude extracts data from PDFs that contain visually complex charts — particularly those with diagonal or rotated data labels — ask it explicitly to flag where label angles or chart formatting may have introduced directional bias into its readings. Then spot-check those specific values against the source document. This converts a silent error into a flagged and manageable one.