Møte-til-wiki-gapet: Hvorfor samtalene dine ennå ikke flyter inn i kunnskapsbasen din

I innlegget sitt fra april 2026 som beskrev en LLM-vedlikeholdt kunnskapsbase, listet Andrej Karpathy opp de åpenbare bruksområdene. Personlige notater. Forskning. Kode. Og så, nesten i forbifarten, navnga han det som burde ha fått hver eneste gründer av møteprogramvare til å sette seg opp:

"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øtetranskripsjoner. Kundesamtaler. Listet som primær kildemateriale for det selvvedlikeholdende wiki-mønsteret. Ikke som en ettertanke — som et navngitt input, ved siden av Slack og prosjektdokumenter.

Det har nå gått flere uker siden det innlegget. I løpet av den tiden har en bølge av møteverktøy lansert Model Context Protocol-servere, hentet nye runder og reposisjonert seg som "kunnskapsbaser". Og likevel, hvis du leser release notes nøye, gjør ingen av dem det Karpathy beskrev. Ikke én. Bransjen har koblet rørene, men rørene flyter bare én vei.

Dette er møte-til-wiki-gapet. Det er det mest verdifulle ubygde produktet i møte-AI-kategorien, og det er rart at det fortsatt er ubygd.

MCP-bølgen: Hvert møteverktøy ble koblet opp

Mellom slutten av 2025 og starten av 2026 skipet hvert seriøse møteverktøy en MCP-server. Tidspunktet var ikke tilfeldig — MCP ble de facto-standarden for å koble AI-agenter til ekstern data, og ingen møteleverandør ville være den som en agent ikke kunne lese.

Listen er nå lang nok til å leses som en kategoriinventering:

• Otter.ai skipet en offisiell MCP-server med OAuth, som støtter både Claude og ChatGPT som klienter. Agenter kan søke i transkripsjoner, hente action items og spørre mot møtemetadata.
• Fireflies.ai slapp sin offisielle MCP sammen med "AskFred" — en chatbot som svarer på spørsmål på tvers av hvert møte — og en "Knowledge Base"-funksjon som foreslår svar under live-samtaler.
• Granola traff en verdsettelse på 1,5 milliarder dollar i mars 2026 og lanserte sin offisielle MCP-server i februar. Agenter kan spørre mot notater, transkripsjoner og highlights på tvers av en brukers Granola-bibliotek.
• Read.ai introduserte Search Copilot, et enhetlig retrieval-lag på tvers av møter, e-post og chat, eksponert via MCP.
• Circleback bygde en enkelt MCP-connector som spenner over møter, e-post og kalender, og posisjonerte seg som en tverrflate-kontekstleverandør.
• tl;dv skipet en offisiell MCP og registrerte den i det offentlige MCP-registeret.
• Fathom er tilgjengelig via en community-MCP gjennom Trutos connector-lag.

Les listen som en bransjebeslutning. Kategorien ble kollektivt enige, innen noen måneder, om at AI-agenter trenger strukturert tilgang til møtedata. Det er et reelt skifte. For to år siden var møteverktøy lukkede siloer hvis verdi-proposisjon var en pen oppsummerings-e-post. Nå er de kontekstleverandører for hvilken agent du enn bruker.

Og likevel.

Hver eneste er read-only

Her er observasjonen som betyr mer enn selve listen: hver møte-MCP-server skipet så langt eksponerer lese-operasjoner. Søk i transkripsjoner. Hent sammendrag. Spør mot action items. List møter. Hent deltakere. Returner highlights.

Ingen av dem skriver tilbake.

Ingen av dem tar et møte som nettopp endte og oppdaterer en prosjektside. Ingen av dem vedlikeholder en "Person: John Smith"-oppføring som akkumulerer hver referanse til John over dusinvis av samtaler. Ingen av dem holder en beslutningslogg som spenner over møter og tagger hver oppføring med hvem som besluttet den og hva den erstattet. Ingen av dem syntetiserer "alt Kunde Y har sagt om priser over de siste fem samtalene" til en persistent artefakt du kan åpne i morgen. Ingen av dem merker når tirsdagens møte motsa en beslutning fra forrige måned og flagger motsigelsen.

Pipelinen brytes ved det mest verdifulle steget. Capture fungerer. Transkripsjon fungerer. Retrieval fungerer. Det som ikke fungerer — det ingen produkt for øyeblikket gjør automatisk — er delen Karpathy faktisk beskrev: å kompilere samtaler til en kunnskapsbase som akkumuleres.

MCP-bølgen koblet møter til agenter. Den koblet ikke møter til kunnskap.

Granola-begrensningen

Granola er den reneste illustrasjonen av gapet, fordi det er produktet de fleste ville navngi hvis spurt hvilket møteverktøy som er best. 1,5 milliarder dollar i verdsettelse per mars 2026. Genuint utmerket UX. Elsket av den typen power users som, i hvilken som helst annen æra, ville bygd dette selv.

Og likevel skrev en Granola-power user nylig noe som bør leses som en diagnose av 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."

Sitt med det et øyeblikk. Det best-kapitaliserte, best-designede produktet i møte-AI-kategorien fanger møter vakkert, lar deg stille spørsmål på tvers av dem, og forkaster så svarene. Resonnementet LLM-en nettopp utførte over korpuset ditt — syntesen, kryssrefereringen, "her er hva klienten har sagt om priser over fem samtaler" — lever i et chatvindu. Når chatvinduet lukkes, er resonnementet borte. Vil du beholde det, copy-paste.

Dette er ikke en Granola-feil. Det er en kategorifeil. Granola gjør nøyaktig det alle andre verktøy i området gjør. Spørregrensesnittet behandles som produktet, og kunnskapen som oppstår fra å spørre behandles som flyktig. Det finnes ingen "wiki" i Karpathy-forstand — ingen persistent, LLM-vedlikeholdt artefakt som neste spørsmål kan bygge videre på.

Granola fanger briljant. Den kompilerer ikke.

Otters pivot er bevis på at bransjen vet

Vil du ha bevis på at kategorien er klar over gapet, se på Otter.

Sam Liang, Otters CEO, har det siste året eksplisitt reposisjonert Otter som en "corporate meeting knowledge base". Frasen er nå i keynotes, deckene, pressen. Det er selskapets uttalte retning. Språket er eksakt riktig. Språket er også foran produktet.

Otters faktiske overflate, per tidlig 2026, er fortsatt et flatt søkelag over transkripsjoner med forbedret oppsummering og en chatbot på toppen. Ingen entitetsresolusjon på tvers av møter. Ingen beslutningslogg som akkumuleres. Ingen "person"- eller "prosjekt"- eller "kunde"-side vedlikeholdt av LLM-en. Ingen motsigelsesdeteksjon. Ingen kompilert artefakt i Karpathy-forstand. Det er et bedre arkivskap, reposisjonert som en kunnskapsbase.

Dette er verdt å påpeke, ikke som kritikk, men som bevis. Den største incumbenten i kategorien har bestemt at "knowledge base" er riktig posisjonering. De legger markedsføringsmuskler bak det. Det de ennå ikke har gjort, er å bygge det. Gapet mellom posisjoneringen og produktet er gapet denne teksten handler om.

Obsidian-DIY-gravlunden

Hvis verktøyene ikke gjør det, gjør brukerne det? Ja — og smertefullt.

Obsidian-communityet har vært kanarifuglen i denne gruven i minst et år. Power users som forstår Karpathy-mønsteret intuitivt (mange av dem kjørte Dataview og lenkede-notater-arbeidsflyter lenge før LLM-er) har prøvd å bygge bro mellom møter og vaultene sine med stadig mer forseggjorte hjemmebygde oppsett:

• Shadow (shadow.do) — lagrer møtetranskripsjoner som .md-filer i en synkronisert mappe. Grunnleggende, funksjonelt, ingen kompilering.
• Char — et open source-prosjekt som transkriberer systemlyd pluss typede notater til .md-filer, ment å droppes inn i et Obsidian-vault.
• tsheil/obsidian_plugin_AI_meeting_notes — et community-plugin som bruker lokal Whisper og Ollama for en fullstendig offline pipeline. Fungerer, men er rettet mot utviklere som er komfortable med å konfigurere modellservere.
• SystemSculpts arbeidsflyt, publisert i februar 2026, er en flertrinns manuell prosedyre: spille inn, transkribere, kjøre en prompt, lime resultatet inn i Obsidian, lenke for hånd.

Hver av disse løsningene er fragmentert. Hver er manuell i ett eller flere steg. Hver er bygget for noen som allerede er komfortabel med lokal inferens, egne skript eller skjør automatisering. Og hver av dem eksisterer fordi de kommersielle verktøyene ikke gjør det.

Dette er et betydelig signal. Når de mest teknisk sofistikerte brukerne i en kategori bygger sine egne halvløsninger av gaffateip, er etterspørselen reell og tilbudet ødelagt.

Hvorfor ingen har bygd det

Det er verdt å spørre ærlig hvorfor dette gapet vedvarer. Svaret er ikke at gründere er late eller at ideen er obskur. Svaret er at det er genuint vanskelig og genuint ute av mote.

Den tekniske kompleksiteten er reell. Å lese er enkelt. Å skrive er vanskelig. En read-only MCP som returnerer transkripsjonsbiter er et helgeprosjekt. Et system som tar et møte, løser entiteter mot en persistent graf, oppdager konflikter med tidligere beslutninger, oppdaterer de riktige wiki-sidene, og gjør alt dette pålitelig nok til at brukere stoler på utdataen — det er et måneder-til-år-ingeniørproblem. Det krever skjemaer, idempotens, entitetsresolusjon, og den typen stille pålitelighet som ikke demoer godt.

Personvern er et reelt hinder. Å pumpe møtelyd inn i en kontinuerlig LLM-vedlikeholdt wiki — en som berører navngitte individer, klientsamtaler og interne beslutninger — reiser reelle GDPR- og datasuverenitetsspørsmål. Hvem eier den kompilerte wikien? Hvor bor den? Hva skjer når en ansatt slutter og ber om sletting? Disse spørsmålene har svar, men svarene krever arbeid, og arbeidet må gjøres før den første kunden onboardes.

VC-er belønner det ikke. Møteverktøy verdsettes på AI-funksjoner som dukker opp i en lanseringstweet: et bedre sammendrag, et raskere transkript, en live copilot. Kunnskapsgrafer er en langsom brann. Du kan ikke skjermdumpe en selvvedlikeholdende wiki på samme måte som du kan skjermdumpe et autogenerert sammendrag. Kategoriens finansieringsdynamikk har stille dyttet gründere mot de demovennlige funksjonene og bort fra de kumulative.

Second brain-gravlunden kaster en lang skygge. Evernote. Roam. Skiff. Limitless (tidligere Rewind). Mem. Investorer har sett knowledge-management-produkter feile, gjentatte ganger, i et tiår. Alt som lukter "bygg en andre hjerne" utløser mønstermatching mot disse tapene. Det faktum at LLM-er fundamentalt har endret økonomien i kunnskapskompilering, har ennå ikke fullt ut registrert seg.

De fleste gründere bygger verktøy, ikke arbeidsflyter. Det er lettere å bygge et bedre UI enn å tenke nytt om hvordan møtekunnskap skal flyte inn i resten av et selskaps informasjonsarkitektur. Verktøy-vs-arbeidsflyt-skillet er forskjellen mellom en feature og en produkttese, og kategorien har stort sett valgt features.

Ingen av disse grunnene er diskvalifiserende. De er bare grunnene til at gapet fortsatt er et gap.

Hva det riktige produktet ville gjort

Kok spørsmålet ned til grunnprinsippene. Hvis du bygde produktet Karpathy beskrev, spesifikt for møter, hva ville det faktisk gjort?

• Fange privat. Bot-fri opptak, lokalt prosesserbart der det er mulig, GDPR-justert som default. Du kan ikke be brukere pumpe sensitive møter inn i en kontinuerlig kompilert wiki med mindre capture-laget er tillitvekkende.
• Trekke ut entiteter automatisk fra hvert møte. Personer, selskaper, prosjekter, beslutninger, forpliktelser, datoer. Ikke som tagger på et transkript, men som førsteklasses objekter i en persistent graf.
• Syntetisere på tvers av møter til persistente artefakter. Når du spør "hva har klienten sagt om priser over de siste fem samtalene", skal svaret ikke være et chat-svar som forsvinner. Det skal være en markdown-fil som finnes i morgen og blir oppdatert etter det sjette samtalet.
• Skrive tilbake, ikke bare lese. MCP-overflaten skal eksponere oppdateringsoperasjoner: "legg til i denne beslutningsloggen", "opprett en personoppføring", "flagg denne motsigelsen". Read-only er et utgangspunkt, ikke produktet.
• Definere kompileringsskjemaet eksplisitt. En CLAUDE.md- eller AGENTS.md-lignende fil som forteller LLM-en hvordan møteinnhold mapper inn i wikien: hva som teller som en beslutning, hvordan personer slås sammen, hvordan en prosjektside ser ut. Skjemaet er produktet like mye som LLM-en er det.
• Bevare raw og wiki separat. Karpathys raw/ vs wiki/-split anvendt på samtaler: transkripsjonene er uforanderlige, reviderbare, sannhetskilde. Wikien eies av LLM-en, kan skrives om, og er alltid aktuell. Du kan alltid regenerere wikien fra det rå. Du kan aldri regenerere det rå.

Det er omrisset. Det er ingen mysterium. Det er en spesifikasjon som kunne skrives inn i en PRD denne uken. Grunnen til at den ikke eksisterer ennå, er listen over hindringer i forrige avsnitt, ikke mangel på klarhet om målet.

Ett selskap prøver

Proudfrog er produktet som mest eksplisitt sikter mot dette gapet — privacy-first capture, automatisk entitetsuttrekking, og møtekunnskap som er designet for å akkumuleres heller enn å forsvinne. Det er mer å bygge, og den ærlige innrammingen er at hele kategorien fortsatt strekker seg etter Karpathy-nivået. Men retningen er den denne teksten har beskrevet.

Vil du ha det lengre argumentet for hvorfor kompilert kunnskap slår flate transkripsjoner i møteskala, er følgeteksten Karpathys LLM-wiki og hva det betyr for møtekunnskap. For den praktiske arbeidsflyten, se den komplette arbeidsflyt-guiden. For hvordan dette spiller ut dag-for-dag er knowledge workers-bruksområdet den nærmeste beskrivelsen. Og vil du se hvordan landskapet står seg, legger sammenligningssiden det ut ærlig.

Gapet er reelt. Noen kommer til å lukke det. Det eneste spørsmålet er hvem og når.

---

Ofte stilte spørsmål

Hva er en MCP-server, og hvorfor betyr den noe for møter?

Model Context Protocol (MCP) er en standard, introdusert av Anthropic og raskt adoptert på tvers av bransjen i 2025, som lar AI-agenter koble til eksterne verktøy og datakilder gjennom et konsistent grensesnitt. For møter betyr den noe fordi det er rørleggingen som en agent — Claude, ChatGPT, eller hva enn — kan strekke inn i møteverktøyet ditt og spørre mot transkripsjoner, sammendrag, action items og metadata uten en egen integrasjon per leverandør. Hvert større møteverktøy skiper nå en MCP-server, som er grunnen til at agenter plutselig kan "se" møtene dine. Begrensningen er at dagens møte-MCP-er er read-only: agenter kan spørre, men ingenting skriver resultatene tilbake til en persistent kunnskapsbase.

Hvorfor skriver ikke møteverktøyene bare tilbake til notat-appen min?

Fordi å skrive tilbake er mye vanskeligere enn å lese, og mye mindre demovennlig. En lese-MCP er et tynt omslag rundt et søke-API. En skrive-MCP som vedlikeholder en kompilert, selv-konsistent kunnskapsbase må gjøre entitetsresolusjon (er denne "John" samme John som forrige uke?), konfliktdeteksjon (motsier denne beslutningen en tidligere?), skjema-håndtering (hvordan ser en prosjektside ut?) og idempotente oppdateringer (hva skjer hvis samme møte prosesseres to ganger?). Den må også være pålitelig nok til at brukere lar den modifisere notatene sine uten tilsyn. De fleste leverandører har valgt å skipe den enkle halvparten og kalle det en kunnskapsbase.

Hvordan skiller dette seg fra Otters "knowledge base"-funksjon?

Otters posisjonering er en corporate meeting knowledge base, men det underliggende produktet er fortsatt flatt søk og oppsummering på tvers av transkripsjoner, med en chatbot lagt på toppen. Det finnes ingen persistent, kompilert wiki. Det finnes ingen beslutningslogg som akkumuleres på tvers av møter. Det finnes ingen entitetsside som blir oppdatert etter hvert samtale. Markedsføringsspråket er riktig; ingeniørarbeidet er ikke der ennå. Gapet mellom "søkbart møtearkiv" og "LLM-vedlikeholdt kunnskapsbase i Karpathys forstand" er gapet denne artikkelen handler om, og Otter er fast på den søkbare-arkiv-siden av det.

Kunne jeg bygd dette selv med Karpathys mønster og et møteverktøys API?

Teknisk ja, og noen i Obsidian-communityet har prøvd. Den vanlige oppskriften er: bruk et møteverktøys eksport eller MCP til å hente transkripsjoner, kjør dem gjennom en lokal eller sky-LLM med en prompt som trekker ut entiteter og beslutninger, og legg resultatene til markdown-filer i et vault. Dette fungerer som et helgeprosjekt for en enkelt bruker. Det bryter sammen når du trenger pålitelighet, entitetsresolusjon på tvers av møter, konfliktdeteksjon, flerbruker-samarbeid eller personverngarantier. DIY-løsningene listet i denne artikkelen — Shadow, Char, community Obsidian-pluginsene, SystemSculpts arbeidsflyt — er alle forsøk på dette, og alle stopper før det en ekte produkt ville måtte gjøre.

Vil GDPR tillate dette i Europa?

Ja, med omhu. GDPR forbyr ikke møtetranskripsjon eller LLM-kompilerte kunnskapsbaser. Den krever et lovlig grunnlag for behandling, dataminimering, formålsbegrensning, retten til sletting, og oppmerksomhet rundt grensekryssende overføringer. Et velutformet kompilert-kunnskapsprodukt håndterer dette ved å gjøre fangst eksplisitt og samtykket, holde råtranskripsjonene separat fra den kompilerte wikien (slik at sletteforespørsler kan rent fjerne begge), prosessere i europeiske regioner der mulig, og være transparent om hva LLM-en gjør med dataen. Hindringen er ikke reguleringen. Hindringen er at å gjøre det riktig krever ingeniør- og juridisk arbeid som de fleste leverandører har utsatt.