Møde-til-wiki-kløften: Hvorfor dine samtaler endnu ikke flyder ind i din vidensbase

I sit opslag fra april 2026, der beskrev en LLM-vedligeholdt vidensbase, opremsede Andrej Karpathy de åbenlyse brugsscenarier. Personlige noter. Forskning. Kode. Og så, næsten i forbifarten, navngav han det, der burde have fået enhver grundlægger af mødesoftware til at rette sig op:

"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ødetranskripter. Kundeopkald. Opført som primært kildemateriale for det selvvedligeholdende wiki-mønster. Ikke som en eftertanke — som et navngivet input, ved siden af Slack og projektdokumenter.

Der er nu gået flere uger siden det opslag. I den tid har en bølge af møde-værktøjer lanceret Model Context Protocol-servere, hentet nye runder og rebrandet sig selv som "vidensbaser". Og alligevel, hvis du læser release notes omhyggeligt, gør ingen af dem det, Karpathy beskrev. Ikke én. Branchen har koblet rørene, men rørene flyder kun i én retning.

Dette er møde-til-wiki-kløften. Det er det mest værdifulde ubyggede produkt i møde-AI-kategorien, og det er sært, at det stadig er ubygget.

MCP-bølgen: Hvert møde-værktøj blev forbundet

Mellem slutningen af 2025 og begyndelsen af 2026 sendte hvert seriøst møde-værktøj en MCP-server. Timingen var ikke tilfældig — MCP blev de facto-standarden for at forbinde AI-agenter til ekstern data, og ingen mødeleverandør ville være den, som en agent ikke kunne læse.

Listen er nu lang nok til at læses som en kategorioptælling:

• Otter.ai sendte en officiel MCP-server med OAuth, der understøtter både Claude og ChatGPT som klienter. Agenter kan søge i transkripter, hente action items og forespørge møde-metadata.
• Fireflies.ai udgav sin officielle MCP sammen med "AskFred" — en chatbot der besvarer spørgsmål på tværs af hvert møde — og en "Knowledge Base"-funktion der foreslår svar under live-opkald.
• Granola ramte en værdiansættelse på 1,5 mia. dollars i marts 2026 og lancerede sin officielle MCP-server i februar. Agenter kan forespørge noter, transkripter og highlights på tværs af en brugers Granola-bibliotek.
• Read.ai introducerede Search Copilot, et samlet retrieval-lag på tværs af møder, e-mail og chat, eksponeret via MCP.
• Circleback byggede en enkelt MCP-connector, der spænder over møder, e-mail og kalender, og positionerede sig som en tværsfladet kontekstleverandør.
• tl;dv sendte en officiel MCP og registrerede den i det offentlige MCP-register.
• Fathom er tilgængelig via en community-MCP gennem Trutos connector-lag.

Læs listen som en branchebeslutning. Kategorien blev kollektivt enige, inden for få måneder, om at AI-agenter har brug for struktureret adgang til mødedata. Det er et reelt skifte. For to år siden var møde-værktøjer lukkede siloer, hvis værditilbud var en pæn opsummerings-e-mail. Nu er de kontekstleverandører for hvilken som helst agent, du tilfældigvis bruger.

Og alligevel.

Hver eneste er read-only

Her er observationen, der betyder mere end selve listen: hver mødes-MCP-server, der er sendt indtil videre, eksponerer læse-operationer. Søg i transkripter. Hent resuméer. Forespørg action items. List møder. Hent deltagere. Returnér highlights.

Ingen af dem skriver tilbage.

Ingen af dem tager et møde, der netop sluttede, og opdaterer en projektside. Ingen af dem vedligeholder en "Person: John Smith"-post, der akkumulerer hver reference til John på tværs af dusinvis af opkald. Ingen af dem holder en beslutningslog, der spænder over møder og tagger hver post med hvem der besluttede den, og hvad den afløste. Ingen af dem syntetiserer "alt hvad Kunde Y har sagt om priser på tværs af de sidste fem opkald" til en persistent artefakt, du kan åbne i morgen. Ingen af dem bemærker, når tirsdagens møde modsagde en beslutning fra sidste måned, og flagger modsigelsen.

Pipelinen bryder ved det mest værdifulde trin. Capture virker. Transskribering virker. Retrieval virker. Det der ikke virker — det intet produkt på nuværende tidspunkt gør automatisk — er den del, Karpathy faktisk beskrev: at kompilere samtaler til en vidensbase, der akkumuleres.

MCP-bølgen forbandt møder til agenter. Den forbandt ikke møder til viden.

Granola-begrænsningen

Granola er den reneste illustration af kløften, fordi det er det produkt, de fleste ville navngive, hvis de blev spurgt, hvilket møde-værktøj der er bedst. 1,5 mia. dollars i værdiansættelse fra marts 2026. Genuint fremragende UX. Elsket af den slags power users, der i enhver anden æra ville have bygget dette selv.

Og alligevel skrev en Granola-power user for nylig noget, der bør læses som en diagnose af hele kategorien:

"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."

Sid med det et øjeblik. Det bedst-kapitaliserede, bedst-designede produkt i møde-AI-kategorien fanger møder smukt, lader dig stille spørgsmål på tværs af dem, og smider så svarene væk. Det ræsonnement, LLM'en netop udførte over dit korpus — syntesen, krydsrefereringen, "her er, hvad klienten har sagt om priser over fem opkald" — lever i et chat-vindue. Når chat-vinduet lukkes, er ræsonnementet væk. Vil du beholde det, copy-paste.

Dette er ikke en Granola-fejl. Det er en kategorifejl. Granola gør præcis, hvad hvert andet værktøj i området gør. Forespørgselsgrænsefladen behandles som produktet, og den viden, der opstår ved at forespørge, behandles som flygtig. Der er ingen "wiki" i Karpathy-forstand — ingen persistent, LLM-vedligeholdt artefakt, som den næste forespørgsel kan bygge videre på.

Granola fanger brilliant. Den kompilerer ikke.

Otters pivot er bevis på, at branchen ved det

Vil du have bevis på, at kategorien er bevidst om kløften, så se på Otter.

Sam Liang, Otters CEO, har det seneste år eksplicit repositioneret Otter som en "corporate meeting knowledge base". Frasen er nu i keynotes, deckene, pressen. Det er virksomhedens erklærede retning. Sproget er præcist rigtigt. Sproget er også foran produktet.

Otters faktiske overflade, fra begyndelsen af 2026, er stadig et fladt søgelag over transkripter med forbedret opsummering og en chatbot ovenpå. Ingen entitetsopløsning på tværs af møder. Ingen beslutningslog der akkumuleres. Ingen "person"- eller "projekt"- eller "kunde"-side vedligeholdt af LLM'en. Ingen modsigelsesdetektion. Ingen kompileret artefakt i Karpathy-forstand. Det er et bedre arkivskab, rebrandet som en vidensbase.

Dette er værd at påpege, ikke som kritik, men som bevis. Den største incumbent i kategorien har besluttet, at "knowledge base" er den rigtige positionering. De lægger marketingmuskler bag. Det de endnu ikke har gjort, er at bygge det. Kløften mellem positioneringen og produktet er den kløft, denne tekst handler om.

Obsidian DIY-kirkegården

Hvis værktøjerne ikke gør det, gør brugerne det så? Ja — og smerteligt.

Obsidian-communityet har været kanariefuglen i denne mine i mindst et år. Power users, der intuitivt forstår Karpathy-mønsteret (mange af dem kørte Dataview og linkede-note-workflows længe før LLM'er), har forsøgt at bygge bro mellem møder og deres vaults med stadig mere forseggjorte hjemmebyggede opsætninger:

• Shadow (shadow.do) — gemmer mødetranskripter som .md-filer i en synkroniseret mappe. Grundlæggende, funktionelt, ingen kompilering.
• Char — et open source-projekt der transskriberer systemlyd plus tastede noter til .md-filer, beregnet til at droppes i en Obsidian-vault.
• tsheil/obsidian_plugin_AI_meeting_notes — et community-plugin der bruger lokal Whisper og Ollama til en fuldt offline pipeline. Virker, men er rettet mod udviklere, der er komfortable med at konfigurere modelservere.
• SystemSculpts workflow, offentliggjort i februar 2026, er en flertrins manuel procedure: optag, transskriber, kør en prompt, indsæt resultatet i Obsidian, link i hånden.

Hver af disse løsninger er fragmenteret. Hver er manuel i ét eller flere trin. Hver er bygget til en, der allerede er komfortabel med lokal inferens, egne scripts eller skrøbelig automatisering. Og hver af dem eksisterer, fordi de kommercielle værktøjer ikke gør det.

Dette er et betydeligt signal. Når de mest teknisk sofistikerede brugere i en kategori bygger deres egne halvløsninger af gaffatape, er efterspørgslen reel, og udbuddet er brudt.

Hvorfor ingen har bygget det

Det er værd at spørge ærligt, hvorfor denne kløft vedbliver. Svaret er ikke, at grundlæggere er dovne, eller at idéen er obskur. Svaret er, at det er genuint svært og genuint ude af mode.

Den tekniske kompleksitet er reel. Læsning er let. Skrivning er svær. En read-only MCP, der returnerer transkriptstykker, er et weekendprojekt. Et system, der tager et møde, opløser entiteter mod en persistent graf, detekterer konflikter med tidligere beslutninger, opdaterer de rigtige wiki-sider, og gør alt dette pålideligt nok til, at brugere stoler på outputtet — det er et måneder-til-år ingeniørproblem. Det kræver skemaer, idempotens, entitetsopløsning, og den slags stille pålidelighed, der ikke demoer godt.

Privatliv er en reel forhindring. At pumpe mødelyd ind i en kontinuerligt LLM-vedligeholdt wiki — en der berører navngivne individer, klientsamtaler og interne beslutninger — rejser reelle GDPR- og datasuverænitetsspørgsmål. Hvem ejer den kompilerede wiki? Hvor bor den? Hvad sker der, når en medarbejder forlader virksomheden og beder om sletning? Disse spørgsmål har svar, men svarene kræver arbejde, og arbejdet skal gøres, før den første kunde onboardes.

VC'er belønner det ikke. Møde-værktøjer værdiansættes på AI-funktioner, der dukker op i et lanceringstweet: et bedre resumé, et hurtigere transkript, en live copilot. Vidensgrafer er en langsom brand. Du kan ikke screenshot en selvvedligeholdende wiki på samme måde, som du kan screenshot et auto-genereret resumé. Kategoriens finansieringsdynamik har stille skubbet grundlæggere mod de demo-venlige funktioner og væk fra de akkumulerende.

Second brain-kirkegården kaster en lang skygge. Evernote. Roam. Skiff. Limitless (tidligere Rewind). Mem. Investorer har set knowledge management-produkter fejle, gentagne gange, i et årti. Alt hvad der lugter af "byg en anden hjerne" udløser mønstermatching mod disse tab. Det faktum, at LLM'er fundamentalt har ændret økonomien i videnskompilering, har endnu ikke helt registreret sig.

De fleste grundlæggere bygger værktøjer, ikke workflows. Det er lettere at bygge en bedre UI end at gentænke, hvordan mødeviden skal flyde ind i resten af en virksomheds informationsarkitektur. Værktøj-vs-workflow-skelnen er forskellen mellem en feature og en produkttese, og kategorien har for det meste valgt features.

Ingen af disse grunde er diskvalificerende. De er blot grundene til, at kløften stadig er en kløft.

Hvad det rigtige produkt ville gøre

Kog spørgsmålet ned til grundprincipperne. Hvis du byggede det produkt, Karpathy beskrev, specifikt til møder, hvad ville det så rent faktisk gøre?

• Fange privat. Bot-fri optagelse, lokalt processerbar hvor muligt, GDPR-tilpasset som default. Du kan ikke bede brugere pumpe følsomme møder ind i en kontinuerligt kompileret wiki, medmindre capture-laget er troværdigt.
• Udtrække entiteter automatisk fra hvert møde. Personer, virksomheder, projekter, beslutninger, forpligtelser, datoer. Ikke som tags på et transkript, men som førsteklasses objekter i en persistent graf.
• Syntetisere på tværs af møder til persistente artefakter. Når du spørger "hvad har klienten sagt om priser over de sidste fem opkald", bør svaret ikke være et chat-svar, der forsvinder. Det bør være en markdown-fil, der eksisterer i morgen og bliver opdateret efter det sjette opkald.
• Skrive tilbage, ikke kun læse. MCP-overfladen bør eksponere opdateringsoperationer: "tilføj til denne beslutningslog", "opret en personpost", "flag denne modsigelse". Read-only er et startpunkt, ikke produktet.
• Definere kompileringsskemaet eksplicit. En CLAUDE.md- eller AGENTS.md-stil-fil, der fortæller LLM'en, hvordan mødeindhold mapper ind i wikien: hvad der tæller som en beslutning, hvordan personer lægges sammen, hvordan en projektside ser ud. Skemaet er produktet lige så meget, som LLM'en er det.
• Bevare raw og wiki separat. Karpathys raw/ vs wiki/-opsplitning anvendt på samtaler: transkripterne er uforanderlige, revisionsbare, sandhedskilde. Wikien ejes af LLM'en, er omskrivelig og altid aktuel. Du kan altid regenerere wikien fra det rå. Du kan aldrig regenerere det rå.

Det er omridset. Det er ikke et mysterium. Det er en specifikation, der kunne skrives ind i en PRD denne uge. Grunden til, at den ikke eksisterer endnu, er listen af forhindringer i forrige afsnit, ikke mangel på klarhed om målet.

Én virksomhed prøver

Proudfrog er det produkt, der mest eksplicit sigter mod denne kløft — privacy-first capture, automatisk entitetsudtrækning, og mødeviden, der er designet til at akkumuleres snarere end at forsvinde. Der er mere at bygge, og den ærlige indramning er, at hele kategorien stadig strækker sig efter Karpathy-niveauet. Men retningen er den, denne tekst har beskrevet.

Vil du have det længere argument for, hvorfor kompileret viden slår flade transkripter i mødeskala, er følgeteksten Karpathys LLM-wiki og hvad det betyder for mødeviden. For den praktiske workflow, se den komplette workflow-guide. For hvordan dette udspiller sig dag-til-dag, er knowledge workers-brugsscenariet den nærmeste beskrivelse. Og vil du se, hvordan landskabet står, lægger sammenligningssiden det ærligt frem.

Kløften er reel. Nogen kommer til at lukke den. Det eneste spørgsmål er hvem og hvornår.

---

Ofte stillede spørgsmål

Hvad er en MCP-server, og hvorfor betyder den noget for møder?

Model Context Protocol (MCP) er en standard, introduceret af Anthropic og hurtigt adopteret på tværs af branchen i 2025, der lader AI-agenter forbinde til eksterne værktøjer og datakilder gennem en konsistent grænseflade. For møder betyder den noget, fordi det er rørene, hvormed en agent — Claude, ChatGPT eller hvad som helst — kan række ind i dit møde-værktøj og forespørge transkripter, resuméer, action items og metadata uden en særskilt integration pr. leverandør. Hvert større møde-værktøj sender nu en MCP-server, hvilket er grunden til, at agenter pludselig kan "se" dine møder. Begrænsningen er, at dagens mødes-MCP'er er read-only: agenter kan forespørge, men intet skriver resultaterne tilbage til en persistent vidensbase.

Hvorfor skriver møde-værktøjerne ikke bare tilbage til min note-app?

Fordi at skrive tilbage er meget sværere end at læse, og meget mindre demo-venligt. En læse-MCP er en tynd indpakning om et søge-API. En skrive-MCP, der vedligeholder en kompileret, selv-konsistent vidensbase, skal udføre entitetsopløsning (er denne "John" den samme John som sidste uge?), konfliktdetektion (modsiger denne beslutning en tidligere?), skemahåndtering (hvordan ser en projektside ud?) og idempotente opdateringer (hvad sker der, hvis det samme møde behandles to gange?). Den skal også være troværdig nok til, at brugere lader den modificere deres noter uden opsyn. De fleste leverandører har valgt at sende den lette halvdel og kalde det en vidensbase.

Hvordan adskiller dette sig fra Otters "knowledge base"-funktion?

Otters positionering er en corporate meeting knowledge base, men det underliggende produkt er stadig fladt søg og opsummering på tværs af transkripter, med en chatbot lagt ovenpå. Der er ingen persistent, kompileret wiki. Der er ingen beslutningslog, der akkumuleres på tværs af møder. Der er ingen entitetsside, der bliver opdateret efter hvert opkald. Markedsføringssproget er rigtigt; ingeniørarbejdet er ikke der endnu. Kløften mellem "søgbart mødearkiv" og "LLM-vedligeholdt vidensbase i Karpathys forstand" er den kløft, denne artikel handler om, og Otter er fast på den søgbare-arkiv-side af det.

Kunne jeg bygge dette selv med Karpathys mønster og et møde-værktøjs API?

Teknisk ja, og nogle i Obsidian-communityet har prøvet. Den sædvanlige opskrift er: brug et møde-værktøjs eksport eller MCP til at hente transkripter, kør dem gennem en lokal eller sky-LLM med en prompt, der udtrækker entiteter og beslutninger, og tilføj resultaterne til markdown-filer i en vault. Dette virker som et weekendprojekt for en enkelt bruger. Det bryder sammen, når du har brug for pålidelighed, entitetsopløsning på tværs af møder, konfliktdetektion, multi-bruger-samarbejde eller privatlivsgarantier. DIY-løsningerne opført i denne artikel — Shadow, Char, community Obsidian-pluginsene, SystemSculpts workflow — er alle forsøg på dette, og alle stopper før det, et rigtigt produkt ville være nødt til at gøre.

Vil GDPR tillade dette i Europa?

Ja, med omhu. GDPR forbyder ikke mødetranskribering eller LLM-kompilerede vidensbaser. Den kræver et lovligt grundlag for behandling, dataminimering, formålsbegrænsning, retten til sletning og opmærksomhed på grænseoverskridende overførsler. Et veludformet kompileret-viden-produkt håndterer disse ved at gøre capture eksplicit og samtykket, holde råtranskripterne separat fra den kompilerede wiki (så sletteanmodninger rent kan fjerne begge), behandle i europæiske regioner hvor muligt, og være transparent om, hvad LLM'en gør med dataen. Forhindringen er ikke reguleringen. Forhindringen er, at at gøre det rigtigt kræver ingeniør- og juridisk arbejde, som de fleste leverandører har udskudt.