Möte-till-wiki-gapet: Varför dina samtal ännu inte flödar in i din kunskapsbas

I sitt inlägg från april 2026 som beskrev en LLM-underhållen kunskapsbas räknade Andrej Karpathy upp de uppenbara användningsfallen. Personliga anteckningar. Forskning. Kod. Och sen, nästan i förbifarten, namngav han det som borde ha fått varje grundare av mötesprogramvara att räta på ryggen:

"Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. The wiki stays current because the LLM does the maintenance that no one on the team wants to do."

Mötestranskript. Kundsamtal. Listade som primärt källmaterial för det självunderhållande wiki-mönstret. Inte som en eftertanke — som ett namngivet input, bredvid Slack och projektdokument.

Det har nu gått flera veckor sedan det inlägget. Under tiden har en våg av mötesverktyg lanserat Model Context Protocol-servrar, tagit in nya rundor och ompositionerat sig som "kunskapsbaser". Och ändå, om du läser release notes noggrant, gör inget av dem det Karpathy beskrev. Inte ett. Branschen har dragit rören, men rören flödar bara i en riktning.

Detta är möte-till-wiki-gapet. Det är den mest värdefulla obyggda produkten i möte-AI-kategorin, och det är märkligt att den fortfarande är obyggd.

MCP-vågen: Varje mötesverktyg blev uppkopplat

Mellan slutet av 2025 och början av 2026 skeppade varje seriöst mötesverktyg en MCP-server. Tajmingen var inte tillfällig — MCP blev de facto-standarden för att koppla AI-agenter till extern data, och ingen mötesleverantör ville vara den som en agent inte kunde läsa.

Listan är nu lång nog att läsas som en kategoriinventering:

• Otter.ai skeppade en officiell MCP-server med OAuth, som stöder både Claude och ChatGPT som klienter. Agenter kan söka i transkript, dra ut action items och fråga mötesmetadata.
• Fireflies.ai släppte sin officiella MCP tillsammans med "AskFred" — en chatbot som svarar på frågor över varje möte — och en "Knowledge Base"-funktion som föreslår svar under pågående samtal.
• Granola nådde en värdering på 1,5 miljarder dollar i mars 2026 och lanserade sin officiella MCP-server i februari. Agenter kan fråga mot anteckningar, transkript och highlights över en användares Granola-bibliotek.
• Read.ai introducerade Search Copilot, ett enhetligt retrieval-lager över möten, e-post och chatt, exponerat via MCP.
• Circleback byggde en enda MCP-connector som spänner över möten, e-post och kalender och positionerade sig som en tvärytekontext-leverantör.
• tl;dv skeppade en officiell MCP och registrerade den i det publika MCP-registret.
• Fathom är tillgänglig via en community-MCP genom Trutos connector-lager.

Läs listan som ett branschbeslut. Kategorin enades kollektivt, inom loppet av några månader, om att AI-agenter behöver strukturerad åtkomst till mötesdata. Det är ett verkligt skifte. För två år sedan var mötesverktyg stängda silos vars värdeerbjudande var ett snyggt sammanfattningsmejl. Nu är de kontext-leverantörer för vilken agent du än råkar använda.

Och ändå.

Varenda en är read-only

Här är observationen som betyder mer än själva listan: varje mötes-MCP-server som skeppats så här långt exponerar läs-operationer. Sök i transkript. Hämta sammanfattningar. Fråga action items. Lista möten. Hämta deltagare. Returnera highlights.

Ingen av dem skriver tillbaka.

Ingen tar ett möte som just avslutats och uppdaterar en projektsida. Ingen underhåller en "Person: John Smith"-post som ackumulerar varje referens till John över dussintals samtal. Ingen håller en beslutslogg som spänner över möten och taggar varje post med vem som beslutade den och vad den ersatte. Ingen syntetiserar "allt Kund Y har sagt om prissättning över de senaste fem samtalen" till en persistent artefakt du kan öppna imorgon. Ingen märker när tisdagens möte motsade ett beslut från förra månaden och flaggar motsägelsen.

Pipelinen bryter vid det mest värdefulla steget. Capture funkar. Transkribering funkar. Retrieval funkar. Det som inte funkar — det ingen produkt för tillfället gör automatiskt — är den del Karpathy faktiskt beskrev: att kompilera samtal till en kunskapsbas som ackumuleras.

MCP-vågen kopplade möten till agenter. Den kopplade inte möten till kunskap.

Granola-begränsningen

