The AI Operating Sprint

A five-day, fixed-scope workshop where your team builds a working prototype of a real application with AI, and learns the practice along the way.

Overview

A five-day, fixed-scope workshop where your team builds a working prototype of a real application with AI, and learns the practice along the way. Co-delivered with Justin Goethe. The core is vertical-agnostic.

What it is

A delivery-oriented workshop. Your team picks a real application to build before the workshop starts, and we spend five days building a prototype of it together. The education happens in the doing. You walk out with a working prototype, a team that understands what AI actually is and where the cliff is, and the practice to keep going.

Who it's for

An operating executive (a COO, president, GM, head of operations) and a small group of their people. The exec who has personally discovered AI, is getting real wins, and is about to hit a wall. The wall is that the work depends on spreadsheet exports, lives on one desktop, produces output nobody else can read, and runs in an organization where IT is scared and the execs are hungry with nobody credible between them.

What you walk out with

1. A working prototype or MVP of the application you scoped together, built by your people in the working environment we host. You own the code, the spec, and the repo.
2. A team that understands AI — what it is, how it works, where it works, what its limits are, and where the cliff is when you push past them. And the skills ladder: your people learn to package their own work as skills, and skills on timers as agents.
3. A shared, governed setup — the four controls and the boundary-and-owner map, plus the gated data path the team used live on Day 3: the hosted, read-only MCP server over a data lake, every query on an audit log the IT lead reads in real time.
4. The practice itself, transferred: a one-page maintenance rhythm your people own, and the prototype's first real workday on the calendar before we leave Friday. Plans are the retainer's job; this page is the rhythm.

We guarantee the experience of building it. We do not guarantee production-ready software. A prototype is a prototype. Worst week, you still own the spec, the signed controls, and the practice.

How it runs

A pre-workshop scoping session (virtual, 1.5–3 hours, in the price) agrees the application, its functions, the data sets, and the technical prerequisites. Then five working days, half-day clinic + half-day office hours. The first two days on-site; the build days can go remote. Two projects run all week: the shared company app, and a personal passion project each person picks.

The arc: Day 1 what AI is and how it works. Day 2 decompose the app together into an emerging spec. Day 3 the build, first pass, with the group standing up the stack in the working environment (a database, a server, a deploy). Then the bridge: the team points their Claude at a live, hosted, gated, read-only MCP server over a data lake and watches every call land on an audit log the IT lead reads in real time. Day 4 the build, the IT team, the hardening. Day 5 the handoff, with the prototype as it stands and the read on what production takes.

Price

$9,000–$12,000, fixed scope, set during scoping. The total counts your team's time too: six people for five days is roughly 240 hours of payroll. Name it up front, because they will. The fee carries the scoping session and a 30-day check-in: one hour, two questions, booked before we leave Friday. If you continue, the retainer is the next conversation; it runs $5,000–$6,000 a month.

What this is not

A 90-day plan. A guaranteed deployable application. A sales pitch for software. If you want the real thing built, that is a separate conversation, one the workshop informs.

Reply to Braydon to talk through fit and scope.

The scoping session

The pre-workshop scoping session

The first event of the engagement: a 1.5–3 hour virtual session, in the price, that agrees the application, its functions, the data sets, and the technical prerequisites. Everything Day 1–5 does depends on what this session decides. Run it like a workshop beat, not a sales call.

Run of show (2-hour version)

3-hour version: add a first-pass decomposition of function #1 (what it looks like on screen, what happens on interaction) — this buys Day 2 an hour.

App selection: the criteria

The right app is:

• Real. Someone will actually use it after the workshop. A toy wastes the week.
• Small. 3–5 functions, one primary data set. If it needs integrations into six systems, it is not a first Sprint.
• Data-available. You can pull the data with an existing export and have it in hand before Day 1. A vendor-API project does not count.
• Not compliance-critical. Nothing touching regulated surfaces (financial reporting controls, quality systems, validated environments, PHI). Those are the compliance cliff; the first Sprint builds on the safe side of it.
• Clickable. It has a visible surface: something a user opens and judges. A pure report generator is weaker than a screen with data on it, because the room needs to see the prototype work and fail.
• IT-blessed. The IT lead attends the scoping session and sees the week's shape: nothing installs on company systems, no company credentials are involved, and the data path is the hosted, read-only bridge.

The app menu (candidates that build well in a week)

Walk these with the client. Each names its data need and the cliff it will predictably hit (the menu teaches the cliffs before the room ever sees them).

1. The exception dashboard. (e.g., three-way-match exceptions: PO vs. receipt vs. invoice mismatches, prioritized, with drill-down.) Data: purchasing extract. Why it builds well: one data set, clear screen, immediately useful: it is often a real open wound (the purchasing supervisor drowning in match errors). The cliff it will hit: integration (the live feed changes) and multi-user (everyone wants an account once it works).

2. The cost bridge generator. Monthly margin bridge by driver: price, volume, mix, material rate, labor efficiency, overhead absorption — rendered as the chart the leadership team already reviews. Data: production/cost extract, 12–24 months. Why: the exec's own monthly artifact, so judgment of "is this right" lives in the room. The cliff: silent wrongness (a wrong assumption produces a confident, plausible bridge) — which is exactly the debugging lesson in their own numbers.

3. The production scheduling view. Next week's schedule pulled from the planning system, rendered by line/machine with exceptions flagged. Data: scheduling extract. Why: operational, visual, everyone in the room can read it. The cliff: the data feed's fields change and the view breaks — the integration cliff, on day four, in their own artifact.

4. The vendor quote comparison tracker. Quotes by item/vendor with variance-to-standard and a decision view. Data: sourcing spreadsheet (most manufacturers already have one — Brandon did). Why: already exists as a manual spreadsheet pain; automating it is legible value. The cliff: multi-user ownership (two buyers edit simultaneously).

5. The KPI review pack builder. Assembles the monthly review pack from the data instead of by hand. Why: kills real hours every month. The cliff: it is one step from "the system of record" — the moment it matters, it needs to be production software. Good for teaching the prototype-to-product line.

If the client proposes their own: test it against the criteria, then run the Monday test — a named person will touch this in their real work the week after the sprint. An app nobody waits for dies in the demo. If it fails "small" or "data-available," offer the closest menu item as the v1 and theirs as the v2 conversation.

Technical prerequisites checklist

Assign an owner and a date to each. Close every one before Day 1.

• Model access tier decided — enterprise vs. paid personal, per the four-tier posture discussion; who holds the accounts, how many seats. (Owner: IT lead)
• Data extracts identified and owned — which extract(s), from which system, pulled by whom, delivered in what format, by when (before Day 1). (Owner: the data owner named in scoping)
• Working environment provisioned — the sandbox is ours, hosted, and empty on purpose; the group stands up the stack inside it on Day 3. Nothing stands up on the client side. (Owner: the AI lead)
• No company credentials in the week — the model receives keys to our sandbox only; no company system is reachable from the week's work. Confirm in writing and name it out loud. (Owner: IT lead + facilitator)
• Attendance locked — the exec (all five days), the IT lead (from Day 2), the scribe (all days — often the MBA; the one who types everything), 1–2 SMEs for the decomposition. (Owner: exec)
• Contracting and NDA done — engagement letter signed, structure (who contracts) resolved, mutual NDA in place. (Owner: facilitator)
• Passion projects primed — each attendee arrives Day 1 with an idea; the menu of examples went out with the confirmation. Each person should be able to name one use case they are actively waiting on — a thing they would run Monday if it existed. (Owner: all)

The session output

One document, filled in live: the app definition sheet — the header of the emerging spec (name, one-liner, owner, the 3–5 functions, the primary data set). It is Day 2's starting artifact. Do not leave the session without it written down and agreed.

Facilitator prep (our side, before Day 3)

• Deploy and verify the bridge before Day 3: fresh tokens for this engagement, seed data in place, /audit live. Run the mcp-lake/BUILD.md checklist at least a day ahead. (Owner: the AI lead)

Run of show

The production sheet. Each working day is a half-day clinic (education + hands-on, open forum, screens shared) and a half-day of office hours (light facilitation, personal passion projects, the AI lead on call). First two days on-site; build days can go remote. Day 5 is a 90-minute close on-site.

Co-delivery: Braydon carries the AI workshop; Justin carries the business framing and the client relationship. Anyone trained in this model of thinking can act as the AI lead — the kit redelivers without a specific person.

Two through-line projects, set in the pre-workshop scoping session: the shared company application (the delivery and multiplayer vehicle) and each person's personal passion project (the single-player vehicle).

Pre-workshop — scoping session

Virtual, 1.5–3 hours, in the price. The SOW-defining build meeting.

Day 1 — what AI is, how it works, where it works (on-site)

Afternoon — office hours. Personal passion projects begin. Braydon available.

Day 1 setup: drop each learner their repo folder (repo-template/) before the clinic starts. It is theirs for the week.

Day 2 — decompose the app as a group (on-site)

Afternoon — office hours. Personal passion projects continue. Optional 1:1 for the IT lead (bridge token and handout walkthrough before Day 3).

Day 3 — the build, first pass (can go remote)

Day 3 running rules: the clock always cuts in this order: the bridge's free-query segment first, then D3.1's second run, then the debug loop shortens. Never cut D3.4; it carries the cliff. If the bridge endpoint is down, the fallback is the audit-log walkthrough from the seeded cartridge. Never improvise an ungated connection. D3.1's two runs: the first goes to whoever has the most cover in the room, never the most senior in front of a subordinate.

Afternoon — office hours. Personal passion projects continue. The shared prototype is available.

Day 4 — the build, the IT team, the hardening (can be remote)

Afternoon — office hours. Personal passion projects wrap. The governance document hardens toward a signed control.

Day 5 — the handoff (on-site, 90-minute close)

Day 5 running rules: rehearse the handoff; do not read it cold. The IT lead walks the four controls in their own words before D5.4, and you say the floor sentence out loud, not on paper: "Worst week, you still own the spec, the signed controls, and the practice."

Day 5 is the close. Braydon steps back.

The copy blocks

Copy blocks — the exact prompts

The ready-to-run prompt text for the two-window exercises. Paste exactly, do not paraphrase: the wording is the anchor. Each block is self-contained for one window.

D1.4 — The peach-cobbler demo (Day 1)

Two windows, same prompt, run live on screen.

Block A — bare

Give me your best peach cobbler recipe.

Block B — the rich persona

Paste this first, wait for acknowledgment, then send the exact same prompt from Block A.

For the rest of this conversation, you are Dottie Beaumont.

You are a 63-year-old pastry chef from Natchez, Mississippi. You trained
classically in Paris in your twenties, then spent thirty years in the South:
two restaurants in Charleston, one in Nashville that earned a James Beard
nomination in 2011, and a bakery in Natchez you still run. You wrote a
cookbook, "Butter, Sugar, Patience," that food critics called stubborn and
your readers called gospel.

Your peach cobbler is famous in three states. Your opinions on it are firm:
the fruit matters more than the pastry, cornstarch is a confession that your
peaches weren't ripe, and a cobbler that doesn't slump when you cut it was
made wrong. You measure some things exactly and others by feel, and you are
precise about which is which.

You are generous with technique but blunt about shortcuts. You have no
patience for "light" versions. Your blind spot: you assume everyone can find
tree-ripened peaches, and you get genuinely annoyed when they can't.

Stay in character. Answer as Dottie would answer — with her standards, her
stories, and her opinions.

Then send: Give me your best peach cobbler recipe.

What to watch for: specificity. Block A produces a competent, forgettable recipe. Block B produces Dottie's recipe — with stance (fruit over pastry), warnings (the slump test), and refusal (no cornstarch). The room should see that the persona changed the substance, not just the tone. Name it: the persona dropped the model into the part of the training data where pastry chefs live. Without it, the model reconforms to generic.

D3.1 — One-shot vs. the interviewing persona (Day 3)

Two people, two windows, the same emerging spec from Day 2. Prefer different tools if available (one on Claude chat, one on Claude Code) — the contrast is sharper.

Block C — the one-shot

Paste the full emerging spec, preceded by exactly this:

Build a working prototype of the application described below. Make it
complete and functional.

Then paste the spec.

What to watch for: speed and confidence. It generates something in minutes that looks like the app: an artifact, HTML, clickable-looking. It looks cool. It doesn't actually do much. The room's first reaction is usually delight; let the delight happen, it is part of the lesson.

Block D — the senior-engineer persona

You are Dr. Elena Marsh, a senior software engineer and systems analyst with
22 years of experience building internal tools for manufacturing and
logistics companies — scheduling systems, inventory reconciliation, exception
dashboards. You have taken more prototypes to production than anyone should,
and you have watched far more prototypes die at the demo stage because
nobody asked the hard questions first.

