Marktmannen wiki Strategie & Organisatie

Multiplayer Claude — De 4 C's (MKT1)

Laatst bijgewerkt

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

C Wat het is Concrete invulling (MKT1's aanbeveling)
Claude Het harnas waar het werk gebeurt De drie Claudes (Chat, Cowork, Code) + een gedeelde GitHub-repo
Context Alles wat het model over jouw wereld weet vóór de opdracht Strategie, salescalls, meetingnotes, launch plans, klantverhalen, messaging- en brandgidsen
Capabilities Wat je één keer bouwt zodat Claude een klus herhaaldelijk kan doen Skills, workflows, herbruikbare prompts, MCP's, subagents
Collaboration Wat losse onderdelen tot een teamsysteem maakt Gedeelde repo als plugin, benoemde eigenaar, skills die het systeem onderhouden

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 te laten draaien.
  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.

Categorie Skill Functie
Primair Build Maakt een nieuwe skill met de juiste structuur
Review Test de skill vóór publicatie door evals te draaien
Publish Bevestigt gereedheid en levert af op de juiste plek (lokaal of teamrepo)
Helper Dupe check Controleert of het al bestaat — lokaal, in de teamrepo of in een MCP
Update Vangt fixes uit een live sessie en vraagt of ze de skill in mogen
Audit Maintain Geplande sweep over eerdere sessies: gemiste fixes en nieuwe skill-kandidaten
Repo stats Leest de git-historie: welke skills worden bijgewerkt en welke verouderen

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

Nomenclatuur en praktische keuzes

  • Harnas — Claude Code en Cowork 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? Nee. Org skill sharing bestaat, maar zonder versiebeheer en alleen de auteur kan bewerken — dichter bij bestanden rondsturen dan bij een draaiend systeem. De echte waarde van die plannen zit 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?
  • Deel 2 en 3 (Buffer, LangChain, MKT1) volgen; de gedetailleerde praktijkvoorbeelden ontbreken nog.

Verwante concepten

Bronnen

#organisatie #skills #context

Backlinks