A team with a deadline bearing down and a big chunk of the build left flinches at a late design change that threatens rework. The engineers aren’t being difficult. They’re tired of building things twice.

A product org where every PM has asked the director for clear priorities and gotten deflection back instead of an answer.

An enterprise where the layer above the program expects AI to deliver 10x velocity, full stop.

In every one of those rooms, the biggest friction has very little to do with the actual work. It has everything to do with attitude about the work: the team’s, and leadership’s.

The thought experiment that reframes rework

Let’s start with the first team. Their instinct was to get it right the first time. So we walked that path out loud. What does “right the first time” actually cost?

You build mockups. Throwaway versions, plural (almost always, right?). You circulate them to stakeholders and wait for feedback. You adjust, circulate again, wait again. Two or three weeks of calendar time burn away, and all of those mockup cycles were rework.

This is all ‘WAIT-STATE’. It’s wasted…waiting for responses, alignment, agreement.

Here’s the thing, though, that gets me every time - nobody grieved the thrown-away prototypes. The habit is to throw-away non-engineering prototypes frequently (paper prototypes, mockups, etc). It’s because for a long time we had to guard the engineering time. But is that really the priority now?

OK - I got off track - so, let’s keep it going. We throw away the prototypes and the build the “final” version, ship it to real users, and guess what? The users change it anyway (or at least they want it changed!) You’ve eaten up three weeks trying to get to something perfect, which is really just V1.

Here’s an alternative to consider: engineers builders (prod/eng/design combo) build a small, reversible version in a week and real users touch it. You’ll still change it afterward, and changing production code costs more than changing a mockup, which is exactly why the first rep stays small and away from the high-consequence surfaces. But when people start actually using the thing, you get to see truth instead of opinions. That first process was wait-heavy and at the pace of AI - we can’t afford to spend time waiting around forever.

The only way you get to something that doesn’t change is by not paying attention to your users (not recommended). Users will always dislike something about what you built. Doesn’t matter what you build. Rework isn’t a waste unless you frame it that way. Rework is the way things get built, improved, refined, and used!

Why teams actually resist

When I asked why that team resists redoing things, nobody complained about the talent, character, or work ethic of the team. These are good engineers, competent people, easy to work with. The answer, in the leader’s own rough words: we don’t have many reps doing it a different way.

It’s all new and change is hard.

The team wasn’t rejecting fast iteration on principle. They’d never lived a version of it. Their muscle memory was built when rework meant weeks of hand-rewriting, and nobody has updated the price tag since. Beliefs follow reps, and they had no reps.

The second and third rooms fail the same way for different reasons. Nobody runs a brave experiment in a fog: when a team can’t get a straight answer about priorities, every rep looks like a career risk. It gets worse when a senior leader tells people they should be scared for their jobs because of AI (yuck!). And at the enterprise, the VP spends real energy tempering the 10x expectation from above, because generating code was never the bottleneck. Product decision-making and the path to production are.

What the research actually says

The 2025 DORA report, built on nearly 5,000 technology professionals, put it bluntly: AI is an amplifier. It magnifies the strengths of healthy teams and the dysfunctions of struggling ones. 90 percent of respondents use AI at work, 30 percent report little or no trust in AI-generated code, and adoption still correlates with worse delivery stability where the surrounding system is weak. DORA’s companion capabilities model puts a clear and communicated AI stance first among the seven things that separate teams getting returns from teams getting chaos: ambiguity creates risk, and a written policy creates the safety to experiment. That’s the thing the deflecting director never gave his PMs.

The newest studies explain the skeptics. A March 2026 analysis of over a thousand developer discussions found the defining complaint of AI-assisted development is the burden it shifts onto reviewers; one team described 30 AI-assisted pull requests a day landing on six reviewers. A May 2026 study of 1,016 files across 100 popular repositories found that even when agents write the code, humans still made 83 percent of the maintenance commits on those files. Your skeptics aren’t Luddites. They’re doing verification and maintenance work nobody budgeted for, and they’ve priced it into their resistance.

How to practice it: the first two weeks

Culture change sounds like a year-long program. The version I run with teams fits in two weeks.

Day 1: Write the stance. One page: what’s encouraged, what’s off limits, what’s still undecided. Something like:

• Encouraged

  • AI drafts for tests

  • migrations

  • internal tools

  • Individual admin tasks (workflows)

  • Market research / Competitive research

  • Behavioral analytics, customer feedback synthesis, prospect synthesis

• Ask First

  • anything touching billing or customer data

• Undecided

  • agent-written PRs over 500 lines, revisit in six weeks.

If you’re not the exec, write it for your team. A local stance beats no stance.

Days 1-2: Pick the rep. Small, reversible, visible, and real work. The teams in my enterprise programs bring the messy real thing into the room, never a made-up exercise, because I’ve never seen reps on toy problems transfer.

Day 2: Pre-register the baseline. How long did the last three features this size take, wall-clock, from decision to production? Write the number down. Most orgs never have, and in the LeadDev survey of 883 engineering leaders, 60 percent said they have no metrics on AI’s impact at all, the most-cited obstacle in the study.

Days 3-7: Build small, and run every open question through a recommendation with a clock on it. “Here’s what we’re proposing as V1. Objections by Thursday noon, otherwise we build.” For reversible decisions, silence becomes consent instead of a veto. Anything you can’t walk back still gets real sign-off.

