Team Agentic OS

Laatst bijgewerkt: 29-06-2026

TL;DR: Een Agentic OS voor teams vereist een 3-tier architectuur (Notion/Drive → Claude Code → GitHub) waarbij toegang wordt gedeeld waar het moet en privé blijft waar het moet — met als kern: niks is vendor-locked, alles zijn markdown-bestanden en mappen.

Een persoonlijk Agentic OS bouwen is relatief eenvoudig. Voor een team komen drie extra uitdagingen bij: 1. Geheugendeling zonder alles te ontsluiten — klant A mag klant B's context niet zien 2. Teamleden die het systeem verbeteren zonder de technische details te hoeven raken 3. Portabiliteit — niet gebonden aan één tool of interface

De 3-tier architectuur

Waarom Notion/Drive? Niet-technische teamleden kunnen markdown-bestanden in Notion editen in een nette interface — zonder foutgevoelige code aan te raken.

Waarom GitHub? Notionrechten werken niet in GitHub; aparte repos per klant met exact dezelfde teamleden als in Notion voorkomt lekken.

Wat wordt gedeeld, wat blijft privé

Globaal (gedeeld met heel team)
├── CLAUDE.md / soul.md / brand context
└── Klantmappen (toegang afhankelijk van Notion-rechten)

Per gebruiker (privé)
├── .claude.local.md (machine-specifieke overrides)
└── Eigen private GitHub-repo (git-ignored lokale aanpassingen)

Alles in blauw = door Notion beheerd als markdown-bestanden. Alles in paars = door Claude Code of GitHub beheerd (agent-bestanden, skills).

Toegangscontrole over 4 systemen

1. Gedeelde drive — team-eigenaar beheert wie welke documenten kan zien/bewerken; per Notion-space
2. Lokale machine — token van Notion/Drive bepaalt welke bestanden naar Claude Code worden gesynchroniseerd; wat je niet mag zien, komt niet aan
3. GitHub — één repo per klant; Notion-rechten ≠ GitHub-rechten; GitHub-lidmaatschap moet Notion-lidmaatschap spiegelen
4. Geheugendatabase (optioneel) — als je semantisch lange-termijngeheugen hebt (vector database): - Optie A: separate geheugenindex per persoon (makkelijker, geen gedeeld geheugen) - Optie B: gedeelde PostgreSQL op Supabase met row-level security per klant (schaalbaarder, moeilijker op te zetten)

Erfelijkheidsmodel (inheritance)

• Globale regels uit de root CLAUDE.md worden geërfd door alle workstations en klantmappen
• Workstation-specifieke regels voegen toe, overschrijven niet de globale regels
• Klantmappen krijgen eigen brand context (voice profile, ICP) — dit wordt niet geërfd van boven
• Lokale .claude.local.md overrides zijn alleen op de eigen machine zichtbaar

Portabiliteit

Onderin is alles markdown en mappen — geen vendor lock-in. Je kunt het systeem overzetten naar Claude Code, Codex, of welk toekomstig platform dan ook zonder de architectuur opnieuw te bouwen.

De drie hersenen (three-brain model)

Een team dat Claude Code draait heeft drie "hersenen" die elk ergens anders leven, hun eigen git-status hebben en in een vaste volgorde van precedentie worden geladen:

Precedentie: Managed → CLI flags → .claude/settings.local.json (persoonlijk-in-repo) → .claude/settings.json (team-in-repo) → ~/.claude/settings.json (globaal). Deny-regels winnen altijd; allow-regels worden samengevoegd over scopes heen.

Het persoonlijke brein gaat nooit de teamrepo in (eigen klantenlijst, schrijfstijl, privé-API-keys). Het gedeelde teambrein bevat wat iedereen moet weten (PR-template, deploy-checklist, afgesproken databasekeuzes) en volgt dezelfde git-regels als de rest van de codebase. Het org-managed brein is beleid ("nooit destructieve commands", "MCP-allowlist is X/Y/Z") en heeft de hoogste prioriteit.

Dit drie-hersenen-model is een aanvulling op de 3-tier architectuur hierboven: tier 1 (Notion/Drive) komt overeen met het org-managed + gedeelde brein voor niet-technische content, tier 2/3 (Claude Code/GitHub) is waar het gedeelde en persoonlijke teambrein als code leeft.

De blast radius-vraag

Voor elke nieuwe MCP-server, elke skill die een schrijf-tool aanroept, en elke hook: "Als Claude de slechtst mogelijke prompt-injectie krijgt, wat gebeurt er dan?" Dat is de blast radius. Het doel is niet nul blast radius, maar een blast radius die begrensd wordt door iets anders dan "Claude merkte het op".

Kernregel: wat een agent kán doen (OAuth-scopes, MCP read/write, tool-permissies) bepaalt de blast radius — niet hoe de instructies of skills zijn georganiseerd.

Branch protection & CODEOWNERS

Het belangrijkste dat een team kan doen: maak het onmogelijk dat een agent (of mens) zonder review naar main pusht. Gebruik GitHub Rulesets (niet de legacy classic branch protection) met: verplichte PR + reviewer, require_code_owner_review, signed commits, en status-checks zoals een ai-safety-workflow.

.github/CODEOWNERS routeert AI-bewerkte paden naar een mens:

*                  @owner @cto-handle
/CLAUDE.md         @owner
/.claude/          @owner
/memory/           @owner
**/.mcp.json       @cto-handle

Branchpatroon voor 2-30 personen: main (beschermd, PR + review + CODEOWNERS + signed commits + groene CI), feature/<slug> (vrij, gesquasht in main), experiment/<naam> (wegwerp, na 7 dagen automatisch verwijderd).

Claude Code vs. Cowork: welk pad?

Het playbook onderscheidt drie team-paden: Cowork-only (niet-technische teams: marketing, sales, legal, finance — web/desktop Claude.ai met Projects + Connectors), Claude Code-only (engineering-teams, repo-first) en Mixed (devs op Claude Code, de rest op Cowork — het dominante patroon voor teams van 2-30 in 2026).

Belangrijkste asymmetrie: Cowork is uitgesloten van Anthropic's Audit Logs, Compliance API, Data Exports en BAA (mei 2026), zelfs op Enterprise. Voor regulated industries hoort gevoelig werk in Claude Code, niet Cowork.

Lethal trifecta (Simon Willison): een Cowork-sessie wordt exfiltratie-gevoelig zodra alle drie tegelijk aanwezig zijn: 1. Privédata — een Project met interne Notion-koppeling + klantgesprektranscripten 2. Onbetrouwbare content — websearch-resultaten, een gedropte PDF, gescrapete Slack-berichten 3. Externe communicatie — Slack-write, Gmail-send, Files API-uploads zonder approval

Verdediging: knip minstens één poot van de trifecta per Project — bijvoorbeeld nooit websearch én een schrijf-Connector tegelijk aanzetten.

Single-team-brain probleem (mixed teams): er bestaat geen native sync tussen Cowork Project Knowledge en Claude Code's memory/-map (Anthropic heeft dit "not planned" verklaard). Oplossing: maak één bron canoniek (bijv. Notion), laat beide tools daaruit lezen via hun integraties, houd de skill-vault in git, en doe een wekelijkse drift-check.

Realistische 15-persoonsstack: 5 Premium-zetels ($100, devs + power users) + 10 Standard-zetels ($25, rest) ≈ $875/maand jaarlijks. Start iedereen op Standard, upgrade naar Premium pas bij 10+ uur/week in Claude Code.

Open vragen

• Hoe automatiseer je synchronisatie van Notion → lokale machine → GitHub?
• Hoe schaal je de PostgreSQL-geheugenoplossing als het team groeit naar >20 mensen?
• Hoe los je de ontbrekende native sync tussen Cowork Project Knowledge en Claude Code's memory/-map structureel op?

Verwante concepten

• Agentic OS — de persoonlijke variant; Team OS bouwt hierop voort
• Geheugen en Context — de geheugenlagen in detail
• Claude Code Routines — automatisering van team-workflows
• Agentic Marketing Organisatie — teamtoepassing van agentic principes in marketing

Bronnen

• Claude Code for Teams · The Ultimate 2026 Playbook — David Arnoux, 18-05-2026
• How to Build an Agentic OS Your Whole Team Can Actually Use — Simon Scrapes, 02-06-2026