For coaches and cohort operators. Your teaching is the asset. Stop losing it.
Your best teaching disappears
after every call. Build a Meeting Wiki Brain.
The sessions. The 1-on-1s. The stories and metaphors you use to explain the hard stuff. Gone the moment the call ends. This guide shows the full mechanism behind the meeting wiki: a second brain that captures every call, pulls out the real teaching, and becomes the context that trains an AI content team to sound like you.
01 · The one idea
The Model Is Frozen. Context Compounds.
The AI does not get smarter. What compounds is the context you feed it. That captured layer is the brain.
Here is the thing nobody tells you. The AI model is frozen. It does not get smarter the more you use it. The weights are the same every session. What actually compounds is the context you feed it. So the whole game is capturing your teaching once, in a form the AI can read before every job.
That captured layer is the wikis. The wikis are the brain.
For a coach or a cohort operator that matters more than for almost anyone. Your product is your thinking. Every call is you explaining the hard stuff in a way that lands. Capture that and it stops being a one-off. Lose it and you pay to re-explain it forever.
02 · The mechanism
Brain, Heartbeat, Muscle
Three parts make it work: wikis, routines, and skills. They map to a body.
The video shows the brain. The reason it actually compounds is the heartbeat and the muscle wired around it. Three parts make it work, and they map to a body.
Wikis
Living, interlinked maps of what you know, in plain text. They hold the teaching.
Routines
Scheduled jobs that feed the wikis on a clock, so the brain fills itself.
Skills
Packaged methods that read the wikis, then act: ideas, drafts, answers.
Brain on its own is a folder of notes. Wire the heartbeat and the muscle around it and it becomes a system that fills itself and turns your calls into content.
03 · The brain
The Wikis
Living, interlinked maps of what you know. Meeting, Stories, and Content, in plain text.
The Meeting Wiki is the one in the video, and the one this guide builds. Every call you run becomes a set of linked markdown pages: people, concepts, the "why" behind decisions, and the teaching itself. Plain text on purpose. It survives any tool change, and any model can read it.
What each call turns into
People + clients
Who was on the call, what matters to them, what you have agreed over time.
Concepts + methods
The ideas you teach, built up across every session you explain them in.
Decisions + the why
What got decided and the reasoning behind it, so it is never re-litigated.
The teaching itself
The stories, metaphors, and analogies you use to make the hard stuff land.
What makes it a brain, not a folder
Synthesis happens when a call goes in, not when you search. A call is not dumped in raw. Claude reads the transcript and writes it up into the pages above, linked to the people and topics it touches. That is why it is "not just summaries, the teaching itself." The expensive thinking is done up front, so every later read is instant.
This is one wiki, doing one job well. Once it is running, it can feed other wikis too. That is the "where to take it next" section near the end.
Enjoying the guide?
Enter your details to unlock the remaining insights. We'll also send you the complete guide as a reference.
04 · The heartbeat
The Routines
Scheduled jobs that feed the wikis on a clock, so the brain fills itself off every call.
A wiki only becomes a brain if something writes to it on a cadence. That is the routine. Without it, you have an empty shell you keep forgetting to fill. Here is the loop on a real call.
You run a call (Fathom records it)
Routine fires on a schedule, no prompt from you
Pulls the transcript, synthesises it into the Meeting Wiki
Extracts the teaching: stories + metaphors into the Stories Wiki
Reindexes for fast search, mirrors to Pinecone for search by meaning
Flags fresh content ideas onto the stack
This is why "15 calls backlogged and the ideas keep stacking." Nobody is doing it by hand. The heartbeat runs whether you show up or not, and every call makes the brain bigger. Keep them as local scheduled routines: cheap, fast models for the filing, a stronger model only for the synthesis that needs judgement.
05 · The muscle
The Skills
Packaged methods that read the wikis, then act. Some write the wiki, some read it.
Skills are where the brain pays off. A skill is a packaged method that reads the relevant wiki before it acts. Two directions: skills that write the wiki, and skills that read it.
Skills that write the wiki
Ingest
Pull a call, synthesise it, file it into the Meeting Wiki as linked pages.
Story extraction
Mine the teaching, the metaphors and proofs, out of a transcript into the wiki's teaching pages.
Skills that read the wiki
Query
Ask the wiki: what did we decide with this client, pull that metaphor I used.
Content ideas
Scan the new teaching and drop fresh angles onto a stack.
Draft in your voice
Pull your real stories and phrasing from the wiki first, then write. On-voice, not generic.
The content team does not improvise your voice. Every drafting skill starts from the wiki: your real stories, your phrasing, the teaching pulled from your calls. That is what makes the AI sound like you instead of generic AI slop.
06 · The payoff
The Two Jobs
Teaching into content ideas, and the wiki as the training context for an AI content team.
The wiki does two jobs. Here is how each actually runs once the brain is filling itself.
Teaching into content ideas
The routine synthesises the call. A content-ideas skill scans the new teaching and stories and drops fresh angles onto a stack. Your best on-call explanation becomes a post idea before you have left the meeting.
The wiki trains your AI content team
The teaching captured in your meeting wiki is the context layer the content team reads. When a draft is needed, the skill pulls your relevant stories and voice from the wiki, then writes. Trained on you, not by fine-tuning a model, but by feeding it your wiki every single time.
Remember the one idea: the model is frozen. The wiki is the leverage. The team sounds like you because it reads you, every time, before it writes a word.
07 · Why it wins
Why This Beats Just Using AI
Captured teaching beats a blank page, line by line.
Everyone says "just use AI for your content." Here is why a captured brain beats that, line by line.
The one-line version: calls go in through routines, teaching gets synthesised into wikis, skills read those wikis to ship ideas and on-voice content. The brain fills itself, and everything you build on top starts from what you already know instead of a blank page.
08 · Build it
The Mega Prompt
Paste this into Claude Code and build your Meeting Wiki Brain, Fathom and Karpathy wired in.
This is the engine behind "comment BRAIN." Paste the prompt below into a fresh Claude Code session and it builds the whole thing with you: Fathom feeds it, the wiki synthesises and compounds, skills turn it into ideas and on-voice content. It is built on Andrej Karpathy's LLM-maintained wiki design: raw sources stay immutable, the LLM owns the wiki, the schema is config. Synthesis happens at ingest, not retrieval at query time.
Tools installed
Claude Code and the CLIs set up, git linked. The fundamentals from the main orchestration guide.
Fathom recording
Fathom is capturing your calls, and you have API access to pull the transcripts.
An orchestrator (ideal)
A CLAUDE.md that holds your brand voice, so the wiki matches how you actually sound.
The Meeting Wiki Brain mega prompt
You are setting up my Meeting Wiki Brain: a persistent, LLM-maintained wiki that captures the teaching from every call I run, turns it into content ideas, and becomes the context that lets an AI content team write in my voice. We are following Andrej Karpathy's LLM wiki design (https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). Read that article first if you can fetch it, so you build to its model, not a generic notes folder.
The core principle, from Karpathy: do NOT just retrieve raw transcripts at query time. Maintain a persistent wiki that compounds. The expensive thinking (synthesis, linking, cross-referencing) happens when a call goes IN, so every later read is fast and rich. You are the disciplined maintainer. I curate the sources (the calls) and ask the questions. You do all the bookkeeping.
Do NOT start writing files yet. Work in phases. Tell me what you find at each step.
PHASE 0: READ WHAT EXISTS
- Look at this project root. If there is an orchestrator (CLAUDE.md), read it so you learn my brand voice, my businesses, and my tone. The wiki should match how I sound.
- Check whether any wiki, Pinecone config, or Fathom access already exists. Report before changing anything.
- Confirm I have Fathom API access (a key or a connected Fathom MCP). If not, stop and tell me how to get it, because the whole pipeline depends on pulling transcripts.
PHASE 1: CONFIRM SCOPE WITH ME
Ask me, briefly:
- Which calls feed this: all my calls, or just coaching and cohort sessions? Any I should exclude (internal, personal)?
- My programs or cohorts, so calls can be tagged to the right one.
- My content channels and formats (so the content-ideas job aims at the right output).
- My brand voice in one example, if it is not already in the orchestrator.
- Where client or member data must stay walled off (isolation matters).
Then show me a short plan before building.
PHASE 2: BUILD THE THREE LAYERS (Karpathy's architecture)
Set up the wiki as three distinct layers. Keep them separate, this is the whole point.
1. RAW SOURCES (immutable): a place to store the pulled Fathom transcripts verbatim. You READ these but NEVER edit them. They are the source of truth you synthesise from. Store them locally (for example a SQLite table or a transcripts folder) keyed by a stable call id.
2. THE WIKI (you own this): markdown pages you create and maintain. Use Karpathy's page types:
- entity pages: people, clients, cohorts, programs, recurring topics.
- concept pages: the ideas and methods I teach.
- connection pages: how things relate, the "why" behind a decision.
- a candidates area for low-confidence drafts that wait for my approval before they are promoted.
Pages carry light frontmatter (title, type, created, updated, confidence) and link to each other with [[wiki-links]]. Markdown is the truth: durable, rebuildable, readable by any tool or model.
Stand up THREE wikis that work together:
- Meeting Wiki: every call, synthesised and filed. The spine.
- Stories Wiki: the teaching itself, extracted. My anecdotes, metaphors, analogies, and proofs, in my own words. This is what makes content sound like me.
- Content Wiki: my brand voice, positioning, and the assets that already worked, so new content starts from what works.
3. THE SCHEMA (configuration): a WIKI.md file at the root of the wiki that is the maintainer contract. It defines the structure, the page conventions, the link rules, how confidence and candidates work, and the ingest, query, and lint workflows below. This is how you stay a disciplined maintainer across hundreds of pages. Treat WIKI.md as the rules you follow every time you touch the wiki.
PHASE 3: BUILD THE ENGINE (deterministic bookkeeping)
Keep the mechanical work in a small script (for example wiki.py), separate from your synthesis. It handles:
- index.md: a catalogue of every page, by category, regenerated on every ingest. (Karpathy's special file.)
- log.md: an append-only, machine-parseable record of every action, with consistent prefixes. (Karpathy's special file.)
- reindex: rebuild index.md, a SQLite full-text search table, and the link graph from the pages.
- pinecone (optional but recommended): embed each page into a vector store so the wiki is searchable by meaning, not just keywords. Reuse my Pinecone setup from stage 07 if it exists. This is the backup brain and the meaning-search layer.
Synthesis is yours (the LLM). Bookkeeping is the script. Do not blur them.
PHASE 4: BUILD THE THREE OPERATIONS (Karpathy: ingest, query, lint)
Build each as a skill so it runs the same way every time.
- INGEST: given a call, read the raw transcript, then update the wiki. Create or update the relevant pages (expect to touch 10 to 15 in a pass), add cross-links, extract the teaching into the Stories Wiki, and log it. Low-confidence items go to candidates for my approval. This is synthesis, not a summary dump.
- QUERY: answer a question against the wiki. Read index.md first, then drill into pages, then fall back to full-text and meaning search. If an answer is valuable, file it back as a page so the exploration becomes permanent knowledge.
- LINT: periodically audit the wiki for contradictions, stale claims, orphaned pages, and missing cross-references. Auto-fix the safe mechanical ones, queue the judgement calls for me.
PHASE 5: WIRE THE FATHOM PIPELINE
Connect the note taker to the brain.
- A pull step that fetches new Fathom recordings and their transcripts via the Fathom API or MCP, and stores them in the raw-sources layer (immutable), keyed by Fathom call id so nothing is pulled twice.
- Tag each call to the right cohort, client, or program from Phase 1.
- Hand each new transcript to the INGEST skill so it is synthesised into the Meeting Wiki and the teaching is extracted into the Stories Wiki.
- Keep secrets in .env, never in the wiki or the chat.
PHASE 6: THE TWO JOBS (this is the payoff in the video)
- Job 1, content ideas: a skill that scans freshly ingested teaching and stories and drops content ideas onto a running stack, aimed at my channels and formats. My best on-call explanation becomes a post idea before I have left the call.
- Job 2, train the AI content team to sound like me: wire my content and drafting skills so they READ the Stories Wiki and Content Wiki BEFORE they write. The team is not fine-tuned, it is fed my wiki every time. Pulling my real stories and phrasing first is what makes drafts sound like me instead of generic AI.
PHASE 7: SET THE CADENCE (so it compounds)
A wiki only compounds if something writes to it on a clock. Set up local scheduled routines:
- An ingest routine that files new Fathom calls automatically (after each call, or daily).
- A weekly insights routine that re-reads recent calls, surfaces themes, and refreshes the content stack.
- A lint routine on a slower cadence to keep the wiki healthy.
Tier the models: a cheap fast model for filing and bookkeeping, a stronger model for the synthesis that needs judgement.
RUN + VERIFY
- Backfill: pull my recent Fathom calls (I will tell you how many) and run them through ingest, so the wiki starts full, not empty. The video had 15 backlogged, do mine.
- Trace one call end to end in front of me: Fathom pull, raw stored, pages created and linked, stories extracted, content ideas stacked.
- Show me index.md, the log, a sample Meeting Wiki page, and a sample Stories Wiki page.
- Run a query ("what did I teach about X", "pull my metaphor for Y") and show it answers from the wiki.
- Confirm secrets are in .env, raw sources are never edited, and any cross-client or cross-member data is walled off.
CONSTRAINTS
- Raw sources are immutable. You read transcripts, you never edit them. The wiki is where your synthesis lives.
- Synthesis at ingest, not at query time. Do the thinking when a call goes in.
- Nothing goes out as content without my approval. The brain drafts and stacks ideas, I approve what ships.
- Keep client and member data isolated. No cross-bleed between cohorts or clients.
- Match my brand voice in everything you write into the Content and Stories wikis.
Start with Phase 0. Tell me what you find, then ask your Phase 1 questions.Two rules people break
Raw stays raw. The Fathom transcripts are the immutable source of truth. Your synthesis lives in separate markdown pages. And backfill first. Run your backlog through ingest on day one so the wiki starts full, then the routine keeps it filling with no effort.
09 · What you could do next
Where To Take It Next
Once the meeting wiki is running, it can feed a stories wiki or pair with a content wiki to spot trends.
This guide builds one thing well: the Meeting Wiki. Once it is running and filling itself, it becomes the foundation other wikis can grow from. Two natural next steps, neither required to get value from the meeting wiki today.
Spin the teaching into its own brain
Your meeting wiki already captures the stories and metaphors you use on calls. The next step is to extract those into a dedicated Stories Wiki: your anecdotes and proofs in your own words, in one place. Now any drafting job can pull a real story instead of inventing one.
Link calls to what actually lands
Build a second wiki from all your social and published content, then link it to the meeting wiki. Now you can see trends: which on-call teaching turns into content that performs, and which strong ideas you have never published. Your calls and your content start talking to each other.
This is where the meeting wiki stops being a single tool and starts becoming an operating system: many wikis, linked, each making the others sharper. The full picture is in the AI Operating System guide. For now, get the meeting wiki live first. Everything else builds on it.
The brain fills itself
The video sells the outcome. This is the engine: wikis as the brain, routines as the heartbeat that fills it, skills as the muscle that turns it into content and a team that sounds like you. The meeting wiki is one organ. The full operating system wires every organ together.
Part of the AI Operating System handbook.