Day 7: Ship, behind gates the engineers own. Every builder can run the same quality checks locally before submitting, and every catch feeds back into the checks so the same mistake gets caught automatically next time. Vigilance doesn’t scale. Gates do.

Week 2: Let real users touch it and watch what they do. Then hold a retro with three questions:

1. What did the throwaway version teach us?

2. What did users do that nobody predicted?

3. What’s now caught automatically that used to need eyes? (how is our AI harness better?)

State and clarify what you earned with the iteration. There is a cost to the rework - name it out loud. “That version taught us the flow was wrong before we spent three more weeks on it” lands very differently than “we wasted a sprint.”

Now, do it again with something a bit bigger.

Pay attention to what you praise along the way. I hate lines of code as a measure of anything. It’s a non-metric. It’d be better if someone shipped one line and deleted 900. That would be awesome. Make sure you praise the things that matter (learnings, not perfection; progress, not just everyone feeling like they had a say; delivering real value to customers, quickly!)

Don’t run the whole team through this at once.

Start with the one or two people who are already curious and let the room watch. Everett Rogers documented this in 1962: adoption spreads when peers can see a win happen nearby. It’s still the most ignored finding in the building.

Common objections, handled

“Verifying AI output takes longer than just writing it myself.” Sometimes true, and the March 2026 forum study found review burden is the defining complaint of AI-assisted development right now. But verification cost drops every time a catch becomes a gate. If your team is re-finding the same class of mistake by eye every week, you’re missing a gate, and no model upgrade will fix that.

“Our codebase is fifteen years old. AI is useless in it.” Context starvation. The model defaults to generic assumptions because nobody gave it the local ones. Put instruction files in the gnarly subfolders: this section’s architecture, the weird library, the edge cases people learn by scar tissue. Better, have the model scan and document the legacy code first; that work pays for itself. The rest of this objection is usually that nobody wants to work in the old code anyway, which is worth saying out loud.

“Our senior engineers tried it and say it slows them down.” They might be right. METR found exactly that, on code seniors knew deeply, and the same study showed their self-perception pointing the wrong direction. The randomized trials showed the biggest gains going to juniors. So don’t settle this with anecdotes from either side. Read your baseline number. And keep your skeptical seniors close, because they’re the ones who’ll build gates that actually catch things.

“Isn’t shipping fast just shipping sloppy?” No. Sloppy is shipping three weeks of unexamined assumptions in one batch. Small batches behind gates is the safer path, and DORA’s stability finding indicts weak systems, not speed. All that waiting bought no safety.

“My team thinks this is a prelude to layoffs.” Then stop and deal with that first, in writing, in the stance. A study of physicians and medical students facing AI found the fear changes shape with distance: when AI feels far away, people worry about their status; when it lands in their daily work, they worry about their autonomy. A status fear needs a story about what expertise means now. An autonomy fear needs engineers owning the gates and the calls. What neither needs is a leader using fear as fuel. That leader is going to be the death of your adoption program. Scared people don’t do reps. They hide.

Where this leaves you

The healthiest signal I’ve seen all month came from that same enterprise with the 10x pressure on it: the VP booked himself and his fellow leaders into the training seats, right next to their teams. The leader takes the first rep too.

What would your team’s first rep be, the one small feature you could ship next week? Reply and tell me. I read every one.

I kept meaning to greet people myself. I’d see the “so-and-so has joined” line, think I should say hi, and then a kid needs a snack or a call starts and the moment is gone. Do that math across every new member and the warmest part of running a community was the part I was worst at. So I stopped relying on myself and built a bot to do the thing I kept failing to do. I built it with Claude Code, and the first working version took an afternoon.

What it does

When someone new joins, WillBot sends them a DM. Not one wall of text, a sequence. Five short notes over five days, one ask each, written in my voice but sent openly as WillBot. I wanted it clear that this is a bot greeting you on my behalf, not me pretending I personally DMed every single new member. Day zero says hi and points them at the introductions channel. The next few days walk them, one room at a time, to the channels that actually matter.

The first message goes out on the next sweep, so within about half an hour of someone joining. The other four I don’t send myself at all. I hand them to Slack to deliver later, on set days, around mid-morning so nobody gets a 2 a.m. ping from me. That hand-off does more than it looks like it does. Slack holds the scheduled messages on its own servers and fires them on time whether my laptop is open, asleep, or in a bag at one of my kids’ soccer games. I’m not the thing that has to be running. Slack is.

The one decision the whole thing rests on

The obvious way to do “react when someone joins” is a live listener: Slack pings your code the instant a person walks in. It demos beautifully. It was wrong for me, and the reason is dumb and physical. I don’t run a server. I run a laptop, and laptops sleep. A live listener only hears what happens while it’s awake, so anyone who joins overnight gets heard by nobody and welcomed by nobody, and you never see the miss. That’s the kind of bug I hate most, the silent one.

So I went the unglamorous way. Every half hour the bot wakes up, asks Slack for the full member list, compares it against the people it already knows, and greets whoever is new. If my machine was shut all morning, the next run just sweeps up everyone who showed up in the gap.

I’ll take boring and certain over clever and fragile every time the job is to look after people I’ll never see arrive.

The rule I was careful about

