Jokaisella kokoustyökalulla on nyt MCP-palvelin. Mikään niistä ei kirjoita takaisin. Miksi organisaatiosi arvokkain tieto ei yhä kumuloidu — ja miltä tämä kuilu näyttää.

Huhtikuun 2026 viestissään, jossa kuvataan LLM-ylläpidetty tietopankki, Andrej Karpathy listasi ilmeiset käyttötapaukset. Henkilökohtaiset muistiinpanot. Tutkimus. Koodi. Ja sitten, lähes ohimennen, hän nimesi sen joka olisi pitänyt saada jokainen kokousohjelmiston perustaja istumaan suorana:

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

Kokoustranskriptit. Asiakaspuhelut. Listattu itseään ylläpitävän wiki-mallin ensisijaisena lähdemateriaalina. Ei jälkiajatuksena — nimettynä inputtina, Slackin ja projektidokkujen rinnalla.

Tuosta viestistä on nyt kulunut useita viikkoja. Sinä aikana aalto kokoustyökaluja on julkaissut Model Context Protocol -palvelimia, kerännyt uusia rahoituskierroksia ja uudelleenbrändännyt itsensä "tietopankeiksi". Ja silti, jos luet julkaisutiedot huolellisesti, mikään niistä ei tee sitä mitä Karpathy kuvasi. Ei yksikään. Ala on kytkenyt putket, mutta putket virtaavat vain yhteen suuntaan.

Tämä on kokous-wiki-kuilu. Se on arvokkain rakentamaton tuote kokous-AI-kategoriassa, ja on outoa että se on yhä rakentamaton.

MCP-aalto: Jokainen kokoustyökalu saatiin liitettyä

Loppuvuoden 2025 ja alkuvuoden 2026 välillä jokainen vakavasti otettava kokoustyökalu julkaisi MCP-palvelimen. Ajoitus ei ollut sattumaa — MCP:stä tuli de facto -standardi AI-agenttien yhdistämiseen ulkoiseen dataan, eikä yksikään kokoustarjoaja halunnut olla se, jota agentti ei voinut lukea.

Lista on nyt tarpeeksi pitkä luettavaksi kategorialaskennaksi:

Otter.ai julkaisi virallisen MCP-palvelimen OAuth:lla, tukien sekä Claudea että ChatGPT:tä asiakkaina. Agentit voivat hakea transkripteistä, hakea toimenpiteitä ja kysellä kokousmetadataa.
Fireflies.ai julkaisi virallisen MCP:nsä yhdessä "AskFredin" kanssa — chatbotin joka vastaa kysymyksiin jokaisen kokouksen yli — ja "Knowledge Base"-ominaisuuden joka ehdottaa vastauksia live-puhelujen aikana.
Granola saavutti 1,5 miljardin dollarin arvostuksen maaliskuussa 2026 ja julkaisi virallisen MCP-palvelimensa helmikuussa. Agentit voivat kysellä muistiinpanoja, transkriptejä ja highlightteja käyttäjän Granola-kirjaston yli.
Read.ai esitteli Search Copilotin, yhtenäisen retrieval-kerroksen kokousten, sähköpostien ja chatin yli, MCP:n kautta paljastettuna.
Circleback rakensi yhden MCP-connectorin joka kattaa kokoukset, sähköpostin ja kalenterin, positioiden itsensä rajat ylittäväksi kontekstitarjoajaksi.
tl;dv julkaisi virallisen MCP:n ja rekisteröi sen julkiseen MCP-rekisteriin.
Fathom on saatavilla community-MCP:n kautta Truton connector-kerroksen kautta.

Lue lista toimialan päätöksenä. Kategoria sopi kollektiivisesti muutaman kuukauden sisällä, että AI-agentit tarvitsevat strukturoidun pääsyn kokousdataan. Tämä on todellinen muutos. Kaksi vuotta sitten kokoustyökalut olivat suljettuja siiloja joiden arvolupaus oli kaunis yhteenvetosähköposti. Nyt ne ovat kontekstitarjoajia mille tahansa agentille jota sattumoisin käytät.

Ja silti.

Jokainen niistä on read-only

Tässä havainto joka merkitsee enemmän kuin itse lista: jokainen tähän mennessä julkaistu kokous-MCP-palvelin paljastaa lukuoperaatioita. Hae transkripteistä. Hae yhteenvedot. Kysele toimenpiteitä. Listaa kokoukset. Hae osallistujat. Palauta highlightit.

Yksikään niistä ei kirjoita takaisin.

Yksikään niistä ei ota juuri päättynyttä kokousta ja päivitä projektisivua. Yksikään niistä ei ylläpidä "Henkilö: John Smith" -merkintää joka kerää jokaisen viittauksen Johniin kymmenien puhelujen yli. Yksikään niistä ei pidä päätöslokia joka kattaa kokoukset, merkiten jokaisen merkinnän sillä, kuka sen päätti ja mitä se syrjäytti. Yksikään niistä ei syntetisoi "kaikkea mitä Asiakas Y on sanonut hinnoittelusta viimeisen viiden puhelun yli" pysyväksi artefaktiksi jonka voit avata huomenna. Yksikään niistä ei huomaa, kun tiistain kokous oli ristiriidassa viime kuun päätöksen kanssa ja merkitse ristiriitaa.

Pipeline katkeaa arvokkaimmassa kohdassa. Capture toimii. Transkribointi toimii. Retrieval toimii. Se mikä ei toimi — mitä yksikään tuote ei tällä hetkellä tee automaattisesti — on se osa jonka Karpathy oikeastaan kuvasi: keskustelujen kompilointi tietopankiksi joka kumuloituu.

MCP-aalto yhdisti kokoukset agentteihin. Se ei yhdistänyt kokouksia tietoon.

Granola-rajoitus

Granola on puhtain esimerkki kuilusta, koska se on tuote jonka useimmat nimeäisivät, jos kysyttäisiin mikä kokoustyökalu on paras. 1,5 miljardin dollarin arvostus maaliskuusta 2026. Aidosti erinomainen UX. Rakastettu niiden power userien joukossa, jotka missä tahansa muussa aikakaudessa olisivat rakentaneet tämän itse.

Ja silti eräs Granola-power user kirjoitti hiljattain jotakin, joka tulisi lukea koko kategorian diagnoosina:

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

Istu hetki tuon kanssa. Parhaiten pääomitettu, parhaiten suunniteltu tuote kokous-AI-kategoriassa nappaa kokoukset kauniisti, antaa sinun kysyä kysymyksiä niiden yli, ja heittää sitten vastaukset pois. Päättely jonka LLM juuri suoritti korpuksellasi — synteesi, ristiviittaus, "tässä mitä asiakas on sanonut hinnoittelusta viiden puhelun yli" — elää chat-ikkunassa. Kun chat-ikkuna sulkeutuu, päättely on poissa. Jos haluat säilyttää sen, kopioi ja liitä.

Tämä ei ole Granolan virhe. Se on kategorian virhe. Granola tekee täsmälleen sitä mitä jokainen muu työkalu alalla tekee. Kyselykäyttöliittymää käsitellään tuotteena, ja kyselyjen tuloksena syntyvää tietoa käsitellään väliaikaisena. Ei ole "wikiä" Karpathyn mielessä — ei pysyvää, LLM-ylläpidettyä artefaktia, johon seuraava kysely voi rakentua.

Granola nappaa loistavasti. Se ei kompiloi.

Otterin käännös on todiste siitä että ala tietää

Jos haluat todisteen siitä, että kategoria on tietoinen kuilusta, katso Otteria.

Sam Liang, Otterin toimitusjohtaja, on viimeisen vuoden aikana eksplisiittisesti uudelleenpositioinut Otterin "corporate meeting knowledge baseksi". Ilmaus on nyt keynoteissa, deckeissä, lehdistössä. Se on yrityksen ilmoitettu suunta. Kieli on aivan oikea. Kieli on myös tuotetta edellä.

Otterin todellinen pinta alkuvuodesta 2026 on yhä litteä hakukerros transkriptien yli, parannetulla yhteenvedolla ja chatbotilla päällä. Ei entiteettiresoluutiota kokousten yli. Ei päätöslokia joka kumuloituu. Ei "henkilö"- tai "projekti"- tai "asiakas"-sivua LLM:n ylläpitämänä. Ei ristiriitojen havaitsemista. Ei kompiloitua artefaktia Karpathyn mielessä. Se on parempi arkistokaappi, uudelleenbrändätty tietopankiksi.

Tämä on syytä huomauttaa, ei kritiikkinä vaan todisteena. Kategorian suurin vakiintunut toimija on päättänyt, että "knowledge base" on oikea positioning. He laittavat markkinointilihaksensa sen taakse. Mitä he eivät ole vielä tehneet, on sen rakentaminen. Kuilu positioinnin ja tuotteen välillä on kuilu josta tämä essee puhuu.

Obsidianin tee-se-itse-hautausmaa

Jos työkalut eivät tee sitä, tekevätkö käyttäjät? Kyllä — ja tuskallisesti.

Obsidian-community on ollut tämän kaivoksen kanarialintu vähintään vuoden. Power userit jotka ymmärtävät Karpathyn mallin intuitiivisesti (monet heistä käyttivät Dataview- ja linkitetty-muistiinpano-työnkulkuja jo kauan ennen LLM:iä) ovat yrittäneet sillata kokouksia vaulteihinsa yhä monimutkaisemmilla kotirakennetuilla setupeilla:

Shadow (shadow.do) — tallentaa kokoustranskriptit .md-tiedostoina synkronoituun kansioon. Perustason, toiminnallinen, ei kompilointia.
Char — open source -projekti joka transkriboi järjestelmän ääntä sekä kirjoitetut muistiinpanot .md-tiedostoiksi, tarkoitus pudottaa Obsidian-vaultiin.
tsheil/obsidian_plugin_AI_meeting_notes — community-plugin joka käyttää paikallista Whisperiä ja Ollamaa täysin offline-pipelineen. Toimii, mutta suunnattu kehittäjille jotka ovat mukavasti mallipalvelimien konfiguroinnin kanssa.
SystemSculptin työnkulku, julkaistu helmikuussa 2026, on monivaiheinen manuaalinen menettely: nauhoita, transkriboi, aja prompt, liitä tulos Obsidianiin, linkitä käsin.

Jokainen näistä ratkaisuista on fragmentoitunut. Jokainen on manuaalinen yhdessä tai useammassa vaiheessa. Jokainen on rakennettu jollekin, joka on jo mukavasti paikallisen inferenssin, omien skriptien tai hauraan automaation kanssa. Ja jokainen niistä on olemassa siksi että kaupalliset työkalut eivät tee sitä.

Tämä on merkittävä signaali. Kun kategorian teknisesti hienostuneimmat käyttäjät rakentavat omia puoliratkaisujaan teipistä, kysyntä on todellinen ja tarjonta rikki.

Miksi kukaan ei ole rakentanut sitä

On syytä kysyä rehellisesti miksi tämä kuilu jatkuu. Vastaus ei ole että perustajat ovat laiskoja tai että idea on hämärä. Vastaus on, että se on aidosti vaikeaa ja aidosti epämuodikasta.

Tekninen monimutkaisuus on todellinen. Lukeminen on helppoa. Kirjoittaminen on vaikeaa. Read-only MCP joka palauttaa transkriptipaloja on viikonloppuprojekti. Järjestelmä joka ottaa kokouksen, ratkaisee entiteetit pysyvää grafia vastaan, havaitsee ristiriidat aiempien päätösten kanssa, päivittää oikeat wiki-sivut, ja tekee kaiken tämän tarpeeksi luotettavasti että käyttäjät luottavat tuotokseen — se on kuukausia-vuosia kestävä engineering-ongelma. Se vaatii skeemoja, idempotenssia, entiteettiresoluutiota, ja sen tyyppistä hiljaista luotettavuutta joka ei demoa hyvin.

Yksityisyys on todellinen este. Kokousäänen pumppaaminen jatkuvasti LLM-ylläpidettyyn wikiin — sellaiseen joka koskettaa nimettyjä henkilöitä, asiakaskeskusteluja ja sisäisiä päätöksiä — nostaa todellisia GDPR- ja datasuvereniteettikysymyksiä. Kuka omistaa kompiloidun wikin? Missä se elää? Mitä tapahtuu kun työntekijä lähtee ja pyytää poistoa? Näille kysymyksille on vastauksia, mutta vastaukset vaativat työtä, ja työ on tehtävä ennen ensimmäisen asiakkaan perehdyttämistä.

VC:t eivät palkitse sitä. Kokoustyökaluja arvostetaan AI-ominaisuuksilla jotka näkyvät julkaisutwiitissä: parempi yhteenveto, nopeampi transkripti, live-copilot. Tietografit ovat hidas poltto. Et voi kuvakaappaa itseään ylläpitävää wikiä samalla tavalla kuin voit kuvakaappaa automaattisesti generoidun yhteenvedon. Kategorian rahoitusdynamiikka on hiljaa työntänyt perustajia demoystävällisten ominaisuuksien suuntaan ja pois yhdistelmällisistä.

Second brain -hautausmaa heittää pitkän varjon. Evernote. Roam. Skiff. Limitless (ent. Rewind). Mem. Sijoittajat ovat katselleet knowledge-management-tuotteiden epäonnistumista, toistuvasti, vuosikymmenen ajan. Kaikki mikä haisee "rakenna toinen aivo" -ideologialta laukaisee hahmontunnistuksen näitä tappioita vastaan. Sitä tosiseikkaa, että LLM:t ovat perustavanlaatuisesti muuttaneet tiedonkompiloinnin taloutta, ei ole vielä täysin rekisteröity.

Useimmat perustajat rakentavat työkaluja, eivät työnkulkuja. On helpompi rakentaa parempi UI kuin miettiä uudestaan, miten kokoustieto tulisi virrata yrityksen muuhun informaatioarkkitehtuuriin. Työkalu-vs-työnkulku-erottelu on ero ominaisuuden ja tuoteteesin välillä, ja kategoria on pääosin valinnut ominaisuudet.

Mikään näistä syistä ei ole diskvalifioiva. Ne ovat vain syyt miksi kuilu on yhä kuilu.

Mitä oikean tuotteen tulisi tehdä

Pudota kysymys ensimmäisiin periaatteisiin. Jos rakentaisit tuotetta jonka Karpathy kuvasi, nimenomaan kokouksille, mitä se oikeasti tekisi?

Napata yksityisesti. Bot-vapaa nauhoitus, paikallisesti käsiteltävä mahdollisuuksien mukaan, GDPR-linjassa oletuksena. Et voi pyytää käyttäjiä pumppaamaan arkaluonteisia kokouksia jatkuvasti kompiloituun wikiin ellei capture-kerros ole luotettava.
Poimia entiteetit automaattisesti jokaisesta kokouksesta. Ihmiset, yritykset, projektit, päätökset, sitoumukset, päivämäärät. Ei tageina transkriptissa, vaan ensimmäisen luokan objekteina pysyvässä grafissa.
Syntetisoida kokousten yli pysyviksi artefakteiksi. Kun kysyt "mitä asiakas on sanonut hinnoittelusta viimeisen viiden puhelun yli", vastauksen ei pitäisi olla chat-vastaus joka katoaa. Sen pitäisi olla markdown-tiedosto joka on olemassa huomenna ja päivittyy kuudennen puhelun jälkeen.
Kirjoittaa takaisin, ei vain lukea. MCP-pinnan pitäisi paljastaa päivitysoperaatioita: "lisää tähän päätöslokiin", "luo henkilömerkintä", "merkitse tämä ristiriita". Read-only on lähtökohta, ei tuote.
Määritellä kompilointiskeema eksplisiittisesti. CLAUDE.md- tai AGENTS.md-tyylinen tiedosto joka kertoo LLM:lle miten kokoussisältö kartoittuu wikiin: mikä lasketaan päätökseksi, miten henkilöt yhdistetään, miltä projektisivu näyttää. Skeema on tuote yhtä paljon kuin LLM.
Säilyttää raw ja wiki erikseen. Karpathyn raw/ vs wiki/ -jako sovellettuna keskusteluihin: transkriptit ovat muuttumattomia, auditoitavia, totuudenlähteitä. Wiki on LLM:n omistama, uudelleenkirjoitettava ja aina ajan tasalla. Voit aina regeneroida wikin raakalähteistä. Et koskaan voi regeneroida raakaa.

Tässä on ääriviivat. Se ei ole mysteeri. Se on spesifikaatio joka voitaisiin kirjoittaa PRD:hen tällä viikolla. Syy miksi sitä ei vielä ole, on edellisen osion esteiden lista, ei selkeyden puute tavoitteesta.

Yksi yritys yrittää

Proudfrog on tuote joka eksplisiittisimmin tähtää tähän kuiluun — yksityisyys-ensin-capture, automaattinen entiteettien poiminta ja kokoustieto joka on suunniteltu kumuloitumaan eikä katoamaan. On vielä rakentamista, ja rehellinen kehystys on, että koko kategoria yhä kurottaa Karpathyn rimaa kohti. Mutta suunta on se jota tämä teksti on kuvannut.

Jos haluat pidemmän argumentin siitä miksi kompiloitu tieto voittaa litteät transkriptit kokousmittakaavassa, kumppaniteksti on Karpathyn LLM-wiki ja mitä se merkitsee kokoustiedolle. Käytännön työnkululle, ks. täydellinen työnkulkuopas. Sille miten tämä näkyy päivittäin, knowledge workers -käyttötapaus on lähin kuvaus. Ja jos haluat nähdä miten maisema asettuu, vertailusivu esittää sen rehellisesti.

Kuilu on todellinen. Joku tulee sulkemaan sen. Ainoa kysymys on kuka ja milloin.

Usein kysytyt kysymykset

Mikä MCP-palvelin on ja miksi sillä on merkitystä kokouksille?

Model Context Protocol (MCP) on standardi, jonka Anthropic esitteli ja joka omaksuttiin nopeasti koko alalla 2025:n aikana, joka antaa AI-agenttien yhdistyä ulkoisiin työkaluihin ja datalähteisiin johdonmukaisen rajapinnan kautta. Kokouksille sillä on merkitystä, koska se on putkityö jolla agentti — Claude, ChatGPT tai mikä tahansa muu — voi ulottua kokoustyökaluusi ja kysellä transkriptejä, yhteenvetoja, toimenpiteitä ja metadataa ilman erillistä integraatiota per toimittaja. Jokainen merkittävä kokoustyökalu julkaisee nyt MCP-palvelimen, mikä on syy siihen miksi agentit voivat yhtäkkiä "nähdä" kokouksesi. Rajoitus on, että tämän päivän kokous-MCP:t ovat read-only: agentit voivat kysellä, mutta mikään ei kirjoita tuloksia takaisin pysyvään tietopankkiin.

Miksi kokoustyökalut eivät vain kirjoita takaisin muistiinpanosovellukseeni?

Koska takaisin kirjoittaminen on paljon vaikeampaa kuin lukeminen, ja paljon vähemmän demoystävällistä. Luku-MCP on ohut kääre hakuAPI:n ympärille. Kirjoitus-MCP joka ylläpitää kompiloitua, itse-johdonmukaista tietopankkia, täytyy tehdä entiteettiresoluutio (onko tämä "John" sama John kuin viime viikolla?), ristiriitojen havaitseminen (onko tämä päätös ristiriidassa aikaisemman kanssa?), skeemahallinta (miltä projektisivu näyttää?) ja idempotentit päivitykset (mitä tapahtuu jos sama kokous käsitellään kahdesti?). Sen täytyy myös olla luotettava tarpeeksi, että käyttäjät antavat sen muokata muistiinpanojaan ilman valvontaa. Useimmat toimittajat ovat valinneet julkaista helpon puolikkaan ja kutsua sitä tietopankiksi.

Miten tämä eroaa Otterin "knowledge base" -ominaisuudesta?

Otterin positioning on corporate meeting knowledge base, mutta alla oleva tuote on yhä litteä haku ja yhteenveto transkriptien yli, chatbotilla päällä. Ei ole pysyvää, kompiloitua wikiä. Ei ole päätöslokia joka kumuloituu kokousten yli. Ei ole entiteettisivua joka päivittyy jokaisen puhelun jälkeen. Markkinointikieli on oikea; insinöörityö ei vielä ole siellä. Kuilu välillä "haettava kokousarkisto" ja "LLM-ylläpidetty tietopankki Karpathyn mielessä" on se kuilu josta tämä artikkeli puhuu, ja Otter on tiukasti haettava-arkisto-puolella sitä.

Voisinko rakentaa tämän itse Karpathyn mallilla ja kokoustyökalun API:lla?

Teknisesti kyllä, ja jotkut Obsidian-communityssa ovat yrittäneet. Tavallinen resepti on: käytä kokoustyökalun vientiä tai MCP:tä transkriptien hakemiseen, aja ne paikallisen tai pilven LLM:n läpi promptilla joka poimii entiteetit ja päätökset, ja lisää tulokset markdown-tiedostoihin vaultissa. Tämä toimii viikonloppuprojektina yhdelle käyttäjälle. Se hajoaa kun tarvitset luotettavuutta, entiteettiresoluutiota kokousten yli, ristiriitojen havaitsemista, monen käyttäjän yhteistyötä tai yksityisyystakuita. Tässä artikkelissa listatut DIY-ratkaisut — Shadow, Char, community Obsidian-pluginit, SystemSculptin työnkulku — ovat kaikki yrityksiä tässä, ja kaikki pysähtyvät ennen kuin oikean tuotteen pitäisi tehdä.

Salliiko GDPR tämän Euroopassa?

Kyllä, huolella. GDPR ei kiellä kokoustranskribointia tai LLM-kompiloituja tietopankkeja. Se vaatii lainmukaisen perustan käsittelylle, datan minimointia, käyttötarkoituksen rajoitusta, oikeutta tulla unohdetuksi ja huomion kiinnittämistä rajat ylittäviin siirtoihin. Hyvin suunniteltu kompiloidun-tiedon tuote käsittelee nämä tekemällä kaappauksen eksplisiittiseksi ja suostumusperustaiseksi, pitämällä raakatranskriptit erillään kompiloidusta wikistä (jotta poistopyynnöt voivat puhtaasti poistaa molemmat), käsittelemällä eurooppalaisilla alueilla missä mahdollista, ja olemalla läpinäkyvä siitä mitä LLM tekee datalle. Este ei ole regulaatio. Este on se, että oikein tekeminen vaatii engineering- ja oikeustyötä jonka useimmat toimittajat ovat lykänneet.

Kokous-wiki-kuilu: Miksi keskustelusi eivät vielä virtaa tietopankkiisi