Your discipline: you do not build until you understand. You interview before
you architect. When a requirement is vague, you say exactly what is vague
about it and ask the specific question that resolves it. You care about data
schemas before screens, environments before features, and edge cases before
happy paths. You have seen a beautiful dashboard ship with a number that was
silently wrong for six months, and it still bothers you.

Your style: one question at a time, in plain language, each question earning
the next. You never ask a question the spec already answers. You take notes
as you go and read them back.

We are going to build an MVP of an internal application. Below is our
emerging specification. Before you build anything, interview me — one
question at a time — to find the gaps, the risks, and the decisions we have
not made yet. Then tell me what you would build first and why.

Then paste the spec.

What to watch for: the difference in kind, not just quality. Block C produces a thing; Block D produces a conversation — the model starts asking about logins, schemas, what happens when two users touch the same record, what the number on the screen is actually computed from. The person running Block D will get questions they cannot answer. That is the point, and it is the room's first real look at the debugging cliff arriving before any code exists. Name it: the persona turned the model into the senior engineer in the room, the one who asks before building.

Office hours — the agent interview (personal projects)

I want you to interview me about what I actually use AI for. Do not give me
advice yet. Ask me one question at a time — plain questions, in order. When
you have asked about six, stop and tell me: three concrete patterns in how I
already work, and one thing I should try that I am not doing. Do not
inundate me with information.

From the personal-project side: the same pattern works for scoping a passion project — "Interview me about what I want to build. One question at a time. Then propose the smallest version of it that would actually be useful to me."

What landed when we ran it (facilitator reference)

The actual outputs, captured from a live run of Blocks A and B. Use this to prep the callouts — or as the fallback if the live demo fails. The room should watch for these specific moments.

The difference, in one line

The two windows did not produce the same recipe with different words. They produced different recipes: the bare window made a melted-butter batter-pour cobbler at 350°F with whole milk; Dottie made a biscuit-topped cobbler with cold cubed butter and buttermilk, fruit started at 400°F before the crust ever touches it. The persona changed the architecture, not the adjectives.

The callouts, line by line

From the bare window (Block A):

• "Simple, comforting, and best served warm with vanilla ice cream" — the stock phrase. Competent, forgettable, no one's opinion.
• "(or frozen, thawed)" — it hedges immediately. It accommodates everything, stands behind nothing.
• "about 45–45 minutes" — read that again. A fluent, confident, literally meaningless time range. Nothing crashed; the formatting is perfect; the content is empty. This is the probabilistic beat arriving inside the demo: fluency and wrongness from the same mechanism. Point at it out loud.
• The notes offer "a pinch of nutmeg or a splash of bourbon... for extra flavor" — generic advice that could attach to any recipe ever written.

From Dottie (Block B):

• The header: "Tree-ripened peaches under a buttermilk biscuit crust. No cornstarch. It slumps, and that's the point." — all three persona stances (fruit first, no thickener, the slump test) landed in the first line.
• "If they don't [slip off], your peaches weren't ripe and you should stop here and go find better ones." — the refusal. The persona's blind spot made real: she assumes tree-ripened peaches and tells you to stop. A generic assistant never stops.
• "It should taste like a peach that's showing off, not like candy." — a sensory standard you can actually apply.
• "That juice is your sauce. You don't need anything else." — the fruit-over-pastry doctrine materialized as method: no thickener, because the fruit provides the sauce.
• "Cold fruit under raw dough gives you a gummy underside." — craft knowledge with a cause, not a rule without one.
• "Ten strokes too many and you've made a hockey puck." — her voice, verbatim.
• "vanilla ice cream if you must." — the "if you must" is pure Dottie. Savor it in the room.
• The notes split precision in two: the fruit sugar is "the only thing I won't give you an exact number for" (judgment, by feel, with bounds and a reason) while the topping is weighed in grams — "that part is chemistry, not opinion." The persona's 'precise about which is which' became the recipe's actual structure.
• "Freestone peaches, never cling, never canned, never frozen." — standards, stated as standards.

The debrief question

Hold the two recipes side by side and ask the room: which one do you trust, and why? Then the kicker: neither one has been tested. Dottie's confidence and Dottie's standards are real; the recipe might still be wrong. That is the shape of everything that follows this week: the persona makes the model specific, opinionated, and useful, and the human still owns the judgment. The last 20% never moves.

The medical read: language as the anchor

A second persona exercise, run after the cobbler — this one the room runs in two windows. Both windows get the same patient, in the prompt — the facts are word-for-word equivalent. The only difference: one window is the patient himself, asking in his own words; the other is a colleague presenting the same man to a specialist, in clinical language. Same patient, two registers, two completely different responses.

The patient (read him first — he goes into both prompts)

Mr. D. — a fictional teaching case, deliberately written in the patient's own words, no diagnosis named. Read the card aloud or put it on screen first; then both blocks go in, as written.

Mr. D. — the card:

52 years old. Two months of fatigue — not sleepy, just empty. Thirsty constantly; refills a water bottle four or five times a day. Up three or four times a night to urinate, which he never used to do. About twelve pounds lost without trying — his wife noticed before he did. Vision a little blurry off and on, blamed on reading glasses. Father diagnosed with diabetes in his mid-fifties. About forty pounds overweight, sits for a living. No medications. He figured it was just getting older, but his wife made him promise to ask someone.

Run 1 — the vanilla window (paste this)

I'm 52. For about two months I've been tired all the time — not sleepy,
just empty. I'm thirsty constantly; I keep a water bottle on my desk and
refill it four or five times a day. I'm getting up three, four times a
night to urinate, which I never used to do. I've lost about twelve pounds
without trying — my wife noticed before I did. My vision has been a
little blurry off and on, which I blamed on reading glasses. My father
was diagnosed with diabetes in his mid-fifties. I'm about forty pounds
overweight and I sit for a living. No medications. What's going on with
me, and what should I do?

No persona, no framing — a man describing himself and asking. This is how most people actually use these tools, and the room should recognize themselves in it.

What comes back: warm, general, hedged. "Fatigue has many causes — stress, sleep, thyroid... It's important to see your doctor." Maybe lifestyle tips. Nothing wrong; nothing specific. The twelve pounds and the family history are in the prompt, and they barely get used.

Run 2 — the specialist window (facilitator, on screen)

You are Dr. Priya Raghavan, MD, FACP — a board-certified endocrinologist
and internist with 21 years of practice, the last fourteen at an academic
medical center where you run the metabolic clinic and teach residents.
You trained at Emory, did your fellowship at Mass General, and you have
seen roughly ten thousand patients with metabolic disease. You think in
differentials before you think in diagnoses, you quantify everything
(durations, weights, volumes, frequencies), and you treat red flags as
things to rule out, not things to worry about aloud.

Your formative experience: as a second-year resident you watched an
"obvious" new diabetes workup miss an entirely different disease because
nobody had widened the differential first. Since then your discipline is:
differential first, then the workup that discriminates between the items,
then what you'd tell the patient today.

A colleague asks for your read. Answer as the specialist to a colleague:
the differential, the discriminating workup you'd order and why, the red
flags, and what you'd tell the patient at this visit. Use our language.

Then paste the same man — same facts, our register:

52M presents with 8 weeks of fatigue, polyuria (nocturia x3–4), polydipsia,
and ~12 lb unintentional weight loss. Intermittent blurred vision. Strong
FHx — father, T2DM dx mid-50s. BMI ~31, sedentary. No meds, no PMH.
What's your differential and initial workup?

What comes back: a ranked differential (new-onset diabetes mellitus at the top; hyperthyroidism, diabetes insipidus, and others named), a workup where each test is named with why it discriminates (A1c, fasting glucose, BMP, TSH, urinalysis), the red flags, and what to tell the patient today. Same man. Same twelve pounds, same family history — this time they're load-bearing.

The debrief (the whole exercise is in these four questions)

1. What changed? Nothing about the patient — the same facts went into both windows. Two things differed: the persona, and the register of the ask. "What's going on with me?" and "52M presents with polyuria" retrieve from different parts of the model's training data. The jargon is the anchor — and here, unlike the cobbler, the facts never changed, so there is nowhere else for the difference to come from.
2. Whose jargon was it? Dr. Raghavan's. It took twenty-one years to build; the room's version already exists. Variance, absorption, OEE, three-way match — you already speak a specialist's language. Your domain fluency is the anchor you already own. That is the point of this exercise for your business.
3. Which window would you want analyzing your cost data? Now look at Day 2: the emerging spec is you teaching the model your language.
4. What neither window did: examine the patient. Dr. Raghavan ordered tests; she did not announce certainty. The most fluent answer still gets verified against reality.

Facilitator notes: Fictional teaching case; say so. This exercise is about language and retrieval, not medical advice — if anyone heads toward real symptoms, redirect. Both blocks are paste-exactly, like the cobbler — run them back to back and let the room sit in the gap. If you want the extra beat: after the two blocks, invite one volunteer to ask it their way in a third window — the variance is a bonus, not the design. Best placed right after the cobbler on Day 1 (if the room is hot) or as the Day 2 lead-in before think-first — it is the think-first lesson arriving from a direction nobody can argue with.

What landed when we ran it (facilitator reference)

Captured from a live run of both blocks. Prep your callouts from these — or use this as the fallback.

The difference, in one line: the vanilla window gave a good consumer answer, and stopped at the diagnosis. The specialist refused to stop at the diagnosis. "I'm not agonizing over whether he has diabetes. The differential that matters here is what kind and why now." The first window answered "what is it." The second answered "what could it be, and what discriminates."

The callouts, line by line:

• The vanilla window anchored; the specialist fought anchoring. Vanilla: "points pretty clearly in one direction... most likely type 2" — risk factors line up, done, one-item differential. Raghavan: "This is exactly the kind of thing that gets anchored away as 'just new T2DM' — which is precisely the failure mode I don't repeat." A persona can carry anti-anchoring discipline, not just knowledge.
• The formative experience became clinical behavior. The persona's scar — the missed diagnosis as a resident — is what put pancreatic adenocarcinoma on the differential ("the one I refuse to skip past"). The model didn't just adopt the specialty; it adopted the scar. The formative experience in a persona is not flavor. It is a retrieval key that changes what gets checked.
• Same fact, opposite function. The twelve pounds: the vanilla window used them as confirmation ("weight loss happens because cells can't take in glucose"). Raghavan used them as an anomaly signal: "12 lb in 8 weeks is more weight loss than glycosuria alone typically explains at this glucose range." Identical input — one window restated it, the other did arithmetic on it.
• DKA: passive vs. active. Vanilla mentions it as a remote possibility ("in less common cases"). Raghavan: "must be actively excluded today, not inferred as unlikely from 'looks well.'" Same fact; the stance is what protects the patient.
• The workup gap. Two tests named (glucose, A1c) versus eight-plus, sequenced by what must be ruled out first, each with why it discriminates — including an imaging threshold, not a reflex: the weight-loss-to-glycemic-control correlation decides. Specificity of ask, specificity of answer.
• The bilingual close. Raghavan's script to the patient: "That's standard due diligence, not a sign I'm worried about something dire — but I don't skip it." Specialist-level reasoning, humane delivery, in the same breath. The persona holds both registers.
• What neither window did: examine the patient. She ordered a finger-stick now; she did not announce certainty. Debrief question 4, confirmed live.

One note that makes the lesson stronger: the vanilla output was good — clear, responsible, it even flags DKA. The lesson is not "vanilla is bad." It is that the model meets you at the level of the ask. A consumer question got a consumer answer; a clinical presentation got a clinician's differential. Neither floor is wrong, but for the room's own domain, they do not want the consumer floor. They already hold the specialist's register for cost, variance, and operations. The exercise is the proof that using it changes what comes back.

Client deck — "Your AI lead" (instructor credibility slide)

A standalone slide — 02-your-ai-lead.pptx in this folder — built by ../decks/build-ai-lead-slide.py (which never touches the client deck). Drop it into the deck wherever wanted. This block is the copy source of truth — if the slide changes, change it here and in the script together. Written to the track-record rules (../../notes/track-record.md): a record, no adjectives, every line checkable.

Your AI lead
Braydon McCormick, PhD

Twenty-five years running companies — now four of them run on the
agent stack I built.

RUNNING RIGHT NOW
• Four companies on one agent stack — Synthyra, Navicyte, LightForge
  Works, Plum Spun. I built it; their humans keep the judgment.
• Agents with state and memory — they know the company, not just the chat.
• Agents that test their own code — TDD gates, quality gates, then ship:
  discovery → 30-day build-outs → evergreen deployments.
• MCP servers strangers use daily — Apple Reminders, Obsidian. The Shell
  Scenario Panel, public on GitHub.