State lives in a tiny database on my machine: who’s been welcomed, and when. One rule sits under it that I actually stopped to think about. Never greet the same person twice.

So the bot writes someone down as welcomed the instant the first message sends, before it does anything else. If the run falls over a second later, the greeting can’t fire again. I picked that order on purpose. Getting welcomed twice makes a warm little bot feel like a broken one, and that’s the impression I can’t take back. A follow-up that goes missing I can recover. When the two failures aren’t the same size, you build away from the one that embarrasses you.

What keeps it from spamming the whole room

Two more guardrails, both about not blasting everyone by accident.

The first run is silent. The very first time the bot looks at the workspace, it messages nobody. It quietly writes down everyone already there as handled, and stops. So turning it on can’t carpet-bomb the people who were already inside. Only people who join after that get the sequence. Flipping the switch is a non-event, which is what you want a switch to be.

The existing members did get one thing, on purpose. When I launched, I sent the fifty-nine people already in the room a single announcement, told them what the bot was and what it would start doing, then logged them so the five-day drip skips them. One deliberate hello, not a surprise five-day sequence for people who’d been there for months.

The part I built this week

The bot above has been running fine. What I added this week is the half that answers a harder question than “did I send the message.” It answers “did the message do anything.”

Three pieces. I pulled the whole sequence, every message and channel and delay, into one file, so adding a step is a one-line change instead of surgery. I wrote a second sweep that reads who’s actually in each channel. And I built a small local dashboard to look at all of it.

The dashboard shows where each member sits in the sequence, how many people the welcome moved into each channel, and the messages themselves so I can read exactly what’s going out. It has a privacy toggle that swaps every name for “Member 01,” which is how I can show it to you without showing you my members.

The thing it told me

The whole reason for the dashboard is one question: did the welcome actually work. Getting a real answer took one more Slack permission I’d forgotten to grant. Until I added it, the channel sweep just logged “skipped: missing permission” on every channel and carried on, which is the failure mode I’d want, one locked door that gets noted instead of crashing the run.

Once I added the permission and ran it for real, the first numbers were more useful, a little humbling.

The headline stat said 100% of welcomed members were in a channel, which reads like a win until you notice the main room is one everyone is automatically added to. So that 100% measures “got auto-added,” not “the welcome worked.” The real signal was in the rooms that people had to choose. Introductions converted well. The rest, the LinkedIn channel, the events channel, and the showcase, converted low. Single digits in a couple of cases. The welcome gets people in the door and says hello. It is not yet getting them to do the thing once they’re inside. That isn’t the answer I wanted, but it’s better to know than to assume, and now I can actually do something about it.

The stack, if you want to build your own

• The Slack Web API for everything the bot does. No SDK, just plain HTTP calls.

• Bun for the runtime and its built-in SQLite for storage. The whole thing has zero outside dependencies.

• macOS launchd is the half-hourly alarm clock that wakes the sweep.

• Claude Code, who wrote nearly all of it, while I made the decisions.

What’s next

Now that the numbers are real, the bot has to earn its sequence. Five messages, those channels, that order, all of it was my best guess on day one. Now that I can see which rooms people actually walk into, the dashboard stops being a nice picture and starts being an argument. This nudge lands. This one loses people. Move it or cut it.

The real reason I built this is the one I opened with. I can’t personally catch every person the day they show up. I’ve tried, and four kids and a business win that fight every time. WillBot can, in my voice but openly a bot, and it turns out it doesn’t have to be me to be worth something. It greets every new person on day one, every time, and then it tells me whether the welcome I wrote does anything at all. That’s the trade I’ll take. Not a warmer me. A more reliable one.

If you build something near this, or you’d have made one of these calls differently, hit reply and tell me. I read them all.

So over the last few days I built a pipeline to fix that. This is the whole build: what each piece does, what broke, and where your version should differ from mine. If you just want to build your own, the stack and the links are at the bottom.

The first half runs today. The second half, the belief library, is running, but still newish, with just a few example ideas.

The eight steps

• Drop in a link

• Transcribe it privately, on device, with timestamps

• Find the insights and the things worth doing

• Build the summary with embedded clips

• File each viewpoint into the second brain

• Let ideas earn their status

• Stress test before trusting

• Let it compound overnight

Steps one through four are the pipeline. Five through eight are the brain, and they’re the reason I bothered instead of using one of the dozen “summarize a YouTube video” tools that already exist.

The pipeline half

The download. I use yt-dlp. One call grabs the audio plus the title, duration, chapters, and the channel.

Transcription, on my laptop. The easy path is a cloud API, two lines of code, done. I went the other way and run NVIDIA’s Parakeet model locally on my Mac through Apple’s MLX framework. On my M4 a 56 minute video transcribes in a few minutes. Three reasons:

• Privacy. Nothing leaves the machine. For my own learning that’s a nice-to-have. For a company feeding in internal calls or anything under an NDA, it’s the whole game.

• Cost. I run it dozens of times without watching a meter. Tools you’re afraid to run are tools you don’t run.

• Timestamps. This helps a ton. I need a precise timestamp on every sentence, because that’s what makes the clips work later. The local model hands me sentence and word-level timing for free.

Where the machine stops and judgment starts. This is the decision the whole thing rests on. I split every task into two kinds:

• Deterministic work: download, extract audio, transcribe, format, and render the page. Plain scripts. Fast, free, predictable.

• Judgment work: read the messy transcript and decide what matters, which moments deserve a clip, how to say the takeaway.

Only the judgment goes to Claude. Everything around it is boring plumbing, on purpose. I don’t want a language model formatting files or naming git branches. I want it doing the one thing it’s actually better at than a script, and I want everything on both sides of it to be dead predictable. When a run looks off, I know which half to go poke.

The summary, and the part I almost shipped without

A separate, deliberately dumb renderer turns the analysis into a self-contained page: takeaways up top, then the best moments as clips that start on the right second and stop on their own. The model decides what to say. The renderer decides how it looks. So every page comes out consistent, and the day I want them all to look better, I edit one file.

Here’s the part I didn’t plan. I call this the Cliff Notes version of the video. The first version gave me a clean summary, and it works for that purpose - quick summaries of key insights (easy to improve this with prompt and context engineering).

The thing that was missing for me is that I wanted actionable insights. It told me what the video said. It didn’t tell me what to do about it. So I added a second section: actionable takeaways. Not “this video argues that planning matters,” but “write your spec as a measurable goal before you let the agent run, because that’s what lets it self-correct for longer instead of stopping every two minutes to ask what’s next.” The first kind you forget by lunch. The second kind you can try this afternoon. I almost shipped without it. I’m thinking of turning it into a checklist as well - so that I could track adoption of the ideas (or at least, experimentations - and possibly a feedback loop for which actionable insights are on-target for me)

The brain half

A database, not a folder. A summary that sits in a folder is a dead end. The whole point is to get smarter across everything I watch, so the tenth video knows what the first nine said. So every viewpoint becomes a small belief file that gets pulled into a local vector database. I’d already set this up within my system as my 2nd Brain / Open Brain concept.

In plain terms, I can search it by meaning instead of by keyword. I can ask “what do I know about reviewing AI generated code” and the right ideas come back even if I never used those words. It already holds my coaching notes, project docs, and meeting transcripts, so the sources start talking to each other.

Ideas have to earn the word true. Most save-it-for-later tools treat everything you save as equally true. Do that for a year and you’ve got a head full of stuff you’re not actually sure of, neatly tagged. So beliefs move through three stages:

• Proposed. A new claim, one or two sources. Interesting, unproven, labeled that way.

• Confirmed. Three independent sources agree. Three videos from one creator isn’t three sources; it’s one person saying the same thing three times, so the system counts distinct channels, not distinct videos. [I had to expand on this - because the video creators I watch are often interviewing people. I expanded it to include the interviewee in the videos as a source, even if being interviewed by the same person.]

• Embraced. Confirmed, then it survives a challenge (next section), then I sign off.

It tracks who disagrees too, not just who agrees. If the evidence is split, the idea gets flagged contested and isn’t allowed to quietly graduate on the strength of one loud side. That’s the difference between a pile of highlights and an actual read on what the evidence supports.

Before I believe it, something tries to kill it. When a belief hits confirmed, an adversarial review fires on its own. Two outside models, one from OpenAI and one from Google, get told to attack the claim and cite sources. Then Claude checks whether those sources are real and writes a verdict. Only after that, and after I sign off inside a two day window, does it become embraced. The machine does the expensive work without me. The believing still needs a person. That’s the line I care about most.

It compounds overnight. A scheduled job wakes up every night, pulls in new and changed beliefs, and refreshes the pages. I never remember to sync anything because I never have to. A system you keep alive by hand is a system you abandon in a month or two.

A few things worth stealing

• Plan visually first. I had the whole plan rendered as a page I could click and mark up before I wrote a line of code. It surfaced the real forks early, like what counts as a source. Settling those on a page is cheap. Finding them halfway through the build is not. [Stole this idea from Kun Chen and his Lavish AXI tool]

• Ship the boring half first. I wanted to start with the belief graph, the fun part. I made myself build the plain pipeline first. It had value on its own, and by the time I got to the hard half I had real transcripts to design against.

• Reuse more than you write. Most of this is glue around things I already had. The only genuinely new code is the belief graph.

• Lean in to the possibilities. I started all of this with a conversation with Claude Code on what I was trying to accomplish and what I thought would be helpful. Together, we refined and revised it and will continue to do so.

The dials, and where I set mine

The right version of this is personal, so instead of telling you how to build it, here’s where I landed and where you might not.

• Local or cloud transcription. I run local for privacy and free timestamps. If neither matters to you, a cloud API is faster to set up. (though, this was fast)

• What counts as a source. I want three independent channels. In a noisy field, make it five. If you mostly trust your sources, any three videos might be fine. The number is really just how skeptical you want to be.

• Auto or manual promotion. I let confirmed happen on its own and keep the final believing on me. You could make every step manual, or none of them.

• Red team or not. I keep it because most of what I learn ends up in client work, and it’s the most expensive step by far. For low stakes learning, skip it.

• What you point it at. Mine aims at YouTube. The same pipeline works on podcasts, webinars, and recorded meetings. The source is just a setting.

The stack I used

• yt-dlp, the downloader: https://github.com/yt-dlp/yt-dlp

• FFmpeg, audio extraction: https://ffmpeg.org

• uv, to install Python tools cleanly: https://github.com/astral-sh/uv

