Vi bygger en MCP-server för mötestranskript. Så här förändrar den LLM-wiki-flödet.

Mönstret som blottar gapet

När Andrej Karpathy publicerade sitt LLM-wiki-arbetsflöde den 2 april 2026 beskrev han en arkitektur med två strikta mappar:

• raw/ — oföränderliga källdokument du kontrollerar
• wiki/ — kompilerad markdown som LLM:en äger

raw/-mappen är där mönstret står eller faller. Det som hamnar där blir substratet för allt LLM:en kompilerar. Artiklar via Obsidian Web Clipper. PDF:er via ett konverteringsskript. Webbsidor via en scraper. Karpathys gist nämner ett par källor explicit — artiklar, papers, webbinnehåll och en som ingen löser rent: mötestranskript.

Under månaderna fram till Karpathys inlägg lanserade varje större mötesverktyg en Model Context Protocol-server (MCP): Otter, Fireflies, Granola, Read.ai, Circleback, tl;dv, Fathom. Läs vår analys av MCP som fundamentet som faktiskt fungerar för varför det spelar roll i stort. Men det specifika problemet med mötes-MCP:er är det här: varenda en är read-only.

Det är gapet. Mötestranskript är något av det mest värdefulla källmaterialet i en organisation, MCP är det standardiserade sättet för AI-agenter att komma åt det materialet, och ändå stannar varje implementation vid "låt agenter fråga tidigare möten". Ingen skriver tillbaka. Ingen behandlar mötestranskriptet som en förstaklassens artefakt du kan mata in i en wiki i Karpathy-stil och ha en riktig kunskapsbas till nästa månad.

Vi bygger den som gör det. Det här inlägget förklarar varför, vad den gör och hur den fungerar.

Read-only MCP-problemet

Låt oss vara specifika om vad som saknas. Tänk dig att du sätter upp en wiki i Karpathy-stil och vill mata in en veckas klientmöten. Med de befintliga mötes-MCP:erna är det här vad en agent kan göra:

Otter MCP (oktober 2025) — list_conversations, get_conversation, search. Du kan hämta ett transkript. Du kan inte få en strukturerad talarlista. Du kan inte extrahera beslut som en queryable resurs. Du kan inte säga till Otter "uppdatera min projektsida efter det här mötet".

Fireflies MCP (community + official) — Samma form. AskFred är ett chattlager ovanpå sökning. MCP:n exponerar möten som platta textblobbar. Syntes över flera möten ligger på dig.

Granola MCP (februari 2026) — Mappbaserad sökning över ditt mötesbibliotek. Du kan söka inom mappar. Du kan inte hämta en ren markdown-export med talar-frontmatter. Möte → wiki kräver ett manuellt omformateringssteg.

Read.ai MCP (beta mars 2026) — Den mest ambitiösa i klassen. Search Copilot sammanför möten, mejl och chattar. Fortfarande read-only. Den beständiga artefakt du kan bygga av datan är "en chatthistorik med agenten", inte "en wiki-sida som ackumuleras över sessioner".

Mönstret är tydligt. Varje MCP byggdes för retrieval — ge en agent en fråga, låt den hämta relevanta snuttar från mötesdatabasen. Ingen byggdes för kompilering — ge en agent ett corpus, låt den skriva en strukturerad kunskapsartefakt och underhålla den över tid.

Det är ingen bugg i protokollet. MCP stöder tools som muterar state. Mötesverktygsleverantörerna har bara inte byggt den sidan. De optimerar för demot där en agent svarar på en fråga om ett tidigare möte. De optimerar inte för flödet där en agent bearbetar 12 möten till 47 wiki-uppdateringar och en flaggad motsägelse.

Vad vi bygger

Proudfrogs MCP-server (för närvarande i beta) exponerar möten som en förstaklassens queryable resurs designad för Karpathy-mönstret. Verktygsytan är opinionated — vi byggde den från ingest-sidan, inte från chatt-sidan.

Tools
├── list_meetings(after, before, participant?, project?)
│   Returns: [{id, title, date, duration, participants}]
│
├── get_meeting(id)
│   Returns: full markdown transcript with frontmatter
│   Format: Karpathy raw/ compatible
│
├── search_meetings(query, limit?, language?)
│   Semantic search across the full library
│
├── list_speakers()
│   Canonical speaker list with merged identities
│
├── get_decisions(meeting_id?, after?, before?)
│   Extracted decisions across one or many meetings
│
└── get_action_items(participant?, status?)
    Open and resolved commitments by person

Resources
├── meetings://raw/{id}.md
│   Markdown transcript, frontmatter-formatted
│   for direct drop into a Karpathy raw/ folder
│
├── meetings://decisions/{date_range}
│   Decision logs as queryable resources
│
└── meetings://entities/{type}
    People, projects, companies as structured data

De två designbeslut som betyder mest:

1. Markdown är det nativa returformatet. När en agent anropar get_meeting får den tillbaka en ren markdown-fil med YAML-frontmatter — exakt den form som passar rakt in i en Karpathy raw/meetings/-mapp. Inget JSON-till-markdown-steg. Ingen omformatering. Ingen informationsförlust mellan mötesverktyget och wiki-ingesten.

2. Strukturerad extraktion sker server-side, inte client-side. Beslut, action items och entiteter extraheras under transkriberingen och exponeras som förstaklassens tools. En agent behöver inte extrahera om dem vid varje query. Mötet "vet" vilka beslut det innehåller. Det är möjligt eftersom Proudfrogs pipeline kör entity extraction som del av transkriberingen, inte som en nedströms chattfunktion.

Kombinationen gör att du kan koppla ihop ett ingest-flöde i ungefär 20 rader agent-prompt:

Every Monday at 9am:
1. Call list_meetings(after=last_monday) on the Proudfrog MCP
2. For each meeting, call get_meeting(id) and write to raw/meetings/
3. Call get_decisions(after=last_monday) and write to raw/decisions.json
4. Run the wiki ingest pass using CLAUDE.md schema rules
5. Run the lint pass to flag contradictions
6. Email me a summary of what changed in the wiki this week

Det är flödet Karpathy beskrev, tillämpat på möten, utan något manuellt exportsteg.

Varför det här betyder mer än bara möten

Det finns en bredare princip i spel. MCP-ekosystemet håller fortfarande på att hitta vad "bra" ser ut som. De flesta servrar under 2025 byggdes som retrieval-gränssnitt — slå in ett befintligt API i MCP, exponera ett search och ett get, skicka ut det. Det är fint för en databas-query. Det är fel för ett kunskapscorpus.

Ett kunskapscorpus behöver MCP-tools som matchar konsumtionsmönstret hos en LLM som gör strukturerad kompilering:

• Bounded enumeration — agenter behöver veta vad som finns (list_* med förutsägbara filter)
• Idempotent retrieval — att anropa samma get_* två gånger ska producera samma artefakt
• Strukturerade extrakt som förstaklassens — beslut, entiteter och relationer ska vara queryable direkt, inte extraheras på nytt från rå text vid varje anrop
• Markdown-nativ output — agenter jobbar i markdown; att slå in JSON i ytterligare ett transformationssteg lägger på latens, kostnad och felyta

Vi tillämpade de här principerna på möten eftersom möten är vad vi kan. Men de generaliserar. Bygger du en MCP-server för ditt eget corpus — din CRM-historik, dina code review-kommentarer, dina supportärenden — gäller samma form. Är din MCP read-only och returnerar JSON, bygger du för fel era.

Up North AI-vinkeln

Vi bygger inte bara Proudfrog. Vi är en nordisk AI-konsultbyrå på Up North AI, och vi hjälper företag navigera skiftet från monolitisk SaaS till agent-orkestrerade system. Läs vårt senaste inlägg om build vs. buy-ekvationen i agent-eran för det bredare resonemanget.

Proudfrog är produkten vi byggde för att vi såg samma gap i uppdrag efter uppdrag: organisationer har flera års ackumulerad möteskunskap, varje anställd känner av frånvaron av den, och varje befintligt verktyg stannar vid "sök i tidigare möten". Vi byggde Proudfrog för att testa hypotesen att en mötesnativ, write-back-kapabel kunskapsgraf är det saknade lagret.

MCP-servern är bryggan mellan Proudfrogs produkt och Karpathy-mönstret som nu tar fart. Är du utvecklare som testar Karpathy-flödet och vill ha dina möten i din wiki, går guiden vi precis publicerade igenom både den manuella exportvägen och MCP-vägen steg för steg.

Är du ett företag som funderar på hur möteskunskap ska flöda in i din AI-stack, hör av dig. Vi har byggt på det här ett tag.

Vad som finns i betan och vad som kommer

Proudfrogs MCP-server i beta stöder för närvarande:

• list_meetings med datum- och deltagarfilter
• get_meeting med markdown-export
• search_meetings med semantisk sökning över hela biblioteket
• list_speakers med kanonisk identitetsupplösning
• OAuth-autentisering för säker agent-access

Vad som kommer härnäst:

• get_decisions och get_action_items som förstaklassens tools (extraheras redan idag men exponeras inte via MCP än)
• Webhooks för wiki-uppdateringar i realtid efter varje möte
• Write-back-tools: update_project_context, add_decision_note
• Multi-tenant-stöd för team-wikis där flera agenter delar åtkomst

Vill du ha tidig tillgång, maila oss eller gå med i Proudfrogs beta-lista. Vill du hellre vänta på den stabila releasen fungerar det manuella exportflödet redan idag med den befintliga Proudfrog-markdown-exporten.

Vad vi hoppas är början på något större

Mötestranskript är den största poolen av ostrukturerad organisatorisk kunskap som finns. De innehåller det faktiska sammanhanget bakom varje beslut, den faktiska formuleringen av varje åtagande, de faktiska personer som sa vad. Och fram till nyligen låg de inlåsta i databaser optimerade för search-and-forget snarare än compile-and-keep.

Karpathys mönster kräver ingen leverantörs tillstånd. Arkitekturen är öppen. Schemafilerna är markdown. Agenterna är utbytbara. Det som har saknats är källmaterial som flödar in rent, med strukturen intakt. Vi försöker fixa det för möten. Vi hoppas andra fixar det för resten av corpuset.

Bygger du MCP-servrar för något högvärdigt källmaterial, skriv till oss. Fältet är vidöppet och mönstren sätts fortfarande.

Vanliga frågor

Vad är fel med de befintliga mötesverktygens MCP:er?

Inget, om du bara vill ha retrieval. Problemet är att retrieval är den mindre halvan av flödet. Karpathys mönster kräver källor som en agent kan mata in i en strukturerad wiki och få den wikin att ackumuleras över tid. Read-only-retrieval tvingar agenten att härleda samma svar från samma råa transkript vid varje fråga. Proudfrogs MCP är byggd kring ingest-till-wiki-flödet.

Varför Markdown i stället för JSON?

LLM:er är markdown-nativa. De skriver markdown som default, de resonerar kring markdown-struktur naturligt, och wiki-mönstret Karpathy beskriver är helt och hållet markdown-baserat. Att tvinga varje transkript genom ett JSON-mellansteg lägger till latens och felyta utan någon nytta. Proudfrogs MCP returnerar markdown direkt så att agenter kan släppa det i en raw/meetings/-mapp utan transformation.

Hur jämför det här med att bygga det själv med Whisper och en databas?

Du kan bygga en mötestranskript-pipeline med open source-Whisper, en databas och en custom MCP-server. Vi gjorde det, två gånger, innan vi byggde Proudfrog. De svåra bitarna är: talaridentifiering över möten (inte inom ett enskilt möte), entity resolution när "Sarah" dyker upp i 14 möten som 6 olika talare, beslutsextraktion som inte hallucinerar, flerspråksstöd för nordiska språk, och GDPR-anpassad dataresidens. Det är 18 månaders arbete styck. Har du obegränsad ingenjörsbudget, bygg det. Annars, använd Proudfrog och fokusera på den del av din stack som faktiskt är unik.

Hur är det med integritet och dataresidens inom EU?

Proudfrog lagrar transkript bara i EU-regioner. MCP-servern respekterar samma dataresidens-gränser — en agent som anropar MCP:n kan inte dra ut data ur EU. Är du ett företag med datasuveränitetskrav är det här ett hårt krav, inte en marknadsföringsfras. Läs vår guide till EU AI Act för SaaS för den bredare compliance-bilden.

Blir MCP-servern open source?

Schemat och tool-definitionerna blir det. Implementationen bygger på Proudfrogs transkriberingspipeline, så hela servern blir inte open source — men vi publicerar MCP-tool-definitionerna så att alla som bygger en liknande server för sitt eget corpus kan matcha konventionerna. Vi tror att mönstren betyder mer än någon enskild implementation.

Hur kommer jag med i betan?

Maila oss eller gå med i Proudfrogs beta-lista. Vi rullar ut access i omgångar under de kommande veckorna.