Granola är den renaste illustrationen av gapet, eftersom det är den produkt de flesta skulle nämna om de fick frågan vilket mötesverktyg som är bäst. 1,5 miljarder dollar i värdering från och med mars 2026. Genuint utmärkt UX. Älskad av den sortens power users som, i vilken annan era som helst, hade byggt det här själva.

Och ändå skrev en Granola-power user nyligen något som bör läsas som en diagnos av hela kategorin:

"Granola doesn't have a place to store answers you get when you query your meetings. You have to copy and paste into a separate notes tool."

Sitt med det ett ögonblick. Den mest välkapitaliserade, mest väldesignade produkten i möte-AI-kategorin fångar möten vackert, låter dig ställa frågor över dem, och kastar sen bort svaren. Resonemanget LLM:en just utförde över ditt korpus — syntesen, korsreferenserna, "här är vad kunden har sagt om prissättning över fem samtal" — lever i ett chattfönster. När chattfönstret stängs är resonemanget borta. Vill du behålla det, copy-paste.

Det här är inte ett Granola-fel. Det är ett kategorifel. Granola gör precis vad varje annat verktyg i området gör. Fråge-gränssnittet behandlas som produkten, och kunskapen som uppstår ur att fråga behandlas som flyktig. Det finns ingen "wiki" i Karpathy-bemärkelsen — ingen persistent, LLM-underhållen artefakt som nästa fråga kan bygga vidare på.

Granola fångar briljant. Den kompilerar inte.

Otters pivot är bevis på att branschen vet

Vill du ha bevis på att kategorin är medveten om gapet, titta på Otter.

Sam Liang, Otters VD, har under det senaste året explicit ompositionerat Otter som en "corporate meeting knowledge base". Frasen finns nu i keynotes, decks, pressreleaser. Det är företagets uttalade riktning. Språket är exakt rätt. Språket ligger också före produkten.

Otters faktiska yta, från och med början av 2026, är fortfarande ett platt söklager över transkript med förbättrad sammanfattning och en chatbot ovanpå. Ingen entitetsupplösning över möten. Ingen beslutslogg som ackumuleras. Ingen "person"- eller "projekt"- eller "kund"-sida underhållen av LLM:en. Ingen motsägelsedetektering. Ingen kompilerad artefakt i Karpathy-bemärkelsen. Det är ett bättre arkivskåp, ompositionerat som kunskapsbas.

Det är värt att påpeka, inte som kritik utan som bevis. Den största incumbenten i kategorin har bestämt att "kunskapsbas" är rätt positionering. De lägger marknadsföringsmuskler bakom det. Det de ännu inte har gjort är att bygga det. Gapet mellan positioneringen och produkten är det gap den här texten handlar om.

Obsidians gör-det-själv-gravgård

Om verktygen inte gör det, gör användarna det? Ja — och smärtsamt.

Obsidian-communityt har varit kanariefågeln i den här gruvan i minst ett år. Power users som förstår Karpathy-mönstret intuitivt (många av dem körde Dataview och länkade-anteckningar-workflows långt innan LLM:er) har försökt brygga möten in i sina valv med allt mer invecklade hembyggen:

• Shadow (shadow.do) — sparar mötestranskript som .md-filer i en synkroniserad mapp. Grundläggande, funktionellt, ingen kompilering.
• Char — ett open source-projekt som transkriberar systemljud plus typade anteckningar till .md-filer, avsett att släppas i ett Obsidian-valv.
• tsheil/obsidian_plugin_AI_meeting_notes — ett community-plugin som använder lokal Whisper och Ollama för en helt offline-pipeline. Funkar, men riktar sig till utvecklare som är bekväma med att konfigurera modellservrar.
• SystemSculpts workflow, publicerad i februari 2026, är en flerstegs manuell procedur: spela in, transkribera, köra en prompt, klistra in resultatet i Obsidian, länka för hand.

Varje lösning är fragmenterad. Varje är manuell i ett eller flera steg. Varje är byggd för någon som redan är bekväm med lokal inferens, custom scripts eller skör automatisering. Och varje finns till för att de kommersiella verktygen inte gör det.

Det är en betydande signal. När de mest tekniskt sofistikerade användarna i en kategori bygger sina egna halvlösningar av silvertejp är efterfrågan verklig och utbudet trasigt.

Varför ingen har byggt det

Det är värt att fråga ärligt varför det här gapet består. Svaret är inte att grundare är lata eller att idén är obskyr. Svaret är att det är genuint svårt och genuint omodernt.