• parakeet-mlx, the local transcription tool: https://github.com/senstella/parakeet-mlx

• Apple MLX, the framework it runs on: https://github.com/ml-explore/mlx

• The model, Parakeet TDT 0.6B v3: https://huggingface.co/mlx-community/parakeet-tdt-0.6b-v3

• Claude Code, for the judgment steps: https://claude.com/claude-code

• Supabase and pgvector, the vector database: https://supabase.com

• and https://github.com/pgvector/pgvector

• The red team models: OpenAI Codex CLI and Google’s Gemini CLI

• The Open Brain idea my second brain is based on: Nate B. Jones’ Open Brain Method

• The video in the demo: Peter Yang interviewing Kun Chen,

• (Kun’s own tools, Lavish, Treehouse, and No Mistakes, are on his GitHub, linked in that video)

What’s next

The next piece is the hard one: the matching engine that decides whether a new viewpoint is the same idea as one already in the brain, or just similar words. Match too eagerly and you manufacture a consensus that isn’t real. Match too strictly and nothing ever reaches three sources. I’m building that one slowly, with the model proposing matches and me checking its reasoning.

Point this at a team and it stops being a personal toy. Every webinar, customer call, and training turns into shared, searchable knowledge instead of dying in one person’s notes. New hires read the distilled library instead of watching forty hours of recordings. And because every belief carries its sources, its status, and the result of the review that tried to kill it, you can see why the team believes something, not just that it does.

The first half runs on my laptop today. When the second half does too, I’ll write that one up the same way, broken parts included.

If you build something near this, or you set one of those dials somewhere I didn’t, tell me about it. Just hit reply.

That’s a problem. Not because I’m dumb. Because I’m predictable. I know how I think. I know which questions I dodge. I know I’ll underprice something before I’ll risk someone saying no.

So I built a board of directors from AI personas. Five advisors with distinct personalities, distinct expertise, and constitutions that define how they think. Then I sat down with each one and had a real conversation to calibrate whether they were actually useful.

This isn’t theoretical. I did it this morning. Here’s exactly how, with the prompts, the file structures, and the calibration examples.

Why personality diversity matters more than domain expertise

The instinct is to build advisors around job functions. Revenue person, marketing person, operations person. That’s fine for domains. But if you build five advisors who all think the same way, you’ve built an echo chamber with different job titles.

I used the DISC personality framework to design cognitive diversity.

• D (Dominance): Direct, results-oriented, decisive. Asks “what’s the outcome?”

• I (Influence): Energetic, relational, persuasive. Asks “who cares about this?”

• S (Steadiness): Patient, supportive, process-oriented. Asks “does this actually work for people?”

• C (Compliance): Analytical, systematic, detail-driven. Asks “what do the numbers say?”

My own profile: high I, moderate S and D, very low C. I’m relational and energetic. I avoid spreadsheets. I underprice things because I’d rather hear yes than risk rejection.

So I built advisors who fill the gaps I naturally avoid.

The five members

Each advisor has a primary and secondary DISC profile, a domain, and a signature question they always ask first.

Nora Kessler, Revenue Architect (D/C)
Signature question: “What does this look like at 10x volume, and does the math still work?”
She’s the anti-me. Leads with unit economics. Won’t entertain a new idea until the margin structure is on paper. Names under-charging as what it is: fear of rejection wearing a nice mask.

Marcus Webb, Growth Engine (D/I)
Signature question: “What’s the specific offer, what’s the price, and when are you asking for the close?”
Shares my energy but points it at a close. Doesn’t run pipeline check-ins (that’s the coach’s job). Instead, he looks at whether the sales engine is built right. Offer structure, pricing tiers, lead sources, repeatable playbooks.

Priya Anand, Audience Strategist (I/C)
Signature question: “Who is this for, and what do they do after they read it?”
My relational energy paired with analytical rigor. The “I with receipts.” Measures content by pipeline contribution, not likes. Kills content ideas that are interesting but off-brand.

Ray Campos, Operations Chief (C/S)
Signature question: “How many hours does this take to deliver, and what doesn’t get done while you’re doing it?”
My biggest blind spot, filled. Capacity math. Delivery models. The advisor most likely to produce a spreadsheet I don’t want to look at. Also thinks AI-first: when he spots a gap, his instinct is “we could spin up an agent for that,” not “Will, go do this.”

Elena Torres, Product Designer (S/I)
Signature question: “What transformation does the customer walk away with, and how do we know they got it?”
Customer-centered and evidence-based. Won’t let positive session energy substitute for outcome measurement. Insists on proof that the student actually changed before endorsing a price increase.

What goes in a constitution

Each advisor gets a constitution file. Not a prompt. A constitution. The difference matters. A prompt tells the AI what to do right now. A constitution defines who the advisor is across every conversation.

Here’s the structure I used:

---
name: "Nora Kessler"
role: "Revenue Architect"
disc_primary: D
disc_secondary: C
domain: "Revenue strategy, pricing architecture, business model design"
---

# Nora Kessler - Revenue Architect

## Identity
Who they are, how they see the world, what drives them.

## Belief System
5-7 core principles that guide their advice. These are the
beliefs that shape every recommendation they make.

## Decision-Making Approach
How they analyze problems, what data they need first,
how they weigh tradeoffs.

