Modi

Wat een modus is

Een modus is een eigenschap van een ruimte, opgeslagen als één kolom in de rij van de ruimte. Elk gesprek in een ruimte deelt die eigenschap, threads inbegrepen — een thread neemt de modus van zijn ruimte over zoals elk ander gesprek. Dezelfde agent kan dus tegelijk in verschillende ruimtes in verschillende modi zitten, en het wisselen van de modus van een ruimte verandert wat er in de volgende beurt gebeurt zonder de agent aan te raken.

Er zijn er precies vier: chat, review, plan, orchestrate. De enum zelf bevat geen beleid. Alles wat een modus garandeert, staat één keer vastgelegd in een capaciteitsprofiel, waaruit elke afdwingingslaag afleidt:

Toolaanbod — welke tools überhaupt bestaan in die modus, uitgedrukt als een maximaal goedkeuringsniveau, een toelatingslijst, een weigerlijst en een set geweigerde effectsoorten.
Vereist uitvoerwerkwoord — wat de run moet aanroepen om iets te hebben opgeleverd.
Geweigerde effectsoorten — wat de actiebewaker zonder meer weigert.
Worktree-houding — of er in de worktree mag worden geschreven. Dit wordt afgedwongen door de muterende tools uit het aanbod te halen, en dat is wat het op elke host laat standhouden. Waar de host een OS-sandbox heeft, bepaalt dezelfde houding ook de regels voor schrijven naar het bestandssysteem — een alleen-lezen modus koppelt de worktree alleen-lezen aan — maar dat is een tweede kopie van de garantie, niet degene die het werk doet.
Systempromptblok — een gegenereerde capaciteitspreambule die is afgeleid van de daadwerkelijk gematerialiseerde tool-lijst, plus met de hand geschreven richtlijnen.

Elke afdwingingslaag leidt af uit dat ene profiel, zodat het toolaanbod, de bewaker, de worktree-houding en de prompt het niet met elkaar oneens kunnen zijn.

De vier modi

Chat — getoond als “Agent”

De standaardmodus en de enige modus zonder extra beperkingen: het volledige toolaanbod tot en met het uitvoeringsniveau, een beschrijfbare worktree, geen geweigerde effectsoorten en geen voltooiingscontract. Gebruik hem voor implementatie, bugfixes, vragen over de codebase en alles wat ad hoc is.

Let op het label: in de composer wordt de modus weergegeven als “Agent”, niet als “Chat”.

Plan — alleen-lezen, één resultaat

De planmodus maakt de worktree alleen-lezen en haalt de schrijftools volledig uit het aanbod, zodat de beperking structureel is in plaats van opgedragen. De agent leest, zoekt en onderzoekt, en levert precies één ding op: een submit_plan-aanroep met een getypeerde afhankelijkheidsgraaf — een doel plus nodes met sleutels, titels, beschrijvingen en de nodesleutels waarvan elke node afhangt.

Het plan verschijnt als een compacte rij in het gesprek en opent Plan Studio in een tab ernaast. Als je het goedkeurt, wordt de graaf omgezet in een orkestratie, wordt het gegenereerde werk uitgevoerd en gaat de ruimte waarin het plan is gemaakt terug naar de agentmodus.

Als een run in planmodus eindigt zonder ooit submit_plan aan te roepen, voegt de loop eerst een aansporing toe die zegt dat het plan niet bestaat totdat die aanroep slaagt. De aansporing staat expliciet een eerlijke uitweg toe met “hier is geen plan nodig”, omdat planmodus een ruimte-instelling is en een gewone vraag die daarbinnen wordt gesteld geen onzinnig plan zou moeten afdwingen.

Er is een tweede, aparte uitweg: exit_plan_mode. Het is een harde goedkeuringspoort, geen uitvoerwerkwoord — een agent die het aanroept in plaats van submit_plan, heeft niets opgeleverd. De eerste aanroep opent een duurzame goedkeuring plan_exit en geeft pending terug, en de ruimte blijft alleen-lezen; herhaalde aanroepen blijven pending in plaats van een tweede poort te openen. Pas nadat de goedkeuring is verleend, zet een volgende aanroep de ruimte om naar chat. Bij een afwijzing kan de agent een nieuw verzoek openen voor een herzien plan.

Om planmodus zelf te verlaten, wissel je de vervolgkeuzelijst in de composer (of Shift+Tab). exit_plan_mode wordt besloten met de MCP-tool decide_approval. Rijen met “agentgoedkeuring” in Postvak in zijn iets anders: bevestigingsvragen per beurt van een draaiende agent.

Review — alleen-lezen, geen contract

De reviewmodus is voor PR-reviews. Hij maakt de worktree alleen-lezen, houdt het toolaanbod onder het uitvoeringsniveau en past een samengestelde toelatingslijst toe van review-, ticket- en communicatietools. Een ruimte die voor een pull request wordt geopend, wordt automatisch in reviewmodus aangemaakt.

De uitvoer van de agent bestaat uit gestructureerde bevindingen — reviewnodes — en, wanneer een review wordt afgerond, een oordeel. Een node heeft een soort (bug, suggestion, recommendation, question of ticket), een prioriteit van P0 (blokkeert de release) tot P3 (mooi meegenomen), een zelf ingeschatte zekerheid, een optioneel anker (bestand plus een regelbereik; notities voor de hele repository hebben er geen) en een levenscyclusstatus die van open naar consensusReady gaat zodra een medereviewer — nooit de auteur — die bevestigt. Een bevinding waarvan de prioriteit of zekerheid ontbreekt of buiten het bereik valt, wordt bij de leesgrens weggegooid in plaats van het oordeel te vervuilen.

Het oordeel is Ship, Hold of Block en het kan alleen maar strenger worden door de resultaten per as die erin worden meegenomen: een as met een poort die is mislukt, dwingt block af, en een as met een poort die niet kon draaien, dwingt minstens hold af. Het ontbreken van bewijs maakt een poort nooit groen.

Anders dan plan en orkestratie heeft review geen voltooiingscontract. Bevindingen verzamelen zich via add_review_node en worden gepubliceerd door finalize_review, en beide mogen terecht nul keer worden aangeroepen — een pipeline-agent die in reviewmodus draait, kan er juist zijn om een ticket af te ronden.

Orkestratie — alleen-lezen, stelt een team voor

De orkestratiemodus verandert één doel in een plan voor een heel team. Net als de planmodus is hij alleen-lezen en kan hij geen bestanden schrijven; boven op het onderzoeksaanbod heeft hij één geprivilegieerd werkwoord, propose_orchestration, dat een gestructureerd voorstel uitzendt: rollen, een boom van subtickets, een synthesestap en een budget. De prompt noemt alleen de tools in het aanbod, zodat het model geen beurten verspilt aan het beschrijven van aanstellingen of ticketwerk dat het niet kan aanroepen.

Niets in het voorstel wordt uitgevoerd totdat je het goedkeurt. Bij goedkeuring neemt een deterministische materialisator de agents aan, maakt hij de tickets en een project aan en draait hij een gegenereerde pipeline. Goedkeuren is alleen voor de operator: er is geen MCP-tool voor, dus een agent kan zijn eigen plan voorstellen maar nooit goedkeuren. Nieuwe voorstellen die door een agent worden gestart, worden beperkt door een afkoelperiode van twee minuten, dus opeenvolgende herplanningen worden geweigerd en krijgen de opdracht om samen te voegen. Zie Orkestratie.

Twee regels die je moet kennen

Het eigen uitvoerwerkwoord van een modus kan nooit worden geweigerd. submit_plan en propose_orchestration zijn vastgezet in het toolaanbod en vooraf goedgekeurd langs het toolfilter, de goedkeuringspoort en de actiebewaker heen, zodat de autonomieschakelaar per ruimte het resultaat van een modus niet kan dempen. De ask_user van de harness is om dezelfde reden vastgezet: het is de manier waarop een run de operator bereikt, dus het afschermen ervan zou een run die iets moet vragen, vastlopen. Het zit op leesniveau, dus elke alleen-lezen modus houdt het, en het is vrijgesteld van de goedkeuringswrapper — een prompt vóór een prompt valt gesloten wanneer er geen goedkeurder is verbonden, wat een agent het stellen van een vraag zou ontzeggen.

Alleen-lezen modi weigeren geen netwerktoegang of secrets. De effectsoorten die review, plan en orkestratie weigeren, zijn de soorten die de wereld veranderen: bestanden verwijderen, schrijven buiten de worktree, commits, pushes, het aanmaken en publiceren van PR’s, schrijfacties bij het synchroniseren met externe systemen, pakketinstallaties, processen starten, werkruimtestructuur wijzigen en omhullingen aansturen. Netwerktoegang naar buiten en toegang tot secrets blijven bewust op hun standaardwaarden — onderzoek is juist het hele doel van een alleen-lezen modus.

Een modus kiezen en wijzigen

De modusvervolgkeuzelijst van de composer biedt drie opties: Agent (chat), Plan en Orkestratie. review is niet door de gebruiker te selecteren — die wordt door het systeem ingesteld wanneer een PR-reviewruimte wordt aangemaakt, en door pipelinestappen.

Een pipelinenode die een ruimte opent, kan de modus van die ruimte vastzetten met een extras['mode']-sleutel (chat, review of plan). De sleutel moet exact overeenkomen: elke andere spelling — ook orchestrate — wordt stil genegeerd en de ruimte krijgt de standaardwaarde van de body (review in de create-space-body). Een agentstap voegt zich bij een ruimte die hij niet zelf heeft gemaakt en past de rechten ervan niet aan.

De bepaling zelf is eenvoudig. De dispatcher leest de kolom mode van de ruimte; een dispatch zonder ruimte — een one-shot, een CLI-aanroep, of een ruimte-id uit een andere werkruimte, die simpelweg niet in het databasebestand van deze werkruimte staat — komt uit op chat. De modus wijzigen gaat in vanaf de volgende beurt.

Waar de garantie daadwerkelijk standhoudt

Het toolaanbod van een modus wordt opgebouwd en afgedwongen door de ingebouwde harness. Het is het enige transport dat een tool onzichtbaar kan maken in plaats van alleen te weigeren, elke aanroep kan afschermen voordat die draait, en een voltooiingscontract kan waarnemen.

Op het Claude Code-transport wordt een niet-chatmodus doorgegeven als --permission-mode plan. Claude respecteert dat op basis van conventie; zijn eigen lees-, schrijf- en bewerktools draaien ongezien en zijn shellopdrachten controleert alleen een hook die de opdrachtregel leest. Voor dat transport is de modus een richtlijn, geen grens van Control Center — zie Het agentmodel.

De toelatingslijsten begrenzen tools vanaf schrijfniveau. Het leesniveau van de ingebouwde harness bereikt nog steeds tools die geen enkele lijst noemt; op Claude Code wordt een tool die de toelatingslijst niet vermeldt, geweigerd, of de server hem nu heeft of niet.

Gerelateerde concepten

Levenscyclus van agent-dispatch: waar de modus wordt bepaald en geprojecteerd
Het agentmodel: welke transporten een modus kunnen afdwingen
Beveiligingen: het effectsoortenbeleid waarin de voorinstelling van een modus uitmondt
Orkestratie: wat een goedgekeurd orkestratievoorstel doet
Planmodus gebruiken: de praktische handleiding