Den tekniska komplexiteten är verklig. Läsning är enkelt. Skrivning är svårt. En read-only MCP som returnerar transkript-chunks är ett helgprojekt. Ett system som tar ett möte, löser entiteter mot en persistent graf, upptäcker konflikter med tidigare beslut, uppdaterar rätt wiki-sidor och gör allt detta tillförlitligt nog att användare litar på outputen — det är ett månad-till-år-ingenjörsproblem. Det kräver scheman, idempotens, entitetsupplösning, och den sortens tysta tillförlitlighet som inte demoar bra.

Integritet är ett verkligt hinder. Att pumpa mötesljud in i en kontinuerligt LLM-underhållen wiki — en som rör vid namngivna individer, kundsamtal och interna beslut — väcker verkliga GDPR- och datasuveränitetsfrågor. Vem äger den kompilerade wikin? Var bor den? Vad händer när en anställd slutar och begär radering? De här frågorna har svar, men svaren kräver arbete, och arbetet måste göras innan den första kunden onboardas.

VC:er belönar det inte. Mötesverktyg värderas på AI-funktioner som syns i en lanseringstweet: en bättre sammanfattning, ett snabbare transkript, en live copilot. Kunskapsgrafer är en långsam förbränning. Du kan inte skärmdumpa en självunderhållande wiki på samma sätt som du kan skärmdumpa en autogenererad sammanfattning. Kategorins finansieringsdynamik har i tysthet tryckt grundare mot de demo-vänliga funktionerna och bort från de sammansatta.

Second brain-gravgården kastar en lång skugga. Evernote. Roam. Skiff. Limitless (tidigare Rewind). Mem. Investerare har sett knowledge-management-produkter misslyckas, upprepat, i ett decennium. Allt som luktar "bygg en andra hjärna" triggar mönstermatchning mot dessa förluster. Faktumet att LLM:er fundamentalt har förändrat ekonomin i kunskapskompilering har ännu inte fullt ut registrerats.

De flesta grundare bygger verktyg, inte workflows. Det är enklare att bygga ett bättre UI än att tänka om hur möteskunskap ska flöda in i resten av ett företags informationsarkitektur. Verktyg-vs-workflows-distinktionen är skillnaden mellan en feature och en produkttes, och kategorin har mestadels valt features.

Inget av dessa skäl är diskvalificerande. De är helt enkelt skälen till att gapet fortfarande är ett gap.

Vad rätt produkt skulle göra

Dra ner frågan till grundprinciperna. Om du byggde produkten Karpathy beskrev, specifikt för möten, vad skulle den faktiskt göra?

• Fånga privat. Bot-fri inspelning, lokalt bearbetbar där möjligt, GDPR-anpassad som default. Du kan inte be användare pumpa känsliga möten in i en kontinuerligt kompilerad wiki om inte capture-lagret är pålitligt.
• Extrahera entiteter automatiskt från varje möte. Personer, företag, projekt, beslut, åtaganden, datum. Inte som taggar på ett transkript, utan som förstklassiga objekt i en persistent graf.
• Syntetisera över möten till persistenta artefakter. När du frågar "vad har kunden sagt om prissättning över de senaste fem samtalen", ska svaret inte vara ett chattsvar som försvinner. Det ska vara en markdown-fil som finns imorgon och uppdateras efter det sjätte samtalet.
• Skriv tillbaka, inte bara läsa. MCP-ytan ska exponera uppdateringsoperationer: "lägg till i den här beslutsloggen", "skapa en personpost", "flagga den här motsägelsen". Read-only är en startpunkt, inte produkten.
• Definiera kompileringsschemat explicit. En CLAUDE.md- eller AGENTS.md-liknande fil som berättar för LLM:en hur mötesinnehåll mappar in i wikin: vad som räknas som ett beslut, hur personer slås samman, hur en projektsida ser ut. Schemat är produkten lika mycket som LLM:en är det.
• Bevara raw och wiki separat. Karpathys raw/ vs wiki/-split applicerat på samtal: transkripten är oföränderliga, granskningsbara, sanningskälla. Wikin ägs av LLM:en, är omskrivbar och alltid aktuell. Du kan alltid regenerera wikin från det råa. Du kan aldrig regenerera det råa.

Det är konturen. Det är inget mysterium. Det är en specifikation som kunde skrivas in i en PRD den här veckan. Skälet till att den inte existerar än är listan med hinder i föregående avsnitt, inte brist på klarhet kring målet.

Ett företag försöker

Proudfrog är den produkt som mest explicit riktar sig mot detta gap — privacy-first capture, automatisk entitetsextraktion, och möteskunskap som är designad för att ackumuleras snarare än försvinna. Det finns mer att bygga, och den ärliga inramningen är att hela kategorin fortfarande sträcker sig efter Karpathy-nivån. Men riktningen är den som den här texten har beskrivit.