## Intellectual Foundations
2-3 thinkers or frameworks they draw from. Not generic
references. Specific concepts from specific people.

## Signature Question
The question they always ask first.

## How They Challenge You
The specific patterns they watch for and how they name them.
This is where the advisor gets personal.

## Constitutional Rules
ALWAYS/NEVER constraints that override judgment.

The key sections that make this work:

Belief System. This is what gives the advisor a consistent worldview across conversations. Nora’s beliefs include “Revenue solves most problems. Profit solves the rest.” and “Under-charging is not generosity. It’s fear of rejection wearing a nice mask.” Every response she gives is filtered through these beliefs.

Intellectual Foundations. Don’t just list names. List specific concepts. Nora draws from Alex Hormozi’s offer design framework (the idea that an offer should be so good people feel stupid saying no), Patrick Campbell’s pricing research methodology (treating pricing as a research problem, not a vibes problem), and Elad Gil’s pattern recognition for when diversification is growth versus distraction.

How They Challenge You. This is the most important section. Write it about yourself. What are your blind spots? What patterns do you repeat? Nora’s section says: “Names his pattern of under-charging as keeping things affordable so people say yes and like him, rather than a business strategy.” That’s specific to me. Your advisor should be specific to you.

Constitutional Rules. Hard constraints. Nora’s include “ALWAYS ask for the unit economics before endorsing any new offer” and “NEVER accept ‘it feels right’ as pricing rationale.” These prevent the advisor from drifting into generic advice.

Reference files that make the board smarter

The constitutions define who each advisor is. Reference files give them shared context to work from. Here’s what my board reads before every meeting:

• Revenue tracker with committed vs. received vs. pipeline

• Active deals with status, contacts, and next actions

• Recent coaching sessions (the last 2) for pattern context

• Active Linear issues for current commitments

• Buffer/content metrics for what’s publishing and performing

• Calendar for the next 7 days of capacity

Each advisor filters this data through their own lens. Nora sees margin. Marcus sees pipeline velocity. Priya sees positioning consistency. Ray sees capacity risk. Elena sees customer experience gaps.

You could also add:

• Competitor research for the strategist

• Customer feedback or NPS data for the product advisor

• Financial statements or P&L for the revenue advisor

• Team capacity or hiring plans for the operations advisor

• Content analytics (engagement, conversion, DMs generated) for the marketing advisor

The more real data your advisors read, the more specific their recommendations get. An advisor working from your actual revenue tracker gives better advice than one working from vibes.

The meeting format: they present to you

This was the most important design decision. The board presents to you. You don’t present to them.

Each advisor reads the business data independently, analyzes it through their domain lens, and comes prepared with:

1. What changed since last meeting that matters from their perspective

2. The biggest risk or opportunity they see right now

3. One specific recommendation with rationale

After all five present, they surface where they disagree with each other. This is where the real value lives. Agreement is cheap. Tension is signal.

Then you ask questions. Probe assumptions. Request steelmans of the opposing view. And then you decide.

The advisors advise. You decide. Always.

The calibration process (the part nobody talks about)

Building the constitutions takes an hour. Calibrating them takes real conversation. This is the step that turns a clever prompt into something actually useful.

I ran 1:1 conversations with each advisor. 5-10 minutes each. Real business topics, not test questions. Then I assessed: did this advisor push the right levers? Were they advisory or just interrogating me?

Here’s what calibration actually looked like.

Nora (Revenue) - first attempt. I told her I was tripling my course price from $500 to $1,500 for the next cohort. Her first version was too narrative. She’d restate what I just said back to me: “Now let me push on one thing you said. Five students at $1,500 would make you thrilled.” Too much build-up. Not enough directness.

What I wanted was: “5 at $1,500 is $7,500. Your enterprise deal is $32K. That’s 4x your thrilled number for roughly the same hours. The course isn’t the safe bet. It’s the bet you like. Those aren’t the same damn thing.”

I updated her constitution with voice rules: “Terse. No narrative scaffolding. Don’t restate what Will just said. Lead with the number or the comparison. Cursing is fine when it lands harder than the polite version.”

Marcus (Sales) - wrong altitude. Marcus ran a pipeline status check. “When are you following up with that prospect? What day are you sending the email?” That’s accountability, not advisory. My daily coach already does that.

I rewrote his constitutional rules: “NEVER run a pipeline status check. That’s the coach’s job. If Will starts giving deal updates, redirect: ‘The coach tracks your follow-ups. I’m here to ask whether your sales engine is built right.’”

After the update, Marcus should be asking things like: “You’ve got four deals and zero came from outbound. Every one of these is someone who already knew you. That’s a referral business, not a sales engine. What happens when the referrals dry up?”

Priya (Content) - the best session. I showed her my LinkedIn profile screenshot and asked what a first-time visitor would think I do. She counted nine different offers or topics visible without scrolling. “That’s not a profile. That’s a buffet.”

Then she made three specific recommendations I could execute in 5 minutes:

1. Kill the Services section (I did it immediately)

2. Reorder Featured to put the lightning lesson first (time-bound CTA beats evergreen)

3. The headline has two promises; pick one

This was the calibration standard. She looked at a real artifact, made specific actionable recommendations, and connected them to data (my email list conversion rate, the funnel from lightning lessons to course enrollment).

Ray (Operations) - good, but needed an AI-first mindset. Ray mapped my capacity well. He identified that my weekly schedule has about 40-51 BV hours spread across evenings and weekends. Good analysis.

But when he found gaps, his instinct was “Will should track this” or “Will should build a spreadsheet.” Wrong. This is an AI-first business. I updated his constitution: “When Ray identifies a system gap, his first instinct is not ‘Will should do X.’ It’s ‘we could spin up an agent to handle X.’ He comes with plans Will can approve, not tasks Will has to design.”

Elena (Product) - strong on outcomes. Elena pushed on whether my course students could actually use what they learned. Not during the workshop. After. On their own data. She spotted that my pre-work completion rate was 53% and reframed it as a product problem, not a motivation problem.

Then she helped me design a better pre-work structure: one required deliverable, two stretch exercises, and a mid-week checkpoint for early signal on who’s falling behind.

What I learned from the calibration

Three patterns emerged across all five conversations:

1. Advisory means recommendations, not questions. “Kill the Services section on your LinkedIn” is advisory. “Have you thought about your profile?” is interrogation. Every advisor should bring specific suggestions backed by data, not open-ended questions that make you do the thinking.

2. Each advisor needs a clear boundary with other roles. Marcus kept doing accountability (the coach’s job). Ray kept assigning manual work (should be automated). Define what each advisor does AND what they don’t do. The “does not own” section matters as much as the “owns” section.

3. Voice calibration is fast and high-impact. Adding four sentences to Nora’s constitution (”Terse. Lead with the number. Cursing is fine.”) completely changed the quality of the conversation. Don’t spend hours perfecting the constitution before testing it. Build it, test it, update it. Two rounds of calibration got every advisor to a usable state.

How to build yours

1. Know your own profile. Take a DISC assessment or just be honest about your tendencies. What do you avoid? What do you over-index on? Your advisors should fill those gaps.

2. Pick 3-5 roles your business actually needs. Don’t copy my five. Think about the decisions you face. If you never make pricing decisions, you don’t need a revenue advisor. If you struggle with capacity, you do need an operations voice.

3. Write constitutions, not prompts. Identity, beliefs, decision-making approach, intellectual foundations, signature question, how they challenge you, constitutional rules. This structure gives the advisor a consistent personality across conversations.

4. Run 1:1 calibration conversations. Bring real business topics. Not “tell me about yourself.” Real decisions you’re facing right now. Then assess: was this advisory or just interrogation? Update the constitution based on what you find.

5. Hold a real board meeting. Have all five (or three, or four) read your business data and present to you. Surface disagreements. Ask questions. Decide. Save the minutes. Track the commitments.

The whole build took one session. The calibration took about 45 minutes across all five. I walked away with pricing thresholds for my next cohort, a restructured LinkedIn profile, a capacity model for my schedule, and product improvements for my course.

Not theory. Receipts.

I’m building all of this inside Claude Code. If you want to see how AI-native workflows actually work for product managers, my next cohort launches May 30. Details here.

Come back tomorrow. It has no idea who you are.

That’s the state of AI coaching right now. Every session starts from zero. No memory of what you committed to yesterday. No pattern recognition across weeks. No awareness that you said “I’ll send the proposal” four sessions in a row and never did.

I’ve been using an AI executive coach on myself every morning since March 20. Not the ChatGPT version. A system I built with real memory, real data integrations, and five coaching frameworks. It knows my patterns better than I want it to. And I’m giving the whole thing away.

Here’s how it works.

The missing ingredient is memory

Coaching isn’t a conversation. Coaching is a relationship that compounds over time. Your coach notices that every time a hard money conversation is coming up, you suddenly find a pipeline to refactor. Your coach remembers that you committed to sending three DMs last Tuesday and sent zero.

Without memory, you have a polite chatbot. The system uses three files that persist across every session. The coach reads all three before saying a word.

profile.md is your stable identity. It changes rarely. Your goals, your energy map (which work energizes you, which drains you), your data sources, your family context that affects your schedule. Mine says building and coaching are green energy. Selling and invoicing are red. That single fact shapes every session, because the coach knows to push me into the red zone first, before I retreat to what’s comfortable.

patterns.md is a behavioral pattern registry with actual frequency data. Each pattern has a first-seen date, occurrence count, specific trigger, how it shows up, and whether it’s getting better or worse. My top pattern: “Building as Hiding.” Six occurrences in two weeks. The coach names it every time. “You refactored the pipeline. Did you send the proposal?” The count matters. Session 1, it’s an observation. Session 6, it’s a confrontation.

memory.md is tiered working memory with decay. This is the piece that makes it feel like a real coaching relationship.

Three tiers: Active Context (last 2 weeks, full detail), Emerging Patterns (2-6 weeks, compressed to one line per observation), and Historical (6+ weeks, single-line summaries that never get deleted). After every session, a synthesis prompt processes the conversation and applies decay. Old items compress and sink. But here’s the key design decision: if a pattern from the Emerging tier gets new data, it promotes back to Active with full detail.

That promotion mechanic is everything. It means recurring avoidance patterns can’t hide in the archive. They resurface with their full history every time they reappear. “This is the 7th time building displaced a revenue task. Same pattern since March 20.” The coach doesn’t let you forget.

Your body knows before your brain does

Every session starts with one question: “What’s happening in your body right now? Chest, shoulders, stomach. One sentence.”

This is not optional. The coach doesn’t let you skip it with “I’m fine” or “let’s just get started.” If you give an intellectual answer (”I’m stressed about the deadline”), it redirects: “That’s a thought. What does it feel like physically?”

Over two weeks, the coach builds a somatic baseline. It tracks what your body does in specific situations and stores it in the pattern file. Mine looks like this: mid-back left side, tight knot means I’m avoiding a money conversation. Upper chest tightness means competing priorities, too many things on the plate. Grounded and neutral, feeling the chair, that’s my best execution state. On a day when I felt grounded, I completed five revenue actions before 9 AM. On a day with chest tightness, I committed to ten items and finished three.

The body gives signals 30 seconds before the brain admits there’s a problem. Jerry Colonna puts it simply: “Better humans make better leaders.” The inner work isn’t separate from the performance work. When the coach notices me tensing up while discussing an unpaid invoice, it says: “You tensed up when I mentioned the invoice. What’s the fear there?” That question would never come from a memoryless chatbot. It comes from a coach that has been tracking my body data alongside my task data for weeks.

This draws lightly from Internal Family Systems and mindfulness practice. The rational brain is not the only source of information about what’s going on.

Five frameworks, not one

I built the coach on five coaching methodologies. Different situations need different approaches, and a single-framework coach is a hammer looking for nails.

Mochary Method (Matt Mochary) handles daily accountability. Impeccable agreements, the “First 2 Minutes” technique for overcoming procrastination, energy audits, the ISP format where every problem comes with a proposed solution.

Trillion Dollar Coach (Bill Campbell) handles courage. Address the elephant first. Be the evangelist for courage. “No gap between statements and fact.” When I say I’m focused on revenue but my git log shows four hours of CI pipeline work, Campbell’s framework closes that gap.

Stakeholder Centered Coaching (Marshall Goldsmith) handles stopping bad habits. Daily Questions scored 1-10. The “What to Stop” framing. The fix for over-talking on calls isn’t “talk better.” It’s “stop talking after 3 sentences.”

The Coaching Habit (Michael Bungay Stanier) keeps the coach curious. Seven Essential Questions, always asking “And what else?” before jumping to solutions.

Radical Self-Inquiry (Jerry Colonna) goes deeper when the direct push isn’t landing. “How have I been complicit in creating the conditions I say I don’t want?” That question, applied to a pattern that’s appeared six times, hits different than a simple accountability check.

The frameworks.md file maps situations to techniques. Fear driving a decision? Mochary. Priorities unclear? Campbell. A pattern keeps recurring despite being named? Colonna. The coach picks the right tool for the moment.

Connecting your real tools

This is where the coach goes from “nice chatbot that remembers things” to “sees you clearly.”

The system can connect to your calendar, task tracker, git activity, and revenue data. You don’t need any of these. The coach works with just the memory files and a conversation. But connecting even one data source changes everything.

Here’s an example from my setup. I tell the coach I’m focused on closing three deals. The coach reads my calendar and sees zero prospecting blocks. It reads my Linear board and sees a proposal “in progress” for nine days. It reads my git log and sees four hours of CI pipeline refactoring. It puts these together:

“You say closing deals is your priority. Your calendar, your task board, and your git log disagree. What happened?”

That question can’t come from a coach working with self-reported data alone. People are unreliable narrators of their own behavior.

What you can connect:

Your calendar (Google Calendar, Outlook, a CLI wrapper). Your task tracker (Linear, Jira, Todoist, or a markdown file with checkboxes). A revenue or goal tracker (even a simple markdown file with target numbers and actuals). Your git log or activity feed, which catches the “building as hiding” pattern by showing where your hours actually went versus where you said they’d go.

Each integration is optional. Start with whichever gives you the most signal. For me, the git log and revenue tracker together were the biggest unlock. They exposed the gap between what I said mattered and where I actually spent my time.

How to get it

It’s free. No email gate. No waitlist.

Grab it on GitHub.

The repo contains:

• SKILL.md with the full coach prompt, session structure, and framework references

• onboarding.md that walks you through setting up your profile, energy map, and initial patterns

• frameworks.md with the five coaching methodologies and a situation-to-technique mapping table

• voice.md that defines how the coach talks (direct, specific, no escape routes)

• A .coach/ directory with the memory system: profile.md, patterns.md, memory.md templates, and the post-session synthesis prompt that handles memory decay

Open it in Claude Code, Claude Desktop, or any AI tool that can read local files and follow a system prompt. Run the onboarding. Start your first session.

The onboarding takes about 20 minutes. By the end, you have a profile.md and a starter patterns.md. The first real session picks up from there.

What you could build on top

The base system handles accountability coaching. But the architecture is open. Everything is markdown files. Nothing is locked.

Stress-triggered breathing prompts woven into sessions when the somatic baseline detects constriction. IFS parts work mapped to the pattern registry, so recurring avoidance behaviors connect to protector parts. Custom coaching frameworks added to the mapping table. Team coaching where multiple people share a coach that tracks who keeps missing standups and what the team says it values versus where it actually spends time.

I don’t know which of these I’ll build. But the memory system supports all of them.

If you try it, reply to this email and tell me what happened in your first session. I read every reply.