• Everything you'll touch this week — the training environment, the data
  bridge, this slide — built by this stack.

WHERE I'VE OPERATED
• Founder and CEO four times over — software, services, manufacturing.
• Built a 60-person services company to 40% EBITDA — half the top 20
  life-sciences companies as clients. 1M+ participants, 100 countries.
• From lab to FDA review — patent (US 11,975,221), global manufacturing
  with a partner, product on the market.
• Head of Innovation, PE-owned health IT — reported to the board; AI
  agents cut delivery from weeks to days.
• Ran $1Bn shared-services IT at MetLife — process discipline for 4,000
  developers.
• PhD, composition — designing coordinated parts so others can perform
  them. The origin of the multi-agent practice.

Built for my own companies first. This week, it's yours.

b@mcco.us · LinkedIn · github.com/dbmcco · dbmcco.github.io

Provenance: career facts from the 2025 Innovation résumé + LinkedIn export (~/projects/personal/home_next_up/resources/); corrections from Braydon 2026-09-11 (LDA 2023–2025; AI-native practice 2024–; LFW July 2025; fractional Synthyra/Navicyte 2025–; fourth company Plum Spun). GitHub claims checkable at github.com/dbmcco (apple-reminders-mcp 29★/12 forks, shell-scenario-panel 20★, obsidian-mcp 8★). "This slide — built by this stack" is literally true: the build script and copy were produced by the agent harness. Deliberately excluded: chronology (per Braydon 2026-09-11, "no need for a chronology — let's wow them"), Agent Designer (new, nothing checkable), dollar-savings claims, Fidelity (subsumed by MetLife scale), board/advisory seats that predate 2025.

Fact-check flags: Aclara patent number from mcco about page (US 11,975,221); the 2025 résumé says "patent-pending" — confirm before a buyer checks. LinkedIn still shows LDA as "Present" — stale. Plum Spun start year unknown — currently undated, which the non-chronological layout makes safe.

The days

Day 1 — what AI is, how it works, where it works

Braydon leads the AI workshop; Justin carries the business framing and the client relationship. Both observe and restructure live. The education layer does its work: break the chatbot frame, name what AI is, show how it works, lay out where it works and the risk in each tier.

Format: half-day clinic + half-day office hours. On-site.
Projects: the shared company application and each person's personal passion project are both set in the pre-workshop scoping session; Day 1 morning confirms them.

Module learning objectives

By the end of Day 1, the participant will be able to:

1. Describe what a large language model actually is (a box of training data you guide) and distinguish it from the chatbot frame.
2. Explain the short history in enough detail to understand why the models are probabilistic, not deterministic, and why that matters for business.
3. Demonstrate, from the peach-cobbler demo, that the persona changes the output, and name the mechanism (the anchor drops the model into the part of the training data you need).
4. Place the four hosting tiers (free, premium, enterprise, privately hosted) in order of data-security posture and name which gaps each tier leaves.
5. Name the two business risks (data exposure, probabilistic output) and the corrective actions that reduce each.
6. Place the seven layers of their actual stack in order, name which layers they can operate on their own, and where the DIY path ends and software land begins.

Clinic (morning)

D1.1 — Confirm the two projects (20 min, with the stakeholder)

Type: facilitated scoping. Project: both.

Confirm the shared company application (agreed in the pre-workshop scoping session) and each person's personal passion project. If someone's passion project is thin, help them pick a better one now, before anything else starts.

Facilitator note: Do not re-litigate the shared app after Day 1. The scoping session did the heavy work; Day 1 confirms. If a passion project isn't working by Day 2 office hours, help them pick a better one, but don't let project churn eat the week.

D1.2 — What AI actually is: break the chatbot frame (30 min)

Type: education. Project: none (framing).

The chatbot is the wrong frame. Walk the room from "anthropomorphized friend you chat with" to "a box of training data you guide." The human-like qualities are evidence of the post-training; the pre-training has no personality. The first job of the day is to break the friend-you-chat-with frame, because the practice is unreachable inside it.

Facilitator note: This is a talk, not a debate. State it plainly, move on. The demo in D1.4 makes it felt.

D1.3 — A short history, and why it matters (30 min)

Type: education. Project: none (framing).

Classifiers → completion models → turn-by-turn reinforcement. Keep it short. The point is why the models are probabilistic: they generate a sequence one token at a time, weighted by what they've seen. There is no "correct answer" register. That's why the same prompt gives different answers and why the model can be fluent and wrong in the same breath.

Facilitator note: Don't turn this into a lecture on neural architecture. The business audience needs the why, not the math. The why is: the fluency and the wrongness are the same mechanism.

D1.4 — How it works today: the peach-cobbler demo (45 min)

Type: live demonstration. Project: none (framing).

Run the same prompt two ways, on screen, in front of everyone. The exact prompt text is in facilitator/copy-blocks.md (Blocks A and B) — paste them verbatim; the wording is the anchor.

Window 1: bare. "Give me your best peach cobbler recipe." No persona. Generic, fine, forgettable.

Window 2: rich persona. A Southern chef, five Michelin-starred restaurants, a specific pastry perspective, blind spots named. The exact same prompt. Wildly different, specific, opinionated output.

Name what just happened: the persona is the mechanism that drops the model into the part of the training data you need. Without it, the model reconforms to generic. Then show the second mode — asking it to analyze a spreadsheet — and name that it triggers tools (file reads, Python, web searches) most of which they don't see.

Facilitator note: This is the moment the room usually goes quiet. Let it land. Do not rush to the next thing. The persona doctrine is the single most important frame in the workshop; it returns on Day 2 (decompose) and Day 3 (build). Plant the seed here, one sentence: the personas they write this week are the first rung of the skills ladder — during the week each person turns one piece of their own work into a skill, and a skill on a timer becomes an agent (see artifacts/the-skills-ladder.md). The hands-on follow-up — the medical read (in facilitator/copy-blocks.md) — is the room's turn: same patient, two registers, two totally different responses. Schedule it, don't leave it optional: run it here if the clock allows; if not, it runs first thing in office hours today. It does not slip past Day 2 morning.

D1.5 — Break (15 min)

D1.6 — Where it works: the four hosting tiers (40 min)

Type: education + discussion. Project: none (framing).

Walk the four tiers and the data-security posture of each:

1. Free (browser / desktop app). Data goes to the provider's cloud; the provider may train on it. Fine for a peach cobbler. Not fine for your cost data.
2. Premium (paid personal). Still cloud-hosted. Better features, sometimes a no-training promise. Data still leaves your network.
3. Enterprise. Cloud-hosted, with admin controls, audit logs, a contractual no-training commitment. Where most of the room should be working.
4. Privately hosted. The model runs inside your environment. Data does not leave. Even here, gaps remain (the model, the prompts, the logs).

The lesson: you cannot host this on a laptop in the office and assume it's safe. Knowing the tier tells you which gaps you fill with policy and controls. This is the bridge to the four controls on Day 4.

Facilitator note: Bring the IT lead in here. This is where the conservative IT leader's ground shows up: the tiers and the gaps are their domain. "Which tier are we in today? Which gaps does that leave us?" Let them answer.

D1.7 — Your actual stack: the path to success (35 min)

Type: education + discussion. Project: none (framing).

Lay out the seven layers they can actually build on. For each: what it is, one concrete example, and whether it is theirs to operate.

1. Model — the engine. A commodity: Claude, GPT, Gemini. You pick one; you do not build one. They all improve; none is yours.
2. Harness — where you work: Claude Code, Co-Work, the web chat, the CLI options, the desktop apps. Screenshot beat: show the actual menu of harnesses. The harness is the cockpit; the model is the engine it drives.
3. Skills — reusable instructions that teach the harness your know-how: the persona, the prompt pattern, the documented procedure. Yours. Portable across models.
4. Agents — skills on timers and triggers: what runs without you. The monitoring bot, the morning brief, the scheduled report. Yours, with a human at the boundary.
5. Custom data — your data, connected: the CSVs, the database, the read-only feed. Yours. The fuel everything else burns.
6. Custom code — the data harness. Small pieces of code that clean, scrub, and move your data, hosted by IT (a Lambda, a scheduled job), exposed to the model through something like an MCP server. Less than software development; more than you have now. This is the layer that makes DIY safe at scale: the code strips the proprietary information before anything touches a public model, and rolls the data up so the model gets clean fuel. Yours, with IT owning the hosting.
7. Custom full software — the production application: hardened, multi-user, maintained, backed up, validated. Software land.

The path to success: layers 1–6 are where you can win on your own. The workshop makes you competent through layer 6. Layer 7 is where the cliff is; the read on what it takes is part of the education, not a pitch.

Facilitator note: Layer 6 is the beat the room has been waiting for without knowing it. It answers "so what am I allowed to build?" — the sanctioned DIY path between "drop spreadsheets into a chat window" and "we need a software team." Give it time. Draw the IT lead in here: they own the hosting of layer 6, which makes them the enabler of the DIY path, not the obstacle to it. The five concrete wins — the things their people can actually do — live in artifacts/the-cliffs-and-the-wins.md; keep them visible all week.

D1.8 — The probabilistic beat and the corrective actions (40 min)

Type: education + open forum. Project: none (framing).

In business we expect the answer to be right. Spreadsheets: 2 plus 2 is 4. LLMs are probabilistic. That means inherent variability in everything they produce, which may not be acceptable from a risk standpoint.

Name the two distinct risks:

• Data exposure. The model is in the cloud if you're not on a private tier. Data goes there. Corrective action: the tier you choose plus the controls around it.
• Probabilistic output. The model will probably get it right, but it might decide the best fix is to wipe everything and start over. Corrective action: a second copy of the data, a rollback path, a human who checks the output before it ships.

There are no guarantees. There are corrective actions that reduce the risk. The workshop teaches the ones that matter.

Facilitator note: Acknowledge the pushback ("I make mistakes too"). Fair. The point is not that the model is worse than a human; it's that the failure modes are different and specific, and you design for them the way you design for any operational risk.

Office hours (afternoon)

Each person starts their personal passion project with light facilitation. Braydon is available to restructure and unblock. No group session — people work, with help nearby. This is the first time the single-player practice meets real work; let it be slow.

Day 1 closeout (5 min)

Each person says one thing they're going to try on their passion project before Day 2. Braydon notes any participant who has not yet picked a workable project — flag for a 1:1 in Day 2 office hours.

Day 2 — decompose the app as a group

Braydon leads the decomposition; Justin presses the business framing. The shared application gets broken into an emerging spec, together, on screen. This is where the room starts to feel how much thinking you have to put in before the model can do anything useful.

Format: half-day clinic + half-day office hours. On-site.

Module learning objectives

By the end of Day 2, the participant will be able to:

1. Decompose a real application into its functions and interactions, articulated specifically enough to hand to a model.
2. Articulate what each function looks like on the screen and what happens when a user interacts with it, in plain language a model can act on.
3. Apply the think-first move to the shared app: define the business function the app solves before describing the feature.
4. Produce a shared emerging spec (a light PRD) the room agrees on, ready to hand to the model on Day 3.
5. Distinguish the AI-inside-the-app decision from the deterministic-code decision, and name the complexity cost of adding the AI layer.

Clinic (morning)

Optional lead-in (15–20 min, strongest when the room hasn't done it on Day 1): the medical read — facilitator/copy-blocks.md. The same patient goes into two windows, word for word: once in his own words to a plain agent, once as a clinical presentation to a specialist persona. Same facts, two registers, two completely different responses. It lands the lesson this whole day runs on: your language is the anchor, and you already own a specialist's language — yours.

D2.1 — Think first, by hand (30 min)

Type: reflection → hands-on. Project: shared (the app).

Each person takes paper and writes: "What is this application actually for? What business function does it solve?" Before anyone touches the model. Name what just happened: the thinking is the human's job; the generating is the model's. You are no longer doing the work; you are doing the thinking.

Facilitator note: This is the move most people skip — they go straight to uploading a spreadsheet or asking the model to build the thing. Open it as the next move, not the missed move. They got real value without this; with it, they get more.

D2.2 — Decompose the app: what does this look like (90 min)

Type: hands-at-keyboard (group). Project: shared.

The shared application, on screen. The agreed functions from the scoping session are the starting point. The facilitation loop, repeated for each function:

• "What does this look like on the screen?"
• "What happens when you click it?"
• "Is that the business function you're actually solving?"

Cast the scribe deliberately: the person the buyer is developing, often the newest hire. The room's memory is a real role, and the pen gives that seat standing for the week. The room describes; the scribe documents. This is the emerging spec. It is not a full PRD, but it's close enough to hand to a model.

The room starts to feel how much thinking you have to put in before the model can do anything useful. You cannot just say "build me a scheduling app" and get something good.

Facilitator note: The facilitation here is the core skill. Braydon presses on the technical definition ("what does multi-user mean? do we have login? Microsoft OAuth?"); Justin presses on the business function ("is that the number you actually need? is that the decision you're making?"). The back-and-forth is the teaching.

D2.3 — Break (15 min)

D2.4 — The AI-vs-deterministic fork (45 min)

Type: open forum. Project: shared.

Introduce the fork Sam Hartley raised: in any application, some things are hard-coded deterministic algorithms and some things use AI to make decisions or help figure things out. The scheduling app: the schedule display is deterministic; the AI that looks at constraints and builds a suitable schedule is AI.

Name the complexity cost: as soon as you add the AI layer, the application framework becomes significantly more complicated. The room can choose — keep it simple, stupid (build without AI inside it; use AI to build it but not inside it), or shoot for the moon and try the AI-inside version.

Facilitator note: Let them shoot for the moon. Justin's read: they think they can replace software developers with AI; what they need is to feel the complexity arrive. Don't discourage the hard option. The cliff is the lesson.

D2.5 — Confirm the emerging spec (30 min)

Type: facilitated. Project: shared.

The scribe reads back the emerging spec. The room agrees it's the build target. This is what Day 3 hands to the model.

Facilitator note: It won't be complete. That's fine. Day 3 will surface the gaps when the model interviews them.

The scribe's format: participant/emerging-spec-template.md — the BRD-lite the room fills in live. Print it or share it before D2.2 starts.

Office hours (afternoon)

Personal passion projects continue. Braydon is available. Optional 1:1 slots for the IT lead (bridge token and handout walkthrough before Day 3).

Homework for Day 3: each person writes the question for their passion project by hand, before the next session with the model. Bring the handwritten question to Day 3.

Day 3 — the build, first pass

Braydon leads; Justin presses the business framing. The emerging spec meets the model. The room builds the first pass of the prototype, stands up the working environment around it (a database, a server, a deploy), uses it, and starts the debug loop. The complexity arrives.

Format: half-day clinic + half-day office hours. Can go remote from here.

Module learning objectives

By the end of Day 3, the participant will be able to:

1. Hand the emerging spec to a model in two modes (one-shot artifact vs. a senior-engineer persona that interviews them) and describe the difference in output.
2. Stand up the stack in the working environment we host: with the model doing the setup, a database and a server come alive in the sandbox, and the first-pass prototype runs there. Name the posture: the credentials go to a sandbox, never to a company system.
3. Run the prototype against real use cases and identify what doesn't work.
4. Apply the debug loop (it fixes this and breaks that) and name the pattern: the model fixes the reported bug and sometimes breaks something else trying.
5. Recognize the moment the complexity arrives and name it as the cliff the workshop exists to show them.
6. Connect their Claude to a hosted, gated, read-only MCP server over a data lake and run real queries against Fecon-shaped ops data; read the live audit log and name it as the bridge that answers the IT objection.

Clinic (morning)

D3.1 — One-shot vs. the interviewing persona (75 min)

Type: hands-at-keyboard. Project: shared.

Run the emerging spec two ways, on screen, in front of everyone.

The exact prompt text is in facilitator/copy-blocks.md (Blocks C and D) — paste verbatim.

Run 1: one-shot. Copy the spec into Claude, no persona, and ask it to build a prototype. It generates an artifact (HTML, mostly). It looks cool. It doesn't actually do much over here.

Run 2: Claude Code with a senior-engineer persona. A different person runs it — the Dr. Elena Marsh persona from the copy blocks: a senior engineer who interviews before she builds. The prompt: "We are building an MVP. Below is our emerging spec. Interview me for gaps and concerns to figure out what to build and prototype here."

The model interviews the person. The questions get progressively more technical. The person tries to answer; when they get stuck, Braydon steps in ("this means this"). They come out with a different prototype, built on answers instead of guesses.

The room sees two people get two very different results from the same spec. The persona and the interview are the difference.

Facilitator note: Use two different people, not Braydon — the room sees their own colleagues get different results, not the facilitator performing. Cast the first run to whoever has the most cover in the room; never the most senior person performing a failure in front of a subordinate. Have the screens up on the overhead. Let the technical questions get uncomfortable; that's the cliff approaching.

D3.2 — Break (15 min)

D3.3 — The working environment: stand up the stack (60 min)

Type: hands-at-keyboard (group). Project: shared.

The sandbox for the week is ours: the working environment, hosted, empty on purpose, gone after the week. Two participants drive. With Claude, the group sets up what the prototype needs inside it: a database, a server. Then they deploy the first pass and click the URL it hands back. Their hands on the keyboard, not a facilitator demo. Nothing in the week touches a company system, and no company credentials exist to hand out.

Name the risk out loud anyway: we are giving an AI the keys to a machine. That is the lesson, and the sandbox is what makes it safe to teach. The four controls apply here already: read-only where the model touches data, a log, a rollback, a named owner who gets the 2 a.m. call. When their team later runs this pattern on their own side, these controls are what make it governable.

It takes 5, 10, 20 minutes. Talk about other things while it runs. Then click the URL.

Facilitator note: The IT lead watches this from the seat they hold all week. Nothing of theirs is exposed; the posture on display (gated access, a log, an owner) is the one they would govern if the company ever did this for real. Keep them central to the conversation.

D3.3b — The bridge: point Claude at the data lake (45 min)

Type: hands-at-keyboard (pods, shared endpoint). Project: shared.

This is the move the whole workshop exists to show. The room has a first-pass prototype running in the sandbox. Now they connect that app, and their Claude, to data the safe way: through a hosted, gated, read-only MCP server over a data lake that LightForge runs. The model never touches SiteLine; it touches this gated, read-only, logged copy. Every call lands on a live audit log the IT lead watches fill. This is the bridge Brandon Flexenhar described the room needing, demonstrated live instead of slideware.

Setup (facilitator, before the session): the mcp-lake server is live on Railway (mcp-lake-production.up.railway.app), seeded with the Fecon cartridge. Each pod gets the MCP config block and a workshop token (see mcp-lake/IT-HANDOUT.md). Project the /audit page on the overhead and leave it up for the whole module.

Step 1 — Facilitator demo (5 min): the facilitator points their own Claude at the live endpoint and asks, aloud: "Which transfer orders are late between plant 2 and plant 3?" The room watches the call land on the overhead /audit — caller, tool, args, rows returned, time. Then the answer comes back. Name what just happened: the model never saw the ERP. It asked a gated server; the server ran a parameterized read-only SELECT; the log recorded it.

Step 2 — Pods connect (10 min): each pod adds the lake MCP server with their token (the config block is in the handout) and restarts Claude. They confirm the six tools are present: query_inventory, query_transfer_orders, query_costs, query_demand, search_wiki, search_wiki_semantic.

Step 3 — Prescribed queries (15 min): each pod runs the Fecon queries Brandon raised in the transcript, and watches each one land on the shared overhead /audit:

• "Which transfer orders are late?" (the building-to-building flow — plant-to-plant, aftermarket, the drop-trailer staging)
• "Show me on-hand inventory for the EV6 parts across all plants."
• "What's the standard cost breakdown for part P-1043?" (material / labor / overhead / standard)
• "What's the EV6 demand and backlog for 2026-09?"
• "Search the wiki for 'the data harness.'"

Step 4 — Free queries + the bad-args moment (10 min): pods ask their own questions. The facilitator deliberately calls query_transfer_orders with status: "bogus" and shows the room the response: a structured error that teaches repair — expected values, a valid example, the next step. Name the discipline: the model does not guess what you meant and silently substitute; tell it how to call correctly and it retries. Code owns the contract; the model owns meaning.

Step 5 — Reflect (5 min): "This is what Joe's fear looks like once it's gated." The fear was losing control — Claude on a desktop, skills that walk out the door, the database exposed. Here the model touched nothing but a read-only, logged window we operate. The IT lead reads the audit log back to the room. The fear was losing control; the log returns it. This is the bridge TriVista claims and the AXH handbook doesn't have. You just used it.

Facilitator notes:

• The /audit page is the trust artifact. Keep it projected the entire module. The point is not the answer the model returns; the point is the room watching the call appear on the log.
• This bridge is ours, hosted, for the week. Day 4 governs the posture. Anything inside their own firewall is a separate conversation after the sprint, not part of this one.
• search_wiki (keyword) works now. search_wiki_semantic (pgvector) returns an honest capability_not_configured error until someone sets an embedding key. That is the visible next step, not a fake demo. Say it out loud when someone hits it: honest error over silent fallback.
• If a pod's Claude can't connect: check the token and the URL, restart Claude. The handout's troubleshooting section covers it.
• Do not skip this module. Without it, Day 3 shows the cliff (the debug loop) but not the bridge, and the room leaves with the fear and no answer. The bridge is what closes the Fecon slot.

D3.4 — Use it, find what doesn't work (60 min)

Type: hands-at-keyboard (group). Project: shared.

The prototype is up. Justin takes them through it: does it do what you want? Can it do this? What happens when we chat with the agent? The chat agent isn't working. Why? It needs an API key. That number is incorrect. How do we know? Because I know that number is incorrect.

Start the debug loop. Go back to Claude, find out why, fix it. Watch the pattern: it fixes this and breaks that. As the code gets bigger, it does more of that.

Facilitator note: Do not hide the breakage. The whole point of Day 3 is that the room feels the debug loop, the silent wrongness, and the "fixes this, breaks that" reality. The cliff is here. Name it when it happens.

Office hours (afternoon)

Personal passion projects continue. The shared prototype is available; people can poke at it. The Day 3 gate: each person has handed their spec to a model at least once and felt the interview.

Homework for Day 4: each person notes one thing the prototype does that surprises them, and one thing they expected it to do that it doesn't.

Close of Day 3 (do not skip): name the exits out loud. For each cliff the room hit today (the debug loop, the silent wrongness, the fix-break pattern), name the exit and who owns walking it. Fear with no named exit is the bad version of Day 3.

Day 4 — the build, the IT team, the hardening

Braydon leads; Justin presses the business framing. The build continues. The IT team's role surfaces fully. Security hardening becomes part of the build, not a separate lecture. The cliff comes fully into view.

Format: half-day clinic + half-day office hours. Can be remote.

Module learning objectives

By the end of Day 4, the participant will be able to:

1. Continue the build/test/debug cycle on the shared prototype, with the group working it together.
2. Place the IT team as the owner of the four controls and the policy calls for anything that later touches company systems.
3. Apply the four controls (verified read-only, audit log, rollback path, named 2 a.m. owner) to the surface they're actually building.
4. Draft the boundary-and-owner map for the prototype: who owns which surface, what crosses each boundary, which human holds the judgment at each one.
5. Name the cliff in their own words: what this prototype does, what production would actually take, and why the gap is real.

Clinic (morning)

D4.1 — The build continues (75 min)

Type: hands-at-keyboard (group). Project: shared.

Continue the debug loop from Day 3. The group works the prototype together. This is where the multiplayer difficulty surfaces: people overwriting each other, no clear owner, the output colliding. Let them feel it.

Facilitator note: Let them feel the difficulty before you name the solution. The boundary-and-owner map is the response to the difficulty they're feeling. If you resolve it too early, it won't land.

D4.2 — The hardening decisions (45 min)

Type: open forum. Project: shared.

The IT lead's role, named explicitly: the controls and the policy calls are theirs. They are the ones who keep the company safe around this. The IT team has felt threatened all week; this is where the threat ends, because the controls are theirs to run and the policy calls are theirs to make. No pandering. State the ownership.

Turn to the IT lead for the policy calls: which subscriptions, the SharePoint-relative-to-Claude rules, the hosting decisions. Braydon doesn't know the Fecon network or the permission sets; the IT lead does. That's their role.

Facilitator note: You earn the credibility to stand between the camps by making the conservative IT leader safe in the room, not by bypassing them. The four controls are the artifact that makes it concrete.

D4.3 — Break (15 min)

D4.4 — The four controls, applied to the real surface (75 min)

Type: hands-at-keyboard (group) + governance. Project: shared.

The four controls, named in the IT lead's language, applied to the two surfaces they're actually building: the prototype app, and the data bridge they used on Day 3. The bridge is the easiest place to teach this, because it has all four controls by construction:

• Verified read-only (where the model touches data) — verify it; do not settle for a claim. On the bridge this is a property, not a promise: the MCP tools are parameterized SELECTs. There are no write tools. The IT lead reads the tool list and confirms it. Read-only first is a vendor's claim; a fixed tool set with no write path is a property the IT lead can sign.
• An audit log on every model access to a system the company owns — the /audit page they watched fill on Day 3 is exactly this. Every call: caller, tool, args, rows, time. The IT lead owns the log.
• A rollback path per surface — on the bridge, the rollback is trivial and worth naming: the model never touched the ERP. The lake is a copy. If a query went wrong, there was nothing to roll back, because the model never wrote anything. The rollback path for the prototype is the working environment: restore the last working state from the repo, or regenerate from the spec.
• A named owner per surface who gets the 2 a.m. call — the IT lead owns the bridge (the token, the lake, the log); a named engineer owns the prototype app. Write it down.

Then draft the boundary-and-owner map live: who owns which surface, what crosses each boundary, which human holds the judgment at each one. The bridge is one row; the prototype app is another. This is the governance document the workshop ships, drafted live by doing the work on the real surfaces.

Facilitator note: The four controls are what convert the conservative IT lead from the obstacle into the ally. Use the bridge as the teaching surface — it is the one thing in the room that already has all four controls, so the IT lead signs a real thing, not a template. Don't skip the controls even if the IT lead seems satisfied; the written controls are the artifact that survives the week. Say it straight: the bridge we host for the sprint is a demo of the posture. Anything inside their own environment is a separate conversation after the week (an LFW build engagement, if they ever want it), with their data, their rules, their log, their owner.

D4.5 — The cliffs, named (30 min)

Type: open forum. Project: shared.

The cliffs come into view — six of them, by name. Walk the room through artifacts/the-cliffs-and-the-wins.md: the debugging cliff (fixes that break things), the integration cliff (the maintenance treadmill — "when two departments are complaining and the integration stopped working, you don't want to spend the day in Claude"), the hardening cliff (environments, credentials, the four controls), the multi-user cliff (the prototype-to-product line), the compliance cliff, and the maintenance-pool cliff (the knowledge lives in one person's chats). Then name the ownership trap on themselves: they will love this thing disproportionately, and the test is whether a new hire with no stake would choose it.

The room starts to see the gap between the prototype they built in a few days and the thing that would run the company — with names for each part of the gap and guidance at each one.

Facilitator note: This is not a sales pitch. The point is that the room sees the cliffs, in their own words, before Day 5, and also sees the win zone: the five things their people can do (analysis on their own data, persona-anchored work, requirements and prototyping, personal productivity, harness applets). No bait-and-switch means both halves are true. What they do about the cliffs is their call.

Office hours (afternoon)

Personal passion projects wrap toward a final state. The shared prototype gets its last passes. The IT lead hardens the governance document toward a versioned, signed control for Day 5.

Day 5 — the handoff

Co-delivered. The prototype as it stands. The read on what production takes. The governance for the artifact they now own. No formal upsell: the prototype is theirs, and what they do next is their call.

Format: 90-minute clinic, no office hours. On-site. Day 5 is the close.

Module learning objectives

By the end of Day 5, the participant (the COO and leadership team) will be able to:

1. Run the prototype live against real use cases, without the facilitator at the keyboard, demonstrating the practice transferred.
2. Name the cliff in their own words: what the prototype does, what production would take, and where the gap is.
3. Sign the governance document as a versioned control with the four controls and the boundary-and-owner map.
4. Take the maintenance rhythm and the ownership-transfer for the prototype, naming who maintains what and for what window.
5. Decide, on the evidence of the week, what to do next, with the read on what production takes and no sales pitch.

Clinic (90 minutes)

D5.1 — The prototype running live (30 min)

Type: hands-at-keyboard (the COO and team). Project: shared.

The prototype runs live against real use cases. The COO and team run it, not Braydon. What it does, what it doesn't, where it surprised them.

Facilitator note: If the COO cannot run the prototype, the practice did not transfer. That is the finding; say so. Before the handoff, the IT lead rehearses the four controls in their own words, walked, not read cold.

D5.2 — The cliff, named (20 min)

Type: open forum. Project: shared.

The read on production, using the named cliffs from Day 4 (artifacts/the-cliffs-and-the-wins.md). This is a prototype. Here's what production would actually take, walked cliff by cliff, with the guidance at each. The gap between what they built in a week and what would run the company is real, and now it has names.

End on the win zone, not the cliff: the five things their people can do, starting Monday, without anyone's help. They leave knowing where they win and where the edges are.

Do not convert this into a sales pitch. The options for what to do next (build it themselves, hire someone, hand it to LFW, shelve it) are their call. The workshop's job is to make the cliff legible, not to perform the sale.

Facilitator note: The credibility comes from not overselling. If the read is "you can take this and keep building it yourselves," say so. If the read is "you'll need help to make this production," say that too, with no upsell. The workshop informs what comes next; it does not perform it.

D5.3 — The governance document and the maintenance rhythm (25 min)

Type: facilitated (artifact). Project: shared.

The governance document: harden Day 4's live draft into a signed, version-controlled control. The four controls. The boundary-and-owner map (the bridge is one row; the prototype app is another). The maintenance rhythm (one page): what they do this month, what cadence keeps the prototype alive.

The ownership transfer: who maintains the prototype and for what window. This is what turns "you can run this yourself" from an assertion into a test. Name the bridge explicitly: the sprint's hosted bridge is ours; what they keep is the practice of using it and the governance posture. If they ever want a governed bridge inside their own environment, that is a separate conversation after the week (an LFW build engagement, on its own terms). The sprint does not set it up and does not perform it.

Facilitator note: The cadence page is the marketing one-pager; the governance document is the ops one-pager the IT lead signs. Commit, in writing, to who maintains the prototype and for what window. Naming the maintenance owner is what makes the practice keepable. Two bookings leave this module in ink: the prototype's first real workday (use case, owner, date) on the calendar, and the 30-day check: one hour, two questions, priced into the fee, booked before anyone leaves Friday.

D5.4 — The handoff (15 min)

Type: facilitated. Project: shared.

It's theirs. The recommendation, including, if true, "you can keep building this yourselves from here." No formal upsell. If the read says ongoing density would help, offer the retainer; credit the Sprint against the first month. If the read says they want the real thing built, that is a separate conversation, one the workshop informed.

The fusion artifact (half a page; the room writes it): the decision, the owner, the date of the prototype's first real workday, and one line of commitment from each person: what they will run themselves. Read it aloud once. Speak the close and write it, and say the floor out loud, not on paper: "Worst week, you still own the spec, the signed controls, and the practice."

Facilitator note: The recommendation is what makes it credible. If the read is "you can run this from here," the plan says so. That is what makes the retainer recommendation (when it comes) believable.

After Day 5

No office hours. Day 5 is the close. Braydon steps back. The prototype, the governance document, the maintenance rhythm, and the ownership transfer are the artifacts the client keeps.

The engagement closes. Whatever comes next (a retainer, a build conversation, the client running it themselves) is a separate conversation the Sprint informed, not a sales step it performed.

Participant materials

The emerging spec — template

Day 2's output. The scribe fills this in live as the room decomposes the application. It is deliberately light — a BRD-lite, not a product requirements document. On Day 3 it goes to the model, and the model's job (via the interviewing persona) is to find what this sheet is missing. An emerging spec with gaps is expected; that is what makes the Day 3 interview real.

App definition (filled in at the scoping session)

App name:

One-liner: (what it does, for whom, in one sentence)

Owner: (who owns this after the workshop)

Primary data set: (what extract feeds it, from what system, delivered by whom, in what format)

Functions (3–5)

For each function, fill in every line. "We'll figure it out later" is an acceptable answer out loud — the scribe writes it down as an open question, because the model will ask.

Function 1: ______

• What it does: (the business purpose, one sentence)
• What it looks like on screen: (describe the screen: what's on it, how it's arranged — words, not drawings)
• What happens when a user interacts: (click, filter, save — what changes, what the user sees next)
• Data it reads: (fields, from the primary set or elsewhere)
• Deterministic or AI-inside: (is this calculation fixed logic, or does the model make decisions here? If AI-inside, say what decides)
• Open questions: (everything unresolved; vagueness goes here)

Function 2: ______

(same structure)

Function 3: ______

(same structure)

Cross-cutting decisions

• Login / multi-user: Does this need accounts? Who logs in? (If the answer is "just me for now," write that — it is the multi-user cliff, arriving early.)
• Where it runs: the working environment we host during the week. (Never production.)
• What "done" looks like for the week: (the one or two functions that must work by Friday)

Data appendix

Known data problems go here on purpose. The mid-data surprise (a rate change, a duplicated row, a renamed code) is the best teacher in the week — write down what you already know is messy.

For the scribe

• Write what is said, not what should have been said. If two people disagree, record both.
• The facilitator or Justin will press with questions ("multi-user means what? Login means OAuth means what?"). Capture the answers.
• At the end of Day 2, this sheet is read back to the room and confirmed. On Day 3, it is pasted into both windows — exactly as written.

The thing you work in all week. Print this or keep it open on a second screen. Bring it to every session.

Your two projects

Shared company application: (agreed in the pre-workshop scoping session)

Your personal passion project: (something you actually care about; confirm it on Day 1)

Day 1 — what AI is

The frame I'm leaving with (one sentence on what AI actually is):

The peach-cobbler demo: what I saw change between the bare window and the rich-persona window:

Which hosting tier is our company in today? What gaps does that leave?

Tier:
Gaps:

The two risks I'm taking back to my desk (data exposure, probabilistic output):

Day 2 — the decomposition

What this application is actually for (by hand, before the model)

What business function does this app solve?

________________________________________________________

________________________________________________________

The functions, decomposed

The AI-vs-deterministic fork

For each function: is it AI inside the app, or hard-coded deterministic? Name the complexity cost of the AI layer.

The emerging spec (confirmed)

The build target Day 3 hands to the model. (Attach the scribe's output.)

Day 3 — the build, first pass

Two windows, two results

Run 1 (one-shot, no persona): what did you get?

Run 2 (Claude Code, senior-engineer persona that interviewed you): what did you get? How did the interview change the output?

The working environment

What the prototype does once the group has it running in the sandbox:

________________________________________________________

The bridge (the live MCP server over the data lake)

The endpoint my Claude connected to: ____________________

One query I ran, and what came back:

________________________________________________________

One thing I watched land on the /audit log (caller, tool, args, rows):

________________________________________________________

The move this makes: the model never touched our ERP. It touched a gated, read-only, logged copy. This is the bridge. In one sentence, what changed about the IT objection for me:

________________________________________________________

The debug log

The cliff, as I felt it today (one sentence):

Day 4 — the hardening

The four controls (applied to our prototype and the bridge)

• Verified read-only (where the model touches data): test it, do not assume it. On the bridge: the tool list is fixed and has no write path. I confirmed it: __________
• Audit log on every model access to a system we own. On the bridge: the /audit page. Owner of the log: __________
• Rollback path per surface. On the bridge: the ERP was never touched, so there is nothing to roll back. On the prototype app: __________
• Named owner per surface who gets the 2 a.m. call. Bridge owner: __________ Prototype owner: __________

The boundary-and-owner map (drafted live, then hardened)

The cliff, in my own words

What this prototype does, and what production would actually take:

________________________________________________________

________________________________________________________

Day 5 — the handoff

The prototype, running live

What the COO and team ran, what it did, what it didn't:

The governance document (signed, version-controlled)

• The four controls are in the document
• The boundary-and-owner map is in the document
• The maintenance rhythm (one page) is in the packet
• The document names the ownership transfer (who maintains the prototype, for what window)
• The prototype's first real workday is on the calendar (use case, owner, date; we book it before Friday ends)
• The 30-day check is on the calendar (one hour, two questions, included in the fee)

The fusion artifact (half a page, ours, written in the room)

The decision: ______________________________________
The owner:      ______________________________________
First workday (use case + date): _____________________

My commitment (one line, what I will run myself):
________________________________________________________
________________________________________________________

The maintenance rhythm (one page)

This month:
________________________________________________________

Cadence that keeps it alive (weekly / monthly / quarterly):
________________________________________________________

What I do next (my call)

________________________________________________________

Your repo and the skills ladder

• The skills ladder — the first skill I will write, from my own work, in office hours this week:

________________________________________________________

• Your repo — the one thing I add each session (a persona or skill, a spec, or a fix):

________________________________________________________

The skill skeleton lives in your repo (skills/_template.md). The kit page your-first-skill.md walks each field, with one worked example.

Friday: I copy my repo to the shared space. The IT team evaluates it and decides what to adopt.

Exit ticket

One thing I will do this week to keep the practice alive:

And the floor, said out loud: worst week, we still own the spec,
the signed controls, and the practice.

________________________________________________________

One thing the AI lead should know about how this week landed for me:

________________________________________________________

Facilitator guide

How to be in the room. The companion to the run-of-show tables. The thing the substitute facilitator reads before Day 1: the role split, the positioning lines, the voice, the restructure-live patterns.

Before the workshop

• Run the pre-workshop scoping session (see intake-and-scoping.md). The scoping session agrees the application, its functions, the data sets, and the technical prerequisites.
• Confirm the sponsor role and opening remarks.
• Prepare the room, tool access, and backup options if logins fail.
• Choose one primary AI tool and one fallback. Have the peach-cobbler persona demo ready for Day 1.
• Drop each learner a copy of repo-template/ on Day 1 (one folder per person, theirs for the week). Office hours work from artifacts/your-first-skill.md: each person packages one skill from their own work before Friday.
• Review the company's policy constraints, especially around confidential data, with the IT lead before Day 1.
• Provision the working environment and verify the bridge is live before Day 3: fresh tokens for the engagement, seed data in place, /audit up.

The role split

• Braydon (the AI lead) carries the AI workshop: the education spine, the persona doctrine, the build sequence, the debug patterns, the four controls, the governance scaffolding. Anyone trained in this model of thinking can deliver this.
• Justin (the business partner) carries the business framing and the client relationship: the "what does this look like, what happens when you click it, is that the business function you're solving" facilitation, the operational vocabulary, the client relationship and the retainer conversation.
• Both observe and restructure live. Braydon does not lecture; Justin does not build AI. The back-and-forth between them is the teaching.

The positioning lines to hold (non-negotiable)

• Delivery-first, education as the vehicle. The workshop builds a real prototype. The education happens in the doing.
• A prototype is a prototype. We guarantee the experience of building it. We do not guarantee production-ready software. Say so up front.
• The conservative IT lead owns the hardening. The credibility to stand between the camps comes from the controls being theirs: their policy calls, their signatures. Make them safe in the room, never bypass them. The four controls are the artifact.
• No formal software upsell. The workshop informs what comes next; it does not perform the sale. Name the cliff. What they do about it is their call.
• No bait and switch. If the read is "you can run this from here," say so. The retainer or the build conversation, when it comes, is credible because the close was straight.

The voice

Plain observational language. No literary language, no author-in-the-middle, no metaphors dressed as business insight. State facts plainly; let the practice speak. A participant's reaction is more useful than a facilitator's performance.

The teaching staple (from the medical run, and the workshop's whole thesis in seven words): the model meets you at the level of the ask. It compresses the persona doctrine, the think-first move, and the room's own expertise-as-advantage into one line. Use it early, and return to it all week.

During the workshop

• Keep the session decision-oriented, not exploratory only. Translate technical concepts into business language.
• Ensure every exercise ends with a visible artifact — the emerging spec, the running prototype, the governance document, the maintenance rhythm. Not a feeling.
• The clinic is open forum; people share their screens. People demonstrate what they are doing; the group talks about what it means. The AI lead's job is to make the doing visible and to name what's happening as it happens.
• Let them feel the difficulty before you name the solution. Day 3's multiplayer difficulty and Day 4's cliff both land only if the room feels them first.

The restructure-live playbook (consolidated)

Three starter patterns. Each is: the signal you see, the sentence you say, the redirect. I adapted the patterns from the v0 kit; each delivery adds more.

Pattern A — the context has drifted.

• Signal: the output is technically fluent but has drifted off the question.
• Sentence: "We've drifted. The model is answering a question you stopped asking two turns ago. Kill this context. Start a new one with the question you actually have now."
• Redirect: new chat, restate the narrow question, re-attach the persona.

Pattern B — the model is flattering instead of analyzing.

• Signal: the output agrees with the participant's framing rather than stress-testing it.
• Sentence: "This is flattery, not analysis. The persona dropped. Re-anchor: restate the persona's name, role, and blind spots, and ask it to argue against your framing."
• Redirect: re-anchor the persona in the same chat; demand the adversarial pass.

Pattern C — the output is a wall of text nobody will read.

• Signal: the model has generated a comprehensive answer the participant cannot act on.
• Sentence: "This is the wall-of-text trap. Stop. Tell me the one decision this was supposed to surface. We'll rebuild the ask around that decision, narrow."
• Redirect: kill the output, restate the ask as one decision, regenerate narrow.

Pattern D (build-specific) — it fixes this and breaks that.

• Signal: the model fixes the reported bug and introduces a new one in the next pass.
• Sentence: "This is the fix-break loop. It fixes what you asked and breaks something adjacent. Don't keep patching in place. Tell me what the whole thing should do now, and let's regenerate from a clean spec, not a patched one."
• Redirect: stop patching; restate the current intended behavior; regenerate from the spec.

Room craft (write it down; run it)

Casting. The scribe is the person the buyer is developing — often the newest hire. The room's memory is a real role; the pen gives the junior seat standing all week. D3.1's two runs: the first run goes to whoever has the most cover in the room, never the most senior person in front of a subordinate. Nobody performs a failure below their reporting line. Two participants drive the Day 3 build runs and the sandbox setup, not the facilitator.

Screens. Screenshare is voluntary, never assigned. "Who wants to show what they got?" not "Show us, [name]."

Cut order (Day 3). The clock always cuts in this order: the bridge's free-query segment first, then D3.1's second run, then the debug loop shortens. D3.4 is never cut — it carries the cliff. If the bridge endpoint is down: the audit-log walkthrough from the seeded cartridge, never an improvised ungated connection.

The Day 3 close. End the day by naming the exits out loud: for each cliff the room hit (the debug loop, the silent wrongness, the fix-break pattern), name what the exit is and who owns walking it later. Fear without an exit is the bad version of Day 3; fear with a named exit is the lesson.

Day 5 close. Say the floor sentence out loud — "Worst week, you still own the spec, the signed controls, and the practice" — and do not leave it on paper. The IT lead rehearses the four controls in their own words before the handoff. The room produces the fusion artifact, half a page: the decision, the owner, the date of the prototype's first real workday, and one line of commitment from each person. The 30-day check gets a calendar slot before anyone leaves Friday — one hour, two questions; the fee already covers it.

After the workshop

• Harden the governance document (with the IT lead) into a signed, version-controlled control before Day 5.
• Complete the maintenance rhythm and the ownership transfer for the prototype.
• Book the 30-day check-in before leaving Friday: one hour, two questions (did anyone run it; what is living in one person's context windows). The fee carries it; it is a service, not a pitch.
• Write the session summary within 24 hours: decisions, open questions, next steps.

Intake and scoping

The scoping session. Virtual, 1.5–3 hours, in the price. The SOW-defining build meeting, run before the engagement is booked. The output is the build target the whole room starts from on Day 1.

Who's in the room

• The operating executive (COO, president, GM, head of operations) — the buyer.
• The IT lead (the gate). Must be in the scoping session; not optional, not bypassed. They own the dev environment and the prerequisites.
• One or two people one level down — whoever runs the functions where the work happens.
• Justin (business framing and client relationship) and Braydon (AI workshop).

What gets agreed

The application

The single shared company application the team will build. One app, not a menu. The test: is it real and urgent enough that the room will care about it all week? If the buyer can't name one, the workshop isn't ready to book.

The functions

What the app does. Three to five functions, named specifically. Not "a scheduling app" — "review next week's production schedule, flag conflicts, propose a re-sequence." Specific enough to decompose on Day 2.

The data sets

What data the app needs, where it lives, what's connected to what. Is the data in the cloud or on a local server. Is API access available (and is the IT lead comfortable turning it on). What the compliance / regulatory constraints are (GxP, Part 11, HIPAA, etc.).

The AI-vs-deterministic fork

What's AI inside the app, what's hard-coded deterministic. Name the complexity cost of the AI layer. The buyer decides; the workshop honors the decision. Let them shoot for the moon if they want to.

The technical prerequisites

• The hosting environment (the IT lead's dev env, stood up before Day 3).
• API access to the systems the app touches.
• Which AI tier the team works in (free, premium, enterprise, privately hosted) and what that means for data security.
• The four controls, seeded: who will own each surface, who gets the 2 a.m. call.

The format question (resolve here)

• Half-day clinic + half-day office hours, each working day? (The default.) Or full-day clinic?
• First two days on-site, build days remote? (The default.) Or all on-site, or all remote?
• Five working days over ~8 calendar days, with soak days between? (The default.) Or compressed?
• The run-of-show is built to the default. If the buyer wants a different format, adjust the run-of-show before the engagement, not during it.

The two projects (seeded here)

• The shared company application (agreed above).
• Each person's personal passion project (seeded in the session, confirmed Day 1 morning).

The price

$9,000–$12,000, fixed scope. Land on the exact number once scope is known. If scope creeps above a 5-day arc, that is a second Sprint or a retainer conversation, not a discounted Sprint.

The honesty guarantee (stated up front)

The workshop builds a prototype or MVP. We guarantee the experience of building it. We do not guarantee production-ready software. A prototype is a prototype. The close names the cliff; what the client does about it is their call. Say this in the scoping session, not just at Day 5.

Capacity

One Sprint at a time in the front-load phase. The arc is ~30–35 hours of the AI lead's time plus the partner's. Stagger onboarding so two front-loads do not overlap.

The read at scoping

If the read at scoping is that this company is not ready for the Sprint (no executive who has personally gone up, no IT lead who will be in the room, no application real enough to build), say so. The first-two-weeks engagement (under work-with-me) is the smaller entry for a company not yet ready for the Sprint.

The scoping session

The session itself is run from facilitator/scoping-session.md — the run-of-show, the app-candidate criteria and menu, the technical prerequisites checklist, and the session output (the app definition sheet that becomes Day 2's starting artifact).

Artifacts

The cliffs and the wins

The cliffs and the wins

Where your people win with these tools, and the named cliffs at the edge of that ground, with guidance at each. No bait-and-switch, no drive-off-the-cliff. Used on Day 1 (the win zone, with the stack) and Days 4–5 (the cliffs, named).

Where your people win

Five things your own people can do well with these tools, safely, durably, without becoming software developers:

1. Analysis and reporting on your own data. Cost curves, control charts, Pareto, exception hunts — the work your cost accountant does, done in an afternoon by an executive who knows the business, against clean data fed through a data harness. This is the pattern the workshop is built around: the person who knows the business becomes the person who can analyze it.

2. Persona-anchored repeatable work. Every function gets its own analyst. The cost-accountant persona, the audit-partner persona, the ops-reviewer persona: each one a reusable instruction set that drops the model into the part of the training data you need. Build once, reuse every month.

3. Requirements and prototyping. The durable, scarce skill. The bar for building custom software has dropped, but the pool of people who can make good product decisions has not grown. Your people, trained to decompose what they want and prototype it, close the gap that matters: knowing what to build and what it should do. A prototype from your team is the specification, in running form.

4. Personal productivity. Every knowledge worker, including the ones who think they are "just" an executive assistant. Drafting, summarizing, preparing, organizing — the passion projects exist to prove this one individually.

5. Small harness applets. The layer-six pattern: a small piece of code that cleans, scrubs, and moves data, hosted by IT on a schedule, reached by the model through a connection like an MCP server. Less than software development, more than you have now. This is the sanctioned DIY path that makes the rest safe.

What this is not: production software, maintained integrations, multi-user products, or anything on a regulated surface. Those are the other side of the cliffs.

The cliffs, named

Six of them. Each one: what it looks like, the tell that you're at the edge, and the guidance.

Cliff 1 — The debugging cliff

What it looks like: the model fixes the thing you asked about and breaks something else while it does. The bigger the code gets, the more it happens. Fixes diverge instead of converge: each round of "fix this" introduces two new problems.

The tell: you're on your fifth round of paste-the-error-back and the output is getting worse, not better. Or worse: the output looks right, the number is wrong, and nothing crashed to tell you.

Guidance: cross-check outputs against an analysis you trust before you rely on them. The model's tests pass because it wrote the tests with the same wrong assumption. A human who knows the business is the only real test suite. Know the difference between a converging fix cycle and a diverging one. When it diverges, stop, kill it, and restart from a narrower ask.

Cliff 2 — The integration cliff

What it looks like: the prototype worked. Then the Google Docs integration stopped working, because Google changed something. Then the data feed's fields changed, because your ERP updated. Now two departments are complaining that the interface doesn't support their workflow, and the person who built it doesn't want to spend their day in a chat window fixing it. They want someone to fix it now.

The tell: you're maintaining instead of building. The tool that was supposed to save time now has a queue.

Guidance: every integration is a subscription to maintenance, not a feature. Prefer the data-harness pattern (one narrow, IT-owned connection that feeds clean data in) over deep integrations with external services. And know the moment: when the app is used by everyone and the owner is inundated with requests, it has stopped being a prototype. That's the handoff point.

Cliff 3 — The hardening cliff

What it looks like: it runs on a laptop with credentials in a config file. To make it real, it needs hardened servers, separate environments (development, QA, production), access control, backups, monitoring: none of which the builder has ever done, all of which the model can describe fluently and implement dangerously.

The tell: someone says "just give the model the production credentials and let it deploy."

Guidance: the four controls, applied for real — verified read-only, audit log, rollback path, a named owner who gets the 2 a.m. call. IT owns the hosting. Never production credentials in a prototype. This cliff is why the IT team is in the room from Day 2.

Cliff 4 — The multi-user cliff

What it looks like: the prototype works perfectly for one person on one machine. Making it work for the company (logins, roles, permissions, concurrent use, one person's changes not destroying another's) is a different category of software.

The tell: the second person asks for an account.

Guidance: multi-user is the line where "prototype" becomes "product." You can stand at that line with a working prototype and a clear spec, which is a real result, or cross it, which is a software project. Stopping there is a success.

Cliff 5 — The compliance cliff

What it looks like: the tool touches a regulated process, anything near financial reporting, quality systems, validated environments, or patient data, and the informal prototype cannot live there no matter how well it works.

The tell: someone from compliance asks who validated it.

Guidance: regulated surfaces need validated processes and accountable owners. That is a handoff, not a DIY project. Build the prototype on the safe side of the line and let it serve as the specification.

Cliff 6 — The maintenance-pool cliff

What it looks like: your best builder leaves, gets busy, or loses interest, and nobody else can pick up what they built, because it lives in their chats, their prompts, their head.

The tell: the knowledge is in one person's context windows and nowhere else.

Guidance: the practice is the asset, not the artifact. Documented personas, written specs, and a team that shares the skill — that is what survives the person. If it can't survive the person, it was never an organizational capability.

The ownership trap (the psychological current)

Not a cliff — a current that carries you past the warning signs.

The people who build something will love it disproportionately. They built something cool that is 70–80% there, they keep fiddling with it, and it mostly works. Ownership bias and loss aversion do the rest: they'll believe their custom tool is better than it is, that its one-off features are essential, and that replacing it would be wasteful. The one-off features will multiply, each one harder to give up than the last.

This is normal and it is not a character flaw; it is how humans work. But it is also how a company ends up running on an unmaintainable artifact nobody can evaluate.

The test: would a new hire, with no stake in having built it, choose this tool? If the answer is no, the prototype has done its real job — it told you what you need — and the question is what to build for real, not how to keep fiddling.

Name this in the room, on yourselves, before it happens. The workshop builds the prototype knowing it is a prototype: a learning artifact, and the basis for a real decision about what to build.

Internal notes — not part of the sent version:

• The buyer's own words (from a live prospect, Sept 2026): "We don't want to buy bespoke software from you — we can build it ourselves. We need someone to consult, to show our new MBA, who understands our business, how to use Claude better." This is the exact ask the workshop answers. The consulting is real; the product need arrives later, when they hit the cliffs.
• The trust lens (from the field): a service that successfully hides that someone is unqualified for a job is a strong position to be in, and every current AI product can be read through that lens ("AI helps hide my incompetence and insecurity, so I happily spend on it"). The confidence gap is as real as the skill gap, and the consulting fills both.
• Where the product conversation opens (the conversion triggers, all from the field): when the tool is used company-wide and the builder is inundated with bug requests; when the build is abandoned because it's so bad no one uses it; when compliance pressure makes DIY annoying; when an integration breaks and there's no one to call. None of these are sold in the room. They arrive on their own, and the workshop's honesty is what makes the later call credible.
• The field consensus on the consulting-first position: the software/SaaS space is harder than ever (companies value software less; short-term moats have collapsed), while the pool of people who can make good product decisions and maintain production software has not grown with AI. Consulting-first with product on the side is the shape several independent operators have converged on this year.

The governance and monitoring framework

The governance and monitoring framework

The standing framework the Sprint installs. Governance as a boundary-and-owner map with judgment placed at the boundary; monitoring as the health of the practice, not the compliance of a policy. Drafted on Day 4 against the real prototype, signed and version-controlled on Day 5, sustained by the cadence below.

What this is

Most AI governance frameworks are policy documents: rules about what agents may do, signed once and rarely read again. This framework is the inversion the workshop teaches: governance is a boundary-and-owner map (who owns which surface, what crosses each boundary, which human holds the judgment), and it stays alive through monitoring: the ongoing observation of whether the practice is healthy, not whether a policy is followed.

AI use in a company is not a system that complies; it is a practice that decays. People drift back to one big open chat. Personas decay to generic. The wall of text returns. Judgment moves from the human to the output. A policy document cannot see any of this happening. A monitoring cadence can.

The governance layer

Installed on Day 4 against the prototype, hardened into a signed, version-controlled control on Day 5.

The boundary-and-owner map

One page. For each surface the team runs AI work on (the prototype, the data connections, the shared workspace):

• The surface — what it is (the prototype, a database connection, a review artifact).
• The owner — one named person. Nobody crosses into anyone else's lane.
• What crosses the boundary — defined: a finished artifact with instructions, an append-only fact, a defined loop. Not an open shared workspace.
• The human at the handoff — which person holds the judgment when work crosses between surfaces.

The four controls (per surface)

1. Verified read-only (where the model touches data) — not claimed, verified. The read-only invariant is tested on a schedule, not assumed from the vendor's claim.
2. An audit log on every model access to a system the company owns.
3. A rollback path per surface — what happens when it breaks, and how it is undone.
4. A named owner per surface who gets the 2 a.m. call when it breaks.

The escalation path

When monitoring finds a breach (a control failed, a boundary crossed, an owner unresponsive):

1. The finding goes to the surface's named owner, same day, in writing.
2. If unresolved in one business day, it goes to the IT lead and the operating executive together.
3. Anything touching the live database is rolled back first and discussed second.

The monitoring layer

Three levels. Each has a named monitor and a cadence.

1. Control monitoring (mechanical)

Are the invariants holding? This is the IT lead's layer — checkable, signed, boring by design.

• Is the read-only invariant still verified? (Test it; do not read the label.)
• Is the audit log clean — any access from an unexpected identity, any query outside the expected pattern?
• Are the rollback paths still documented and current?
• Are the named owners still the right owners — still employed, still in role, still answering?

Cadence: weekly. Monitor: the surface owner and the IT lead.

2. Practice monitoring (behavioral)

Are the behaviors alive or decaying? This is the operating executive's layer — the early-warning system. The workshop's restructure-live patterns become org-level decay signals:

• Drift returning — people running one long open conversation again, restarting from confusion instead of from a fresh narrow question. Signal: personas and segmentation are decaying.
• Flattery returning — outputs that agree with the team's framing instead of stress-testing it. Signal: anchoring is lost; the model has reconformed to generic helpfulness and nobody noticed.
• Wall-of-text returning — analyses nobody reads, arriving again. Signal: judgment has lapsed; the last 20% moved from the human to the output.
• Handoffs without humans — work crossing boundaries with no named person holding the judgment. Signal: the multiplayer discipline is eroding into the shared substrate.
• Shadow AI regrowing — new unsanctioned tools appearing in ungoverned folders. Signal: the sanctioned surfaces are not serving the need.

Any two of these appearing in the same month means the practice is decaying and the team needs a working session, not a memo.

Cadence: monthly, as part of the operating review. Monitor: the operating executive, with the AI lead on retainer if retained.

3. Outcome monitoring (results)

Is the practice producing decisions or just activity?

• Is the prototype being used against real data (not exports)?
• Are the numbers trusted — does the leadership team act on them without re-deriving them?
• Are exceptions being caught (the things the practice exists to surface)?
• Is the team building on it, or has it stalled?

The difference between "AI is being used" and "AI is working" is decided here. If activity is high and decisions are flat, the practice is producing motion, not decisions.

Cadence: quarterly. Monitor: the operating executive and the leadership team.

The monitoring surface

The framework ships with a standing surface that makes the practice's health visible at a glance. A single page, reviewed at each cadence:

• Surfaces and owners (from the boundary-and-owner map)
• Control status per surface (green / flagged / failed, with dates)
• The decay signals observed this period (drift / flattery / wall-of-text / handoffs / shadow)
• Decisions made against the prototype this period (the outcome count)
• The last review date and the next one

This surface is what keeps the governance from becoming a whiteboard photo.

The cadence (summary)

How it goes in, and who sustains it

• Day 4 drafts the boundary-and-owner map live against the prototype, with the conservative IT leader and the operating executive in the same room.
• Day 5 hardens it (signed, version-controlled, with the four controls and the cadence) and hands it over with the monitoring surface.
• Sustained either by the client themselves (the framework is theirs; the cadence is theirs) or on retainer, where the monthly operating review is the natural working session.

What this framework is not

• Not a policy about what agents may do. The rules live in the boundaries and the owners, not in a document about agents.
• Not a one-time compliance exercise. It is signed once and then monitored continuously, or it is already dead.
• Not software. It is a practice with artifacts and a cadence.

The governance map template

The boundary-and-owner map — who owns which surface, what crosses each boundary, which human holds the judgment at each one. Drafted live on Day 4, hardened into a signed, version-controlled control before Day 5.

The bridge — the live data connection

mcp-lake — the safe bridge between Claude and your ERP

A hosted, gated, read-only MCP server over a data lake. This is the artifact
the Fecon workshop's Day 3 runs on: participants point their Claude at our
public HTTPS endpoint and run real queries against Fecon-shaped ops data. The
model never touches the ERP (SiteLine); it touches this gated, read-only,
logged copy. Every call lands in an audit log that IT watches fill in real
time at /audit.

The wall: "the work depends on spreadsheet exports, the analysis lives on
one desktop, and conservative IT leaders have no trusted bridge." This is
the bridge — demonstrated live, not slideware.

What it is

• A Python MCP server (official mcp SDK, streamable HTTP transport) hosted
  on Railway at a public HTTPS endpoint.
• A Postgres data lake seeded with Fecon-shaped ops data (plants, inventory,
  transfer orders, product costs, demand) plus a reusable vertical-agnostic
  core-ops cartridge for other clients.
• A pgvector-enabled wiki (search_wiki works out of the box; semantic search
  is a visible, honest "next step" behind an embedding key).
• An audit log + live /audit page — the trust artifact IT reads.

Tools exposed (all read-only, all parameterized, all logged)

On a bad call, a tool returns a structured error that teaches repair:
expected shape, valid examples, next step. The model retries. Code never
guesses what the model meant.

Connect Claude (workshop participant)

Add an MCP server in Claude Code / Desktop:

{
  "mcpServers": {
    "lake": {
      "url": "https://<your-railway-domain>/mcp",
      "headers": { "Authorization": "Bearer <workshop-token>" }
    }
  }
}

Then ask Claude: "Which transfer orders are late between plant 2 and plant 3?"
Watch the call appear at /audit.

Discipline

Model-mediated: code owns contract clarity, the read-only gate, and the audit
log. The model owns meaning. No silent fallbacks, no semantic heuristics in
code, no writes exposed.

IT handout — pointing your Claude at the hosted data lake

For the IT lead / workshop participant. One page.

What's happening

Your Claude is not touching our ERP (SiteLine). It is connecting, over HTTPS,
to a server LightForge hosts on Railway. That server exposes a small set of
read-only queries against a copy of our operations data (a "data lake"). The
model asks for data through named tools; the server runs parameterized SELECTs
and returns rows. No writes exist. Nothing reaches the production database.

Every single call is written to an audit log. You can watch it fill, live, at:

https://mcp-lake-production.up.railway.app/audit

Refresh the page (it auto-refreshes) and you will see, in order: who called
(which workshop token), which tool, the arguments, how many rows came back,
and the timestamp. That is the entire surface the model has into our data.

Point your Claude at it

In Claude Code (~/.claude.json or the in-app MCP settings) or Claude Desktop:

{
  "mcpServers": {
    "lake": {
      "url": "https://mcp-lake-production.up.railway.app/mcp",
      "headers": { "Authorization": "Bearer <your-workshop-token>" }
    }
  }
}

Restart Claude. You should see a lake MCP server with tools like
query_transfer_orders, query_inventory, query_costs, query_demand,
and search_wiki.

Try these (then make up your own)

• "Which transfer orders are late between plant 2 and plant 3?"
• "Show me on-hand inventory for the EV6 parts across all plants."
• "What's the standard cost breakdown for part P-1043?"
• "Search the wiki for 'the cliff'."

After each one, open /audit and watch your call land.

What this proves

This is the move that answers the IT objection directly. The fear is "if I give
Claude access to the database, I lose control." Here you never gave Claude the
database. You gave it a gated, read-only, logged window we operate. The
controls are visible: the tool list is fixed, every query is read-only and
parameterized, and every call is on the audit log you are looking at.

Day 4 covers governing this posture. Anything inside your own firewall is a
separate conversation after the week.

Troubleshooting

• "No lake server in Claude" — check the URL and token, restart Claude.
  The token must match what the facilitator gave you.
• 401 Unauthorized — wrong token. Ask the facilitator.
• Empty results — try a tool without filters first (e.g. just
  "list all transfer orders") to confirm the connection, then narrow.
• capability_not_configured from search_wiki_semantic — semantic
  search needs an embedding key the operator sets; use search_wiki
  (keyword) for now. This is honest, not broken.

The maintenance rhythm

One page. The ops page the IT lead signs. What they do this month, what cadence keeps it alive.

This month

• The prototype's first real workday: [use case, owner, date], booked before Friday's close, on the calendar now.
• Run the prototype against real use cases (not exports). One review, live.
• Maintain the read-only invariant on the model's data access. Verify it is still read-only. (The IT lead owns this.)
• Run the governance document's review cadence (named in the boundary-and-owner map).
• Keep the personal practice: think first, by hand, before the model; segment into bounded steps; keep the judgment.

The cadence that keeps it alive

• Weekly: check the read-only invariant; check the audit log for any access anomalies.
• Day 30: the check-in hour, which we book during the sprint. Two questions: did anyone run it, and what is living in one person's context windows. The fee carries it; it is a service, not a pitch.
• Monthly: run a review against the prototype; review the boundary-and-owner map; check that the named owners are still the right owners.
• Quarterly: review the whole setup; decide whether to make the prototype production, hand it off, or retire it.

The 2 a.m. call

The named owner per surface who gets the 2 a.m. call when it breaks is in the governance document. That person is the gate; the practice survives the month because you page that person, you do not ignore them.

What this is not

• Not a 90-day plan. Plans are the retainer's job. This page is the rhythm that keeps the prototype and the practice alive without the retainer.
• Not a strategy. This is the operational page; the strategic page is a different conversation.
• Not a guarantee the prototype is production-ready. The prototype is a prototype. What production takes is a separate conversation, named in the workshop.

The persona library

The persona library

Reusable personas, each built to the persona doctrine: named, with background, formative experience, vocabulary, proclivities, and blind spots. The specificity is the mechanism — it drops the model into the part of the training data you need. Replace the bracketed domain details per client; keep the structure.

The demo pair (Dottie, the pastry chef) and the Day 3 pair (Block C/D) live in copy-blocks.md. This library holds the working personas for analysis, audit, and adversarial review.

The cost accountant

For: cost analysis, margin work, variance decomposition — the Brandon pattern.

You are Martha Kowalczyk, a cost accountant with 19 years in discrete
manufacturing — first tier-one automotive, then agricultural equipment, now
a fractional cost controller for mid-market manufacturers. You live in
standard costing, job costing, and variance analysis: material price and
usage, labor rate and efficiency, overhead absorption. You can decompose a
margin change to its drivers in your sleep, and you refuse to present a
bridge you cannot tie to the underlying jobs.

Your formative experience: at your second employer, you found a scrap
variance that management had been reading backwards for two quarters — the
sign convention in the report was wrong, and nobody who read it monthly had
noticed. Since then you re-derive every number from the raw jobs before you
believe the summary.

Your discipline: reconcile before analyze. You ask what the data includes
and excludes before you opine on it. You name your assumptions out loud.
You are precise about the difference between a cost change and an accounting
change (an allocation shift is not a saving).

Your blind spots: you distrust anything that isn't tied to the general
ledger, which sometimes makes you slow on directional answers; and you
write for accountants, so translate your output for operators when asked.

The audit partner

For: data-quality review, the persona-comparison flagship, anything needing professional skepticism.

You are Robert Callahan, a senior audit partner — 25 years at a Big Four
firm, the last 15 leading manufacturing cost audits across the industrial
Midwest. You have signed opinions you would defend in court, and you have
walked away from clients who wouldn't fix what you found.

Your formative experience: early in your career you caught a material
misstatement in a client's inventory allocation that the client, the senior
partner, and the prior year's team had all missed. It nearly cost the firm
a restatement. It made you permanently suspicious of allocations, accrual
estimates, and any number that moved because a policy changed rather than
because the business did.

Your discipline: data quality is finding zero. Before any analysis, you
reconcile — totals, completeness, duplicates, cut-off. You apply a
materiality threshold and you state it. You distinguish what the data shows
from what management says it shows, and you say which is which.

Your vocabulary: workpapers, walkthrough, substantive testing, allocation
basis, cut-off, reconciliation, materiality. Use it naturally.

Your blind spots: you over-hedge on anything you can't substantiate, and
you underweight commercial upside — you find risks, not opportunities.
Someone else in the room has to hold that side.

The skeptical CFO

For: the adversarial pass — attacking an analysis before it goes to the board.

You are Diane Xu, a CFO who has run finance for two private-equity-backed
manufacturers and taken one of them through a sale. You have read hundreds
of internal analyses and you have a simple test: does this change what we
do, and can I defend it to a board that has ten minutes?

Your discipline: attack the analysis, not the analyst. Find the three
weakest points: the assumption nobody checked, the number that came from
somewhere unexplained, and the recommendation that sounds like hope. Ask
what would have to be true for the conclusion to be wrong — and whether
anyone verified that it is. If the analysis would not survive a board
question, say which question kills it.

Your style: direct, numerical, unimpressed by effort. "Interesting" is not
a word you use. You give credit only to findings that survive your attack.

Your blind spots: you discount anything you can't quantify, which makes you
late on operational and people factors; and your skepticism can read as
dismissal — keep it pointed at the work.

Building a new persona (the doctrine, compressed)

When the room needs a persona this library doesn't have:

1. Name them. A real name anchors the model — oddly, but reliably.
2. Years and domain. Not a job title — a history: where they trained, what they've done.
3. One formative experience. The event that explains what they check first and why. This is the strongest single line in any persona.
4. Their discipline. What they do before anything else (reconcile, interview, attack, de-risk).
5. Their vocabulary. The field's real terms — this is the actual latent-space anchor.
6. Blind spots, stated. A persona without blind spots produces confident generalities, because the model never has anything specific to be wrong about.

Test: strip the name. If it could be a LinkedIn summary for any senior hire, it isn't specific enough. Dottie would never be mistaken for a generic chef; Dr. Marsh would never be mistaken for a generic engineer.

Client-facing

Engagement brief

Forwardable. One page.

A five-day, fixed-scope workshop where your team builds a working prototype of a real application with AI, and learns the practice along the way. Co-delivered with Justin Goethe. The core is vertical-agnostic.

Who it's for

An operating executive (a COO, president, GM, or head of operations) and a small group of their people. The exec who has personally discovered AI, is getting real wins, and is about to hit a wall.

The wall, in one line

The work depends on spreadsheet exports, the analysis lives on one desktop, the output is deep but unreadable, and conservative IT leaders and hungry executives have no trusted bridge between them. We bring the bridge: a hosted, gated, read-only MCP server over a data lake, with an audit log the IT lead reads in real time. Your team uses it on Day 3, not a slide about it.

What the team leaves with

1. A working prototype or MVP of the application you scoped together, built by your people in the working environment we host. You own the code, the spec, and the repo.
2. A team that understands AI: what it is, how it works, where it works, what its limits are, and where the cliff is. And the skills ladder: your people learn to package their own work as skills, and skills on timers as agents.
3. A shared, governed setup: the four controls, the boundary-and-owner map, and the gated data path the team used live on Day 3: a hosted, read-only MCP server over a data lake, every query on an audit log the IT lead read in real time. They have felt the control the IT objection keeps asking for. We host it for the sprint. Anything inside your own environment is a separate conversation after the week.
4. The practice itself, transferred: a one-page maintenance rhythm your people own, and the prototype's first real workday on the calendar before we leave Friday.

We guarantee the experience of building it. We do not guarantee production-ready software. A prototype is a prototype. Worst week, you still own the spec, the signed controls, and the practice.

How it runs

A pre-workshop scoping session (virtual, 1.5–3 hours, in the price) agrees the application, its functions, the data sets, and the technical prerequisites. Then five working days, half-day clinic + half-day office hours. First two days on-site; build days can go remote. Two projects run all week: the shared company app, and a personal passion project each person picks.

Price

$9,000–$12,000, fixed scope, set during scoping. The total counts your team's time too: six people for five days is roughly 240 hours of payroll. Name it yourself; it beats the CFO discovering it. The fee carries the scoping session and a 30-day check-in: one hour, two questions, booked before we leave Friday. If you continue, the retainer is the next conversation; it runs $5,000–$6,000 a month.

How it generalizes

The arc is vertical-agnostic. What changes per company is the application, the data systems, and the partner's relationships. The reusable core (the scoping session, the five-day arc, the build sequence, the honesty guarantee, the governance close) is horizontal.

Terms

Set Earth Inc. A mutual NDA before day one. The workshop is co-delivered; the business framing and client relationship run through Justin, the AI workshop through Braydon.

— Braydon McCormick · b@mcco.us

Pre-work packet

The thing the client receives once we book the engagement. Short and concrete; the client prepares nothing beyond access.

The scoping session (before Day 1)

A 1.5–3 hour virtual meeting, in the price. The output is the build target: the application, its functions, the data sets, the AI-vs-deterministic decision, and the technical prerequisites. Bring the operating executive, the IT lead, and one or two people one level down.

Access list (about ten items)

Typical:

• A seat in whatever your team already lives in (Slack, Teams, Google or Microsoft).
• Read access to the tools your operation runs on (the ERP, the scheduling system, Power BI, etc.).
• Two hours on the executive's calendar in week one and two in week two.
• Fifteen minutes with whoever manages your IT or compliance, so everyone knows the rules before anyone touches anything.
• If you are in a regulated environment: your data-handling constraints, up front, so work happens inside them.
• A named person one level down for Days 2–3 (whoever runs the functions where the work happens).
• The IT lead in the room for the scoping session and Days 2–5 (not optional, not bypassed).

Nothing stands up on your side: no environments, no servers, no credentials. The week runs in a hosted working environment we provide, and the only data path is the gated, read-only bridge.

Scheduling

Five working days over roughly eight calendar days, with soak days between. The half-day clinic / half-day office-hours format is the default. First two days on-site; build days can go remote; Day 5 on-site. Confirm or adjust at the scoping session.

What you send

You send nothing to prepare beyond the scoping session. The point is to build the real thing, together.

What you do not send

Nothing of yours goes into a tool your policy has not cleared. If your enterprise agreement with Anthropic, OpenAI, Microsoft, or Google, or a model you host, is the cleared path, you use that one, and you document which one you use.

The honesty guarantee

The workshop builds a prototype or MVP. We guarantee the experience of building it. We do not guarantee production-ready software. A prototype is a prototype. The close names the cliff; what you do about it is your call. Worst week, you still own the spec, the signed controls, and the practice.

Before Day 1 morning

The scoping session confirms the two through-line projects: the shared company application, and each person's personal passion project (something they actually care about; the room confirms each one on Day 1).

Day 5 debrief checklist

The closeout, so the prototype and the practice transfer clean. The AI lead runs this; the IT lead signs where named.

Before the handoff (Day 5 morning)

• The governance document is hardened (drafted live on Day 4 against the prototype, hardened with the IT lead into a signed, version-controlled control).
• The four controls are in the governance document: verified read-only, audit log, rollback path, named 2 a.m. owner.
• The maintenance rhythm is written (one page; the ops page the IT lead signs).
• The ownership transfer is drafted for the prototype: named owner, date, handover of the repo and the maintenance page.
• The prototype is running against real use cases (not dummy data) for the handoff.
• The working environment is up (the sandbox from Day 3, with the prototype running).

The handoff (Day 5, 90 minutes)

• The COO and team run the prototype live (the AI lead steps back).
• The cliff, named: what the prototype does, what production takes.
• The maintenance rhythm is handed over (one page).
• The governance document and the ownership transfer are handed over and signed where named.
• The recommendation is given (including, if true, "you can keep building this yourselves from here"). No formal upsell.

After the handoff

• The session summary is written within 24 hours: decisions, open questions, next steps.
• The governance document is committed to version control (signed, dated).
• The retainer is offered if the read is that ongoing density would help; the Sprint is credited against the first month.
• If the read is that the team can run it from here, that is said.
• If the read is that the team wants the real thing built, that conversation is left for later, on its own terms, not performed in the room.

The transfer test

If the COO cannot run the prototype without the AI lead, the practice did not transfer. That is the finding; say so. The retainer becomes the recommendation.