Multiplayer Claude — De 4 C's (MKT1)

Laatst bijgewerkt 12 oktober 2026

TL;DR: De volgende productiviteitssprong komt niet van een beter persoonlijk systeem maar van een gedeeld teamsysteem — en de C die vrijwel elk team mist is niet Claude, Context of Capabilities, maar Collaboration.

Emily Kramer (MKT1) interviewde marketingleiders over teambrede Claude-systemen en concludeert dat het knelpunt zelden technisch is. Het knelpunt is dat teamgenoten niet gebruiken wat anderen bouwden, dat niemand eigenaar is, en dat het systeem verouderd raakt. Ze noemt dit "multiplayer Claude": een systeem waarin iedereen met actuele gedeelde context en capabilities werkt, zodat elke verbetering van één persoon direct bij iedereen landt.

Wat multiplayer Claude niet is

• Alleen een Team-abonnement afsluiten
• Documenten in een gedeelde drive of project dumpen
• Iedereen eigen skills laten bouwen die nooit hun laptop verlaten
• Eén AI-enthousiasteling die tools maakt die niemand adopteert

De 4 C's

Noot (12-10-2026): de indeling in drie Claudes gold bij publicatie. Sinds 16-09-2026 worden Chat en Cowork gefaseerd samengevoegd tot één Claude (Pro/Max eerst; release notes Anthropic); Claude Code blijft apart. Nieuwe Cowork-taken en scheduled tasks draaien op Pro/Max in de cloud, ook als de computer slaapt; projecten op een lokale map werken alleen via de geopende desktop-app.

Capability- vs. contextlaag (term van Simon Heaton, Buffer): de capability-laag is het uitvoerende — skills, workflows, referentiebestanden, de dingen die het werk dóén. De contextlaag is de kennisbank. Een skill kan feitelijk in beide zitten; de indeling is een denkhulp, geen dogma.

Hoe het voelt als de 4 C's samenkomen

• Eén levende bron van waarheid, geen twaalf kopieën. Iemand werkt de canonieke ICP-definitie bij, iedereen heeft hem meteen.
• Eén fix, iedereen profiteert. Je repareert een skill en pusht naar de teamrepo; de volgende run is bij iedereen goed, ook bij wie het probleem nooit opmerkte.
• Correcties sterven niet in een chatsessie. "Stop met em-dashes" hoort in de gedeelde voice-skill, niet in een gesprek dat eindigt.
• Skills reizen tussen subfuncties. Growth gebruikt de contentskills, ops gebruikt de productmarketingskills — iedereen wordt meer full-stack.

Collaboration: waarom bijna niemand deze C rond heeft

1. Teams zijn niet georganiseerd genoeg om het systeem te bouwen — zonder gecodificeerde ICP's geen werkend AI-systeem.
2. De teamleider is niet de AI-superuser. De bouwer is niet de beslisser (zelfde patroon als "champion ≠ decision maker" in sales).
3. Werk is weer lokaal. Na 15 jaar cloud moet je laptop openstaan om Claude Code lokaal te laten draaien; cloudtaken zoals routines draaien wel door.
4. Geen tijd — er zijn pipelinetargets. Het systeem bouwen is precies wat je efficiënter maakt en precies waar nooit tijd voor is.
5. Wachten op het bedrijfsniveau. Teams willen het antwoord erven in plaats van het zelf te bouwen.

Delen is niet hetzelfde als samenwerken. Een prompt in Slack posten of een skillmap rondsturen is stap één, maar niemand kan het terugvinden, niemand weet of het te vertrouwen is en niemand is eigenaar als het stukgaat. Devon Watts (Mercury): een gedeelde skillbibliotheek zonder consistente manier van maken en testen leidt tot lage adoptie — mensen bouwen dan liever hun eigen ding.

Kramer waarschuwt dat de bouwfase eruitziet als achteruitgang: het opruim-moment waarop alles uit de kast op de grond ligt. Dat is normaal; het alternatief is nooit beginnen.

Skills die skills maken — de kern van zelf-onderhoud

Het onderdeel dat vrijwel iedereen overslaat: naast skills die het werk doen, heb je skills nodig die je andere skills bouwen en onderhouden.

De Update-skill en de Maintain-sweep zijn conceptueel identiek aan de eigen leg-vast- en health-check-taken in het Marktmannen-OS. De Repo stats-skill (git-historie als staleness-signaal) is nieuw materiaal.

Eval (definitie uit het artikel): een skill testen door voorbeelden erdoorheen te halen en de output te vergelijken met een afgerond voorbeeld van die klus. Slava Baranskyi: "No skill ships without an eval list, five or six expected outputs written down before anyone runs it."

Praktijkvoorbeelden: Buffer, LangChain, Mintlify (deel 2)

Deel 2 van de MKT1-reeks (02-09-2026) zet de 4 C's naast drie echte teams. Alle drie hebben een eigen eigenaarsmodel, maar volgen wel hetzelfde patroon: context eerst op orde, dan pas capabilities.

Wat overal terugkomt: - Context vóór capabilities. Mintlify's les: teams die skills bouwen zonder eerst de contextlaag op orde te hebben, zien lage adoptie en slechte output — niet omdat de skill slecht is, maar omdat de context waar hij op draait wankel is. - Onderhoud is een aparte capability-categorie. Alle drie hebben iets dat het systeem zelf actueel houdt: bij Buffer een maandelijkse context-refresh-workflow, bij LangChain een "LangSmith Engine" die faalpatronen clustert en fixes voorstelt, bij Mintlify een mens (Ethan) wiens hele baan dat is. - Eigenaarschap kan gecentraliseerd óf gedecentraliseerd zijn, als het maar helder is. Buffer is beide tegelijk (lokaal bouwen, centraal shippen); LangChain is volledig gecentraliseerd (4-persoonsteam bouwt voor iedereen); bij Mintlify ligt contexteigenaarschap bij één rol en de rest van het systeem bij marketing zelf. - Danny Lambert's 4 toetsen voor een agent: gebruiksgemak, modelagnostisch, traceerbaar (te begrijpen en te repareren), zelfverbeterend. - Agent-vs-skill-onderscheid scherper dan in deel 1: een skill is een recept, een agent (zoals LangChain's SDR-agent) draait autonoom in de cloud, is zichtbaar wie hem gebruikt, en kan volgens deel 2 getriggerd worden via Slack, webhook of schema. Dat "een skill kan dat niet" is te stellig: een routine die een skill aanroept, start via een schema, een API-aanroep of een GitHub-event (geen Slack) — en MKT1 doet in deel 3 zelf precies dat.

MKT1 zelf als praktijkvoorbeeld (deel 3)

Deel 3 (17-09-2026, slot van de reeks) legt MKT1's eigen setup open: drie generalisten ("Gen Marketers", 1 fulltime + 2 halftime) die maandelijks 2 nieuwsbrieven, 20+ posts, 5+ video's, ~200 gevalideerde vacatures en 10+ MCP-skills shippen. De aanleiding voor de opschoning was tweeledig: teamleden op vakantie en een nieuwe laptop maakten zichtbaar dat te veel lokaal en per persoon was gebouwd.

Twee toetsen als noordster

MKT1 scoort zichzelf na de zomer een A- op de eerste en een B+ op de tweede. Praktische toepassing: neem de drie AI-workflows waar je team het meest op leunt en vraag per workflow of hij nog draait als de bouwer weg is of zijn laptop dicht zit.

Claude — waar het draait

• Bouwen uitsluitend in Claude Code; dagelijks gebruik is per persoon een andere mix van Chat, Cowork en Code (Chat en Cowork worden gefaseerd samengevoegd, zie noot bij de 4 C's).
• Ieder een eigen Max-account, geen Team-account — meer usage en persoonlijke projecten blijven gescheiden. Bevestigt de conclusie uit deel 1.
• Twee gedeelde GitHub-repo's, beide als plugin geïnstalleerd op alle drie de machines: één voor interne workflows ("Team-Dino"), één voor abonnee-tools inclusief de MKT1 MCP. Wie pusht, zet het bij de anderen in hun volgende sessie klaar. Daarnaast heeft iedereen een persoonlijke repo — daarmee slaag je voor de New Computer Test.
• Repo's krijgen namen die je niet dagelijks uitspreekt, zodat Claude nooit twijfelt wat je bedoelt.
• 30+ routines, zo veel mogelijk als cloud-routine (draaien ook bij gesloten laptop; volgens MKT1 ook te starten vanaf een telefoon).
• Veel MCP's (Airtable, Attio, Substack, Slack, Asana, Granola, Plain, Drive, Clay, Figma, Zapier, …) — naar eigen zeggen te veel.

Context — instructies in skills, feiten erbuiten

MKT1 begon met alle context ín skills en met volledige data-pulls via MCP bij elke run. Dat brak op vier punten: Claude negeert of misleest datapunten in een lange skill, context veroudert en zit dan verstopt op een plek die niet iedereen bijwerkt, alles ophalen bij elke run vreet usage-limiet, en de skill-eigenaar is vaak niet de context-eigenaar.

De huidige regel: skills documenteren instructies; context leeft in de tools waar het team al werkt en wordt via MCP alleen gelezen als een skill hem nodig heeft, per afgebakende dataset.

Geen enkele bron van waarheid, maar een sources-of-truth-skill die per dataset zegt waar hij leeft en wat de fallback is, zodat andere skills niet gokken.

Capabilities — 100+ skills, waarvan een deel het systeem zelf onderhoudt

Werk-skills lopen langs de productielijnen: nieuwsbrief (/newsletter-copy leest de /voice-guide, /newsletter-pre-send checkt links/sponsorcopy/SEO, /newsletter-after-publish indexeert, wisselt de homepagebanner, informeert sponsors en zet promo-onderwerpen op de LinkedIn-roadmap), video (Riverside → Descript-clips → YouTube als unlisted, mens zet public), web/design (Framer-CLI met alleen bestaande componenten, Figma-checks, beeldcompressie), research (/general-research met de regel "leeg laten in plaats van gokken, elke batch steekproeven" en een /company-taxonomy zodat elke research-skill bedrijven op dezelfde manier indeelt) en rapportage (alle eigen cijfers in één Airtable-base met Slack-samenvatting).

Schrijven blijft mensenwerk. "If writing is the main way your team uses AI, I think you're doing it wrong. AI is best at automating mundane and repetitive work. It's not good at craft." Kramer ziet AI vooral als copy-editor en workflow-automatiseerder.

Voorbeeld van een keten die zichzelf draait — de vacaturebank: wekelijkse scrape van careers-pagina's uit een Airtable-lijst → sortering Approved / Not Approved / Flagged met Slack-ping voor wat menselijk oordeel vraagt → elke twee dagen een link-check die gesloten vacatures verwijdert → ingezonden vacatures via formulier elke paar uur gevalideerd → drie ochtenden per week een LinkedIn-concept in Slack. Het patroon (inzending landt → routine controleert → flagt wat hij niet kan parsen) is herbruikbaar voor elk formulier.

Onderhoudsskills, uitgewerkt ten opzichte van de tabel hierboven:

Plugins uit een eigen repo verversen zichzelf niet. Claude houdt een lokale kopie van elke plugin. Auto-update staat aan voor officiële en via claude.ai toegevoegde marketplaces, uit voor overige — dus ook voor een eigen GitHub-repo zoals die van MKT1. MKT1 draait daarom bij alle drie een dagelijkse refresh-routine en de publish-skill ververst de plugin van de bouwer direct. /reload-plugins past alleen een al bijgewerkte schijfkopie toe in de lopende sessie; de nieuwe versie ophalen gaat via /plugin of claude plugin update. Dit was mede de reden om voor de abonnees een MCP te bouwen in plaats van een plugin.

Routines — instructies in een skill, niet in de routine

• Een routine die zijn instructies zelf bevat faalt de vakantietest: hij draait in één account en niemand anders kan hem draaien of nabouwen. Zet de instructies in een gedeelde skill in de repo en laat de routine die skill aanroepen.
• Lokaal vs. cloud: lokale routines kunnen bij lokale bestanden en tools, maar alleen als de laptop wakker is; cloud-routines draaien op Anthropics servers maar zien alleen repo en connectors. Lokale routines falen dus beide toetsen. Tip: vraag Claude welke lokale routines naar cloud kunnen en splits een routine in een cloud- en een lokaal deel als één stap lokale bestanden nodig heeft.
• Voorbeelden: /daily-connection-status (checkt of e-mail/Asana/Zapier/Slack nog verbonden zijn, of de skills up-to-date zijn en of back-ups lopen — meldt alleen bij een breuk), /kramer-to-dos (leest Slack, Granola, e-mail en supporttickets en zet wat aandacht vraagt op de Asana-lijst), /calendar-sync (houdt Google Calendar, Asana-roadmap en sponsorgrid op dezelfde datums).

Collaboration — één eigenaar, iedereen bouwt

• Kramer is eigenaar van het systeem (dichtst bij Buffer's model); iedereen bouwt en verbetert.
• Eén roadmap in Asana met per Claude-onderdeel een eigenaar en collaborators; skills-in-aanbouw op een gedeelde to-do-lijst in de repo, een wekelijkse routine zegt wat als volgende te bouwen is.
• Verbeter skills tijdens het werk en push direct — geen groot opruimproject achteraf.
• Wat het team verlaat, test iemand die het niet bouwde. De publish-skill vraagt zelf of er een review-taak in Asana moet komen en voor wie.
• Claude post in Slack in een vast format: nieuwe skills, proceswijzigingen, wat routines gedaan hebben (calendar-sync-changelog, scrape-rapport, open tickets). Niemand hoeft andere tools te openen voor de meeste updates.
• Publiek schrijven over het eigen systeem dwingt tot evalueren en op één lijn komen.

Moet je een MCP publiceren?

Een gedeelde repo + plugin komt ver, maar een intern MCP wint als: je geen last wilt van verouderende plugins, skills bronnen moeten lezen die niet iedereen zelf gekoppeld heeft (CRM), niet het hele team in Claude Code zit (bijv. deels Codex), of je gebruiksanalytics wilt. Een publiek MCP is een "sidecar-product" voor je publiek (MKT1 noemt als voorbeeld Ramp Data MCP met benchmarks los van het eigen account), of verrijkt het product-MCP dat engineering al shipt met docs, templates en frameworks.

Volgens MKT1 is hun MCP gebouwd in Claude Code, GitHub en Cloudflare (altijd-aan, redeployt bij elke push); toegang per e-mailadres gecheckt tegen de Airtable-abonneebase, elk uur gesynchroniseerd met Substack-betalingen; ingebouwde helpdocs, changelog en help-skill die Claude concipieerde; supporttickets in Plain met een Cloudflare-"persoonskaart" (betaald/gratis, laatste verbinding, wat stuk is) en een Claude-agent die binnen minuten labelt en prioriteert; dagelijkse statistieken (actieve gebruikers, installs, tool-calls, top-skills) naar Slack. Publicatieregel: zodra een skill werkt voor iemand die hem niet bouwde, kun je hem delen — met een collega, abonnee of partner.

Nomenclatuur en praktische keuzes

• Harnas — Claude Code en Cowork (wordt gefaseerd samengevoegd met Chat tot één Claude-app) zijn harnassen: hetzelfde model, verpakt met toegang tot je bestanden, tools en context.
• Agent — een AI-"programma" dat autonoom naar een vooraf bepaald doel toewerkt. Doorslaggevend is autonomie. Een skill is géén agent (een skill is een recept, een agent is een kok); een geplande skill ook niet — plannen verandert wanneer iets draait, niet hoe het werkt. Voor een echte gedeployde agent bouw je in een platform als LangChain, met Claude als motor.
• Waar bouw je skills? In Claude Code, niet in Cowork. Cowork draait een afgeronde skill prima, maar bouwen en testen vraagt bestanden bewerken en mappen doorzoeken.
• Waar leeft context? Git of Obsidian werken beter met Claude dan Google Docs. Een gedeelde cloudmap met markdown geeft Claude geen zicht op de relaties tussen documenten en geen versiebeheer (David Johnson-Igra, Scribes).
• Team/Enterprise-plan nodig? Volgens MKT1 nee. Org skill sharing bestaat: delen met personen of groepen (groepen alleen op Enterprise), nadat de owner delen heeft aangezet. Dat het zonder versiebeheer werkt en alleen de auteur kan bewerken, is Kramers eigen inschatting ("my understanding") — volgens haar dichter bij bestanden rondsturen dan bij een draaiend systeem. De echte waarde van die plannen zit volgens haar in billing, admin en compliance.

Verhouding tot bestaande artikelen

• Dit is niet het Vier C's-framework uit Agentic OS (Context + Connections = second brain, Capabilities + Cadence = AIOS). MKT1's 4 C's zijn Claude, Context, Capabilities, Collaboration — en de nadruk ligt op de sociale laag, niet op de architectuur.
• Team Agentic OS beschrijft de technische kant van hetzelfde probleem (3-tier Notion/Claude Code/GitHub, toegangsbeheer, blast radius). Dit artikel vult de adoptie- en onderhoudskant in die daar ontbreekt.

Zelftest: heb je een echt multiplayer-systeem?

Vijf ja's = in goede vorm:

1. Hebben we gedeelde context?
2. Hebben we herbruikbare capabilities, zoals skills?
3. Zijn MCP's aangesloten, en gebruiken we hun data ook ín onze skills?
4. Bouwt en gebruikt meer dan de helft van het team skills in Claude Code of Cowork?
5. Bereiken individuele AI-inspanningen het hele team?

Open vragen

• Waar zit de grens voor een eenmansbedrijf met klanten (Marktmannen-model)? Is "multiplayer" daar per klant-OS, of over klanten heen?
• Repo stats als staleness-signaal: is git-historie ook bruikbaar voor de wiki-health-check (welke artikelen worden nooit bijgewerkt)?
• Het artikel adviseert een benoemde systeemeigenaar — hoe werkt dat bij klant-OS'en waar de champion parttime is?
• LangChain's model (volledig gedeployde cloud-agents i.p.v. lokale skills) past niet op een eenmansbureau als Marktmannen — is Buffer's gedecentraliseerd-bouwen/gecentraliseerd-shippen-model het bruikbaarste tussenpunt voor een klant-OS met meerdere gebruikers?
• Slaagt het Marktmannen-OS en slaagt een klant-OS voor de Vacation Test en de New Computer Test? Welke routines bevatten nu hun eigen instructies in plaats van een skill aan te roepen?
• MKT1 koos een MCP boven een plugin om stale plugins te vermijden en gebruik te kunnen meten. Is dat voor de klant-OS-starterkit (meerdere klanten, versies, updates) ook de betere distributievorm, of blijft repo-als-plugin voldoende zolang er een refresh-routine draait?

Eigen toepassing (29-07-2026): dit framework is tegen het Marktmannen-OS gelegd; die analyse is werkdocumentatie en staat daarom niet in de wiki maar in mm/projecten/marktmannen-os/Analyse-Multiplayer-Claude-vs-Marktmannen-OS.md. Daar zijn de eerste drie open vragen hierboven beantwoord.

Verwante concepten

• Team Agentic OS — de technische architectuur onder ditzelfde probleem
• Agentic OS — de persoonlijke variant, en het andere Vier C's-framework
• Skill Systems — orchestratie van meerdere skills
• Skills en Plugins — distributie via plugins
• Executive AI-implementatie (Every Consulting) — champions-model voor invoering
• Agentic Marketing Organisatie — agentic principes specifiek in marketing
• Claude Code Routines — lokaal vs. cloud draaien; MKT1's regel "instructies in een skill, de routine roept die aan" is de multiplayer-variant hiervan
• Skills Verbeteren — Vier Praktijken — MKT1's /skill-update (correctie uit een sessie → duurzame instructie in de skill) is de teamversie van praktijk 3
• Zelfverbeterende Kennisbank — MKT1's scheiding "instructies in skills, feiten in tools" is dezelfde scheiding als schema (CLAUDE.md) versus inhoud (wiki)

Bronnen

• Marketing teams are stuck in single-player Claude mode. Here's how to go multiplayer. — Emily Kramer, 27-07-2026
• Inside the multiplayer AI setups at Mintlify, LangChain, and Buffer — Emily Kramer, 02-09-2026
• Inside team MKT1's multiplayer AI setup — Emily Kramer, 17-09-2026
• Claude Help Center — Chat en Cowork samengevoegd tot één Claude — Anthropic, 12-10-2026
• Claude Help Center — Release notes (One Claude, 16-09-2026) — Anthropic, 12-10-2026
• Claude Code docs — Discover plugins — Anthropic, 12-10-2026
• Claude Code docs — Routines — Anthropic, 12-10-2026
• Claude Help Center — Skills delen — Anthropic, 12-10-2026