Vill du ha det längre argumentet för varför kompilerad kunskap slår platta transkript i mötesskala, är kompanjonstexten Karpathys LLM-wiki och vad det betyder för möteskunskap. För den praktiska workflowen, se den kompletta workflow-guiden. För hur det här spelar ut dag-för-dag är knowledge workers-användningsfallet den närmaste beskrivningen. Och vill du se hur landskapet står sig lägger jämförelsesidan fram det ärligt.

Gapet är verkligt. Någon kommer att stänga det. Den enda frågan är vem och när.

---

Vanliga frågor

Vad är en MCP-server och varför spelar den roll för möten?

Model Context Protocol (MCP) är en standard, introducerad av Anthropic och snabbt adopterad i branschen under 2025, som låter AI-agenter koppla upp sig mot externa verktyg och datakällor genom ett konsekvent gränssnitt. För möten spelar den roll eftersom det är rörläggningen som en agent — Claude, ChatGPT, eller vad det nu är — kan sträcka in i ditt mötesverktyg och fråga mot transkript, sammanfattningar, action items och metadata utan en egen integration per leverantör. Varje större mötesverktyg skeppar nu en MCP-server, vilket är varför agenter plötsligt kan "se" dina möten. Begränsningen är att dagens mötes-MCP:er är read-only: agenter kan fråga, men inget skriver tillbaka resultaten till en persistent kunskapsbas.

Varför skriver inte mötesverktygen bara tillbaka till min anteckningsapp?

För att skriva tillbaka är mycket svårare än att läsa, och mycket mindre demo-vänligt. En läs-MCP är ett tunt omslag runt ett sök-API. En skriv-MCP som underhåller en kompilerad, självkonsistent kunskapsbas måste göra entitetsupplösning (är det här "John" samma John som förra veckan?), konfliktdetektering (motsäger det här beslutet ett tidigare?), schemahantering (hur ser en projektsida ut?) och idempotenta uppdateringar (vad händer om samma möte bearbetas två gånger?). Den måste också vara pålitlig nog att användare låter den modifiera sina anteckningar utan tillsyn. De flesta leverantörer har valt att skeppa den enkla halvan och kalla det en kunskapsbas.

Hur skiljer sig detta från Otters "knowledge base"-funktion?

Otters positionering är en corporate meeting knowledge base, men den underliggande produkten är fortfarande platt sökning och sammanfattning över transkript, med en chatbot ovanpå. Det finns ingen persistent, kompilerad wiki. Det finns ingen beslutslogg som ackumuleras över möten. Det finns ingen entitetssida som uppdateras efter varje samtal. Marknadsföringsspråket är rätt; ingenjörskonsten är inte där än. Gapet mellan "sökbart mötesarkiv" och "LLM-underhållen kunskapsbas i Karpathy-bemärkelse" är gapet den här artikeln handlar om, och Otter är fast på den sökbara-arkiv-sidan av det.

Skulle jag kunna bygga det här själv med Karpathys mönster och ett mötesverktygs API?

Tekniskt ja, och några i Obsidian-communityt har försökt. Det vanliga receptet är: använd ett mötesverktygs export eller MCP för att hämta transkript, kör dem genom en lokal eller moln-LLM med en prompt som extraherar entiteter och beslut, och lägg resultaten i markdown-filer i ett valv. Det här funkar som ett helgprojekt för en enstaka användare. Det bryter ihop när du behöver tillförlitlighet, entitetsupplösning över möten, konfliktdetektering, fleranvändarsamarbete eller integritetsgarantier. DIY-lösningarna i den här artikeln — Shadow, Char, community-pluginsen för Obsidian, SystemSculpts workflow — är alla försök i den riktningen, och alla stannar kort för vad en riktig produkt skulle behöva göra.

Kommer GDPR tillåta det här i Europa?

Ja, med omsorg. GDPR förbjuder inte mötestranskribering eller LLM-kompilerade kunskapsbaser. Den kräver en laglig grund för behandling, dataminimering, ändamålsbegränsning, rätt till radering och uppmärksamhet kring gränsöverskridande överföringar. En välutformad kompilerad-kunskap-produkt hanterar dessa genom att göra fångst explicit och samtyckt, hålla råtranskripten separata från den kompilerade wikin (så raderingsbegäran kan rent ta bort båda), bearbeta i europeiska regioner där möjligt, och vara transparent om vad LLM:en gör med datan. Hindret är inte regleringen. Hindret är att göra det rätt kräver ingenjörs- och juridiskt arbete som de flesta leverantörer har skjutit upp.