Så bygger du en LLM-wiki i Karpathy-stil av dina möten (Obsidian-guide)

Varför den här artikeln finns

Den 2 april 2026 publicerade Andrej Karpathy ett arbetsflöde som vände upp och ner på AI-baserad kunskapshantering. Kärnidén: sluta använda vektordatabaser och RAG-pipelines för personliga kunskapsbaser. Lägg i stället råa dokument i en mapp, låt en LLM "kompilera" dem till en strukturerad markdown-wiki och använd Obsidian som frontend. Inom fem dagar hade originaltweeten över 16 miljoner visningar, hans GitHub-gist över 5 000 stjärnor och minst 15 fungerande implementationer hade dykt upp på GitHub.

Men det finns ett gap som ingen pratar om: Karpathy nämner uttryckligen mötestranskript som en källtyp, men inget verktyg matar faktiskt in möten i hans wiki-mönster automatiskt. Alla mötesverktyg — Otter, Fireflies, Granola, Read.ai, Circleback — har lanserat en Model Context Protocol-server (MCP) det senaste halvåret, men de är alla read-only. Inget av dem kompilerar möten till en beständig, strukturerad kunskapsbas.

Den här artikeln är den praktiska guiden för att överbrygga gapet. Om du har läst Karpathys gist och vill ha dina möten i din Obsidian-vault som förstaklassens källor finns det två sätt att göra det redan idag.

Värt att läsa först: vår djupare analys av gapet mellan möten och wiki på Proudfrog, som förklarar varför de stora mötesverktygen inte har byggt det här själva.

En snabb sammanfattning av Karpathys wiki-mönster

Om du inte har läst hans gist är arkitekturen enkel:

your-wiki/
├── raw/                    # Immutable source documents
│   ├── articles/
│   ├── papers/
│   └── meetings/           # ← What this tutorial adds
├── wiki/                   # LLM-owned compiled markdown
│   ├── index.md
│   ├── people/
│   ├── projects/
│   └── decisions/
└── CLAUDE.md               # Schema file: how the LLM should compile

Tre operationer driver systemet:

1. Ingest — Bearbeta nya källor från raw/, uppdatera korsreferenser i hela wikin
2. Query — Läs index.md, gräv ner dig i relevanta sidor, syntetisera ett svar
3. Lint — Granska efter motsägelser, övergivna sidor och inaktuella påståenden

Den centrala insikten: i måttlig skala (~100 källor, hundratals wiki-sidor) presterar ett välunderhållet markdown-index bättre än vektorsökning. LLM:en navigerar strukturerade filer direkt. Inga embeddings, ingen RAG-infrastruktur, ingen retrieval-pipeline.

För den kanoniska beskrivningen av hur det fungerar, läs Karpathys gist och vår kompletta arbetsflödesguide på Proudfrog.

Problemet med möten som källa

Karpathys mönster fungerar utmärkt med artiklar och papers eftersom verktyg som Obsidian Web Clipper omvandlar webbsidor till ren markdown med ett klick. Möten är annorlunda.

Ett möte börjar som ljud. För att få in det i raw/meetings/ behöver du:

1. Inspelning (mötesverktyget)
2. Transkribering med talaridentifiering (mötesverktyget)
3. Export till markdown (de flesta mötesverktyg gör inte det här rent)
4. Ett sätt att hålla råtranskriptet stabilt medan wikin kompileras om (de flesta mötesverktyg lagrar transkript i sin egen databas, inte i ditt filsystem)

Det är här de flesta arbetsflöden går sönder. Mötesverktyg är optimerade för "sök i tidigare möten", inte för "ge mig en markdown-fil jag äger för alltid". Transkripten ligger i någon annans databas. Och även om du kan exportera är formatet oftast inkonsekvent — ibland JSON, ibland en PDF, ibland en UI-dump där talaretiketter försvinner.

Det finns två sätt att lösa det här idag: ett manuellt export-flöde, eller en MCP-server som exponerar möten som en queryable resurs.

Väg A: Manuell markdown-export

Den enklare metoden. Fungerar med alla mötesverktyg som låter dig exportera ett transkript som text eller markdown.

Proudfrog, det nordiska mötestranskriberingsverktyget vi byggt på Up North AI, exporterar varje möte som en markdown-fil med talaretiketter, tidsstämplar och frontmatter. Exporten ser ut så här:

---
title: "Q1 Roadmap Review with Acme Corp"
date: "2026-04-03"
participants: ["Klara Lindqvist", "Erik Nilsson", "Sarah Chen (Acme)"]
duration_minutes: 47
language: "en"
source: "proudfrog"
---

## Transcript

**Klara Lindqvist** [00:00:14]
Welcome everyone. I'd like to start by walking through the three things we
agreed to ship this quarter and where we are on each.

**Sarah Chen (Acme)** [00:00:31]
Sounds good. I have some concerns about the timeline on the second item but
let's go through them in order.

...

Släpp den filen i raw/meetings/2026-04-03-acme-q1-roadmap.md. Det är allt. Din wiki-ingest-körning plockar upp den nästa gång.

För andra mötesverktyg behöver du städa upp exporten — ta bort headers, normalisera talaretiketter, konvertera tidsstämplar. Ett shell-skript på 30 rader klarar det oftast, men friktionen blir påtaglig om du har möten varje dag.

Väg B: En MCP-server för möten

Det här är den mer intressanta metoden. I stället för att manuellt exportera transkript pekar du din AI-agent (Claude Code, Cursor, Codex etc.) på en Model Context Protocol-server som exponerar möten som queryable resurser.

Vi bygger det här för Proudfrog just nu. Proudfrogs MCP-server (för närvarande i beta) exponerar:

• list_meetings — Listar nyligen genomförda möten, filtrerbara på datum, deltagare, projekt
• get_meeting — Hämtar ett fullständigt transkript via ID, formaterat som markdown med frontmatter
• search_meetings — Semantisk sökning över alla dina möten
• list_speakers — Hämtar den kanoniska listan över identifierade talare i ditt bibliotek
• get_decisions — Hämtar extraherade beslut från ett möte eller ett datumintervall

När det är konfigurerat kan din agent mata in möten i wikin på begäran:

You: Ingest all meetings from this week into the wiki

Claude Code:
- Calls list_meetings(after="2026-04-01")
- Returns 12 meetings
- For each meeting, calls get_meeting(id)
- Writes each transcript to raw/meetings/
- Runs the wiki ingest pass
- Updates index.md, people/, projects/, decisions/

MCP-metoden har tre fördelar jämfört med manuell export:

1. Inget manuellt steg — Agenten hämtar det den behöver när den behöver det
2. Komponerbar med andra källor — Samma agent kan också anropa din GitHub-MCP, Notion-MCP etc. och kompilera kunskap över flera källor i en enda körning
3. Idempotent — Att köra om ingesten skapar inga dubbletter; agenten kollar raw/ efter det som redan finns

Proudfrogs MCP är i beta. Vill du ha tidig tillgång, maila oss eller titta i Proudfrogs roadmap.

Schemafilen: så lär du LLM:en vad den ska göra med möten

Karpathys gist föreslår en CLAUDE.md- eller AGENTS.md-fil i roten av din wiki för att definiera hur LLM:en ska kompilera innehållet. För möten behöver schemat några tillägg utöver Karpathys standardmall:

# Wiki Compilation Schema

## Source Types
- `raw/articles/` — long-form articles and blog posts
- `raw/papers/` — academic papers (PDFs converted to .md)
- `raw/meetings/` — meeting transcripts with frontmatter

## Meeting Ingest Rules

When processing a file from raw/meetings/:

1. Extract all named participants and update wiki/people/<name>.md
   - Add a new bullet under "## Meetings" with date, title, and key role
   - If the person is new, create the page from a template

2. Extract decisions made in the meeting
   - A decision is any statement matching: "we decided", "we agreed",
     "let's go with", "the plan is", etc.
   - Add each decision to wiki/decisions/<date>-<short-slug>.md
   - Cross-link to the source meeting in raw/

3. Extract action items
   - An action item is any commitment with an assignee
   - Add to wiki/people/<assignee>.md under "## Open commitments"
   - Mark as resolved when a later meeting confirms completion

4. Extract project mentions
   - Update wiki/projects/<project>.md
   - Add a "## Recent activity" entry pointing to the meeting

## Linting Rules

When running the lint pass on meeting-derived content:

- Flag contradictions: if a decision in meeting A conflicts with a
  decision in meeting B, surface both
- Flag stale commitments: action items older than 30 days with no
  resolution
- Flag orphaned people: speakers who appear in only one meeting and
  have no other context

Schemat är kontrollytan. LLM:en följer det vid varje ingest-körning, vilket innebär att din wiki över tid utvecklar en konsekvent form. Utan ett schema improviserar LLM:en — ibland bra, ibland oberäkneligt.

Exempelfrågor som faktiskt fungerar

När möten väl flödar in i wikin förändras frågorna du kan ställa kvalitativt. Några exempel från vår egen wiki:

Spåra åtaganden över möten:

Query the wiki: What did Sarah at Acme commit to in Q1, and which of
those commitments are still open?

Agenten läser wiki/people/sarah-chen-acme.md, går igenom hennes öppna åtaganden, korsrefererar beslutsloggar och returnerar en ren statusrapport. Ingen människa behövde underhålla listan — varje åtagande extraherades automatiskt under ingesten.

Hitta motsägelser:

Query the wiki: Did we make any decisions about the Acme Q1 timeline
that conflict with what we agreed in March?

Lint-körningen har redan flaggat motsägelser om de finns. Agenten läser lint-rapporten och lyfter fram dem med citat till källmötena.

Cross-meeting-syntes som beständig artefakt:

Query the wiki: Compile everything we know about Acme's pricing concerns
across all meetings into a single wiki page.

Agenten frågar wiki/projects/acme.md, går igenom de länkade besluten, hittar varje möte som nämner pricing och skriver en ny wiki-sida som sammanfattar tråden. Sidan består — nästa vecka uppdaterar nästa ingest-körning den inkrementellt i stället för att regenerera den från noll.

Det är vad Karpathy kallar "att kompilera kunskap en gång och hålla den aktuell, inte härleda den på nytt vid varje fråga". Det är också det som inget större mötesverktyg gör i dag.

Vad det här inte löser

Två ärliga reservationer:

1. Kostnad. Varje ingest-körning rör flera wiki-sidor. Lint-körningar skalar med wiki-storleken. Att köra det här på Claude Sonnet för personligt bruk är prisvärt; att köra det på Claude Opus över hundratals möten är det inte. Vi publicerar verkliga siffror när vi har några månaders användardata — sätt ett budgettak på din API-nyckel tills vidare.

2. Hallucinationskontaminering. Om LLM:en extraherar ett felaktigt åtagande från ett möte och skriver in det i wiki/people/<name>.md lever felet kvar i din wiki och påverkar framtida frågor. Steph Ango (en av Obsidians grundare) rekommenderar att man håller personliga anteckningar och agent-underhållet innehåll i separata vaults av exakt det här skälet. Vi håller med. Vi går djupare in på det i skeptikerns guide till LLM-wikis på Proudfrog.

Varför det är värt att bygga

Vi har lagt de senaste månaderna på att bygga Proudfrog kring en specifik hypotes: möten är rätt omfattning för en AI-underhållen kunskapsbas eftersom inputen är naturligt avgränsad. Du behöver inte bestämma vad som ska fångas — möten händer ändå. Och källmaterialet är så pass rikt att LLM-extraktion blir rimligt grundad.

Karpathys mönster validerar ansatsen från ett annat håll. Han visade att strukturerad markdown plus LLM-kompilering presterar bättre än RAG i praktisk skala. Vi har byggt infrastrukturen för att få det mönstret att fungera för en specifik källa: dina möten.

Vill du prova det idag ger Proudfrog dig markdown-exporten. MCP-servern är i beta — skriv upp dig på listan för tidig tillgång. Bygger du något liknande eller vill prata om hur kunskapsgrafer från möten passar in i din enterprise-AI-stack, hör av dig.

Vanliga frågor

Måste jag vara utvecklare för att använda det här arbetsflödet?

Väg A (manuell export) kräver ingen kod — släpp en markdown-fil i en mapp. Väg B (MCP) kräver att du konfigurerar en MCP-server i Claude Code, Cursor eller en annan agentklient. Det är en engångskonfiguration, inte löpande utveckling.

Vilka mötesverktyg fungerar med det här mönstret idag?

Alla verktyg som låter dig exportera ett transkript som text eller markdown. Proudfrog exporterar nativt som markdown med frontmatter. Otter, Fireflies och Granola låter dig kopiera transkript men du måste städa upp formatet. tl;dv exporterar markdown men utan konsekventa talaretiketter.

Hur skiljer sig det här från att bara använda Otters "ask my meetings"-funktion?

Otter (och Granola, och Fireflies) låter dig fråga tidigare möten via ett chattgränssnitt. Svaren försvinner efter varje session. Karpathys mönster bevarar svaren som wiki-sidor — så nästa gång du ställer en liknande fråga läser LLM:en den befintliga wiki-sidan i stället för att härleda svaret från råa transkript igen. Kunskap ackumuleras.

Vad är skillnaden mellan MCP och att bara anropa Proudfrogs API?

MCP standardiserar hur AI-agenter upptäcker och anropar verktyg. Med en MCP-server kan vilken agent som helst som pratar MCP (Claude Code, Cursor, Codex etc.) använda Proudfrog utan custom integrationskod. Utan MCP skulle du skriva en egen klient för varje agent. MCP är för AI-agenter vad HTTP är för webbläsare — läs mer om varför MCP är fundamentet som faktiskt fungerar.

Kan jag använda det här med lokala LLM:er i stället för Claude eller GPT?

Ja, med vissa förbehåll. Verktyg som Ollama och LM Studio kör open source-modeller (Gemma, Llama) lokalt, vilket löser kostnads- och integritetsfrågorna. Men modellkvaliteten spelar roll för kompileringsuppgifter — de mindre modellerna missar entitetsreferenser och producerar sammanfattningar av lägre kvalitet. Vi rekommenderar att du börjar med molnmodeller, validerar arbetsflödet och sedan utvärderar lokala modeller för ditt specifika användningsfall.

Vad gör Up North AI med det här?

Up North AI är en nordisk AI-konsultbyrå. Proudfrog är vår produkt — ett mötestranskriberingsverktyg byggt för nordiska språk med en kunskapsgraf som central värdeproposition. Vi hjälper företag bygga liknande AI-nativa kunskapssystem för sin egen data. Är det ditt problem, kom och prata med oss.