Het agentmodel

Wat is een agent?

Een agent is een benoemde actor met een persona, een set skills en een adapter om op te draaien. Agenten zijn principalen in dezelfde zin als mensen: ze schrijven berichten, bezitten tickets, laten reviews achter en staan op dezelfde ledenlijst. Zij zijn degenen die het werk doen.

Elke agent hoort bij precies één werkruimte. Dat is een harde invariant — agent.workspaceId is niet null, de eigen werkruimte van de agent bepaalt in welk databasebestand zijn rijen terechtkomen, en het aanmaken van een agent zonder werkruimte wordt geweigerd.

Een agent is ook een map. Zijn definitie staat in agents/<slug>/AGENTS.md onder de gegevensmap van de werkruimte, met de skills die hij heeft gesymlinkt naar agents/<slug>/.agents/skills. De databaserij en het bestand worden samen geschreven. Seeden is idempotent: als de agentrij al bestaat, worden de bestanden op schijf en de skill-links alsnog opnieuw geschreven. De aanroeper in productie is het aanmaken van de werkruimte, niet elke serverstart.

Wat een agent meebrengt

Attribuut	Wat het doet
`name`	Korte, slug-achtige id (`architect`, `qa`). Ook waarop `@mentions` worden opgelost
`title`	Voor mensen leesbare functietitel
`persona`	Vrije tekst met persoonlijkheid en gedragsinstructies, als promptgedeelte ingevoegd
`systemPrompt`	Optionele extra instructies, ingevoegd als een “Agent instructions”-gedeelte — ze vervangen de rest van de samengestelde prompt niet
`skills`	Set skillnamen zonder onderscheid tussen hoofd- en kleine letters, op schijf gespiegeld als skill-links
`adapterId`	Naar welke runner de agent zijn runs stuurt. Null valt terug op de ingebouwde loop
`modelId`	Welk model binnen die adapter
`effort`	Redeneerniveau, uit het eigen vocabulaire van het geselecteerde model
`contextSize`	Overschrijving van het contextvenster
`silenceTimeoutMinutes`	Overschrijving per agent (1–240) voor de stiltewatchdog
`reportsTo`	Id van de bovenliggende agent — de rapportagelijn die het organigram tekent

Je bewerkt dit allemaal via Instellingen → Werkruimte → Agenten. Nieuwe agent maakt een naamloze agent aan die je daarna invult.

Skills

Skills zijn namen op de agent-entiteit, zonder onderscheid tussen hoofd- en kleine letters. Er gebeuren twee losse dingen mee:

De namen staan in de samengestelde prompt onder een “Skills”-kopje. Dat is alles wat de set van de entiteit op zichzelf doet — er hangt geen promptbibliotheek per skill aan vast.
De map van elke genoemde skill (skills/<slug>/SKILL.md in de werkruimte) wordt in de eigen map van de agent gelinkt. Op de ingebouwde harness wordt de frontmatter van de gelinkte skills automatisch in de systeemprompt geladen en leest de agent een body op aanvraag; als je /skill:<name> in een gesprek typt, wordt die body als richtlijn voor de beurt geladen.

Skills die van buiten worden opgehaald, doorlopen tussen ophalen en schrijven een scan van de toeleveringsketen die bij twijfel weigert — geen enkele skillinhoud bereikt de schijf of een prompt zonder een oordeel. Dat “buiten” zijn GitHub-repositories die je zelf als skillbronnen registreert: er is geen gecureerde catalogus, dus de eigen metadata van de repository (de beschrijving, de sterren, de naam van de skill) zijn onvertrouwde weergavegegevens en het oordeel van de scan is het enige veiligheidssignaal. Een installatie haalt de hele map van de skill op, pint die in skills-lock.json vast aan de commit waar hij vandaan kwam, en een latere update passeert de poort opnieuw voordat er iets wordt vervangen. De instructies staan in Skills installeren en beheren.

Repo-gebonden skills

Een repo kan zijn eigen skills meeleveren, op elk van de gebruikelijke plekken (.agents/skills/, .claude/skills/, .opencode/skills/). Een ruimte checkt elke gekoppelde repo naast elkaar uit onder repos/<name>/, maar een agent werkt per keer in één repo — dus hij heeft alleen de skills van die repo bij zich, en die wisselen wanneer hij verhuist.

Welke repo actief is, wordt afgeleid uit de bestanden die de agent aanraakt: een bestand schrijven onder repos/<name>/ maakt die repo actief, terwijl alleen maar lezen over repo’s heen dat niet doet. Een symbool achternagaan tot in een zusterservice haalt de set dus nooit onder een taak vandaan. In een ruimte met één repo is het antwoord al bekend vóór de eerste beurt.

Die beperking is een beslissing over het contextbudget. De skillindex staat bij elke beurt in de prompt, de bodies niet, dus het in één keer opsommen van de skills van elke repo kost doorlopend tokens — en een testing-skill uit de ene service misleidt actief wanneer het werk in een andere ligt. Dezelfde redenering verklaart waarom de index van een agent één repo meedraagt, maar de composer niet zo is beperkt: een skill zelf benoemen is één expliciete handeling, dus /skill:<repo>:<name> bereikt elke repo in de ruimte.

Reposkills worden voor elke adapter geladen, niet alleen voor de ingebouwde harness. De skills van de actieve repo worden gematerialiseerd in de werkmap van de agent, het pad dat Claude Code al scant; dezelfde index wordt samengesteld in de AGENTS.md die de ingebouwde harness leest. De skills van een repo doorlopen, voordat dit alles gebeurt, dezelfde scan die bij twijfel weigert als een geïnstalleerde skill — een uitgecheckte repo is gekloonde inhoud, en zijn frontmatter bereikt een prompt.

Machtigingen

Een agent draagt geen eigen machtigingsvlaggen. Of hij een commit mag maken, mag pushen, een pull request mag openen, naar een tracker mag schrijven of het netwerk mag bereiken, beslissen de actiebeveiligingen — toestaan, eerst vragen of weigeren, op het bereik werkruimte, agent of ruimte — en dezelfde regels gelden welke adapter hem ook draait.

Wat een run aangereikt krijgt, verandert niet met die regels. Een run in een GitHub-worktree krijgt altijd een GitHub-token met alleen leesrechten, en een push wordt gevraagd op het moment dat hij gebeurt: de git-configuratie van de agent stuurt elke GitHub-push via Control Center, dat de regel Naar een remote pushen toepast voordat het hem doorstuurt.

Zie Sandbox en beveiliging voor hoe dat werkt, waaronder wat er op bestandssysteemniveau wel en niet wordt afgedwongen.

De adapter bepaalt wat er kan worden afgedwongen

Het veld met de grootste gevolgen op een agent is zijn adapter, want het transport van de adapter bepaalt hoeveel van het beleid van Control Center daadwerkelijk kan worden afgedwongen.

Transport	Adapters	Wat Control Center afdwingt
Ingebouwde harness	Control Center (built-in)	Alles. Het tooloppervlak wordt gebouwd vanuit de modus, dus een niet-toegestane tool is onzichtbaar in plaats van alleen maar geweigerd; elke call passeert de goedkeuringspoort en de actiebeveiligingen; het voltooiingscontract kan een zetje geven en daarna een run laten mislukken die eindigt zonder zijn oplevering
Claude CLI	Claude Code	De `mcp__*`-tools die het worden aangeboden, plus zijn `Bash`-opdrachten, die een hook vóór uitvoering naar het actiebeleid stuurt. Claudes eigen lees-, schrijf- en bewerktools leven in zijn proces en draaien ongezien — en hij wordt gestart met `--dangerously-skip-permissions`, omdat een niet-interactieve `claude -p` anders voor altijd zou blijven hangen op zijn eigen prompt

Concreet: alleen de ingebouwde harness ondersteunt subagents, bijsturing midden in een run, pauzeren en hervatten (en dus overname) en structurele afdwinging van de modus. Claude Code krijgt niets daarvan.

De matrix hierboven gaat over wat Control Center kan zien en bij de poort kan controleren. Daaronder wikkelt cc_server de Claude Code-CLI in de OS-sandbox van de host waar die bestaat — Seatbelt op macOS, bubblewrap op Linux en WSL2 — dus een ongeziene rm of een ongeziene schrijfactie wordt alsnog door het OS begrensd. Op Windows is er helemaal geen backend en op Linux of WSL2 zonder bwrap en socat meldt de probe er geen, dus daar vallen die runs terug op opschoning van de omgeving, via de broker verstrekte inloggegevens, de beveiligingen op de calls die Control Center kan zien en de eigen worktree van het gesprek (copy-on-write waar rift wordt meegeleverd; git worktree op Windows).

Wat de sandbox niet is, is een poort. Hij begrenst waar een proces mag lezen, schrijven en verbinden — een alleen-lezenmodus bereikt hem wel, in de vorm van alleen-lezen bind mounts — maar hij kan geen call onderscheppen, niet om goedkeuring vragen en je achteraf niet vertellen wat de CLI heeft geprobeerd. Dat, plus de vier mogelijkheden die net hierboven zijn genoemd, is nog steeds wat de ingebouwde harness heeft en de andere niet. Zie Sandbox en beveiliging.

Een agent zonder adapter valt terug op Control Center (built-in) — de loop in de server, dus er is geen CLI te installeren — en zijn runlog registreert cc-harness. Elke geseede agent wordt aangemaakt zonder adapter of model, dus de vijf agenten van een verse werkruimte draaien daar allemaal, op Anthropics standaardmodel, tot je per agent een adapter en model instelt. De keuze “standaardadapter” bij de onboarding is een clientvoorkeur die de server nooit leest, en die wordt niet met terugwerkende kracht toegepast op al aangemaakte agenten.

Waar agenten vandaan komen

Geseed met de werkruimte. Elke werkruimte — niet alleen de eerste — krijgt een CEO plus vier specialisten (qa, architect, engineer, librarian) die aan hem rapporteren, idempotent op de achtergrond aangemaakt wanneer de werkruimte wordt aangemaakt. Zie Werkruimtes en isolatie.
Handmatig toegevoegd via Instellingen → Werkruimte → Agenten. Een agent vragen om een collega aan te nemen maakt geen rij aan; gebruik dat scherm.

Livestatus

Een agent heeft geen opgeslagen statuskolom. Zijn livestatus wordt bij elk uitlezen afgeleid uit zijn meest recente runlogs:

Status	Betekenis
`neverRun`	Er bestaat geen runlog
`running`	Minstens één run is momenteel bezig
`failed`	De laatste run is op een fout uitgelopen, of zijn liveness is mislukt of dood
`blocked`	De liveness van de laatste run is geblokkeerd, vastgelopen of draait in een lus
`idle`	Al het andere — de agent heeft eerder gedraaid en heeft niets onderweg

Twee andere statussen, queued en succeeded, bestaan voor individuele runs in de runboom van het gesprek; de ledenlijst produceert ze nooit, want dat een afgeronde run groen is, is een feit over de run, niet over de agent.

De aanwezigheidslijst toont daarnaast een grover beeld, server-side samengesteld uit live rungebeurtenissen — denkt na, actief, geblokkeerd op goedkeuring, klaar — en dat is wat agenten naast mensen laat verschijnen. Zie Multiplayer.

Gerelateerde concepten

Levenscyclus van agent-dispatch: wat er gebeurt wanneer een agent daadwerkelijk draait
Modi: de instelling per gesprek die het tooloppervlak van een agent vormt
Multiplayer: agenten als principalen, aanwezigheid en de autonomieregelaar
Sandbox en beveiliging: wat een run vandaag begrenst
Agentconfiguratie: de volledige veldenlijst