Moduser

Hva en modus er

En modus er en egenskap ved et område, lagret som én kolonne på områderaden. Hver samtale i et område deler den, inkludert tråder – en tråd arver modusen til området sitt på samme måte som enhver annen samtale. Den samme agenten kan derfor være i forskjellige moduser i forskjellige områder samtidig, og å bytte modusen til et område endrer det som skjer på neste tur, uten å røre agenten.

Det finnes nøyaktig fire: chat, review, plan, orchestrate. Selve enumet inneholder ingen policy. Alt en modus garanterer, erklæres én gang, i en kapabilitetsprofil, som hvert håndhevingslag projiserer fra:

Verktøyflate – hvilke verktøy som i det hele tatt finnes i den modusen, uttrykt som et maksimalt godkjenningsnivå, en tillatelsesliste, en nektliste og et sett med effektklasser som avvises.
Påkrevd resultatverb – hva kjøringen må kalle for å ha levert noe.
Effektklasser som nektes – hva handlingsvakten avviser blankt.
Worktree-holdning – om det er tillatt å skrive til worktreet. Dette håndheves ved å fjerne de muterende verktøyene fra flaten, og det er det som gjør at det holder på alle verter. Der verten har en OS-sandkasse, skjærer den samme holdningen også ut reglene for skriving til filsystemet – en skrivebeskyttet modus monterer worktreet skrivebeskyttet – men det er en andre kopi av garantien, ikke den som gjør jobben.
Systemprompt-blokk – en generert kapabilitetsinnledning utledet fra den faktiske, materialiserte verktøylisten, pluss håndskrevet veiledning.

Hvert håndhevingslag projiserer fra den ene profilen, så verktøyflaten, vakten, worktree-holdningen og prompten kan ikke være uenige.

De fire modusene

Chat – vises som «Agent»

Standardmodusen og den eneste modusen uten ekstra begrensninger: hele verktøyflaten opp til utførelsesnivået, et skrivbart worktree, ingen nektede effektklasser og ingen fullføringskontrakt. Bruk den til implementering, feilretting, spørsmål om kodebasen og alt ad hoc.

Legg merke til etiketten: i skrivefeltet vises modusen som «Agent», ikke «Chat».

Plan – skrivebeskyttet, én leveranse

Planmodus gjør worktreet skrivebeskyttet og fjerner skriveverktøyene fullstendig fra flaten, så begrensningen er strukturell snarere enn instruert. Agenten leser, søker og undersøker og leverer nøyaktig én ting: et submit_plan-kall som bærer en typet avhengighetsgraf – et mål pluss noder med nøkler, titler, beskrivelser og node-nøklene hver av dem avhenger av.

Planen vises som en kompakt rad i samtalen og åpner Plan Studio i en fane ved siden av. Godkjenner du den, kompileres grafen til en orkestrering, det genererte arbeidet kjøres, og området planen ble laget i, settes tilbake til agentmodus.

Hvis en kjøring i planmodus avsluttes uten å noen gang kalle submit_plan, injiserer løkken først et dytt som sier at planen ikke finnes før det kallet lykkes. Dyttet gir uttrykkelig tillatelse til en ærlig utgang av typen «ingen plan er nødvendig her», fordi planmodus er en innstilling på området, og et enkelt spørsmål stilt i den bør ikke tvinge frem en falsk plan.

Det finnes en andre, separat vei ut: exit_plan_mode. Den er en hard godkjenningsport, ikke et resultatverb – en agent som kaller den i stedet for submit_plan, har ikke levert noe. Det første kallet åpner en varig plan_exit-godkjenning og returnerer pending, og området forblir skrivebeskyttet; gjentatte kall forblir pending i stedet for å åpne en andre port. Først når godkjenningen er gitt, setter et påfølgende kall området til chat. En avvisning lar agenten åpne en ny forespørsel om en revidert plan.

For å forlate planmodus selv bytter du nedtrekksmenyen i skrivefeltet (eller Shift+Tab). exit_plan_mode avgjøres med MCP-verktøyet decide_approval. Radene for «agentgodkjenning» i innboksen er noe annet: bekreftelsesmeldinger per tur fra en agent som kjører.

Gjennomgang – skrivebeskyttet, ingen kontrakt

Gjennomgangsmodus er for PR-gjennomgang. Den gjør worktreet skrivebeskyttet, begrenser verktøyflaten til under utførelsesnivået og bruker en kuratert tillatelsesliste med verktøy for gjennomgang, saker og kommunikasjon. Et område som åpnes for en pull request, opprettes automatisk i gjennomgangsmodus.

Agentens utdata er strukturerte funn – gjennomgangsnoder – og, når en gjennomgang fullføres, en dom. En node bærer en type (bug, suggestion, recommendation, question eller ticket), en prioritet fra P0 (blokkerer utgivelse) til P3 (kjekt å ha), en selvvurdert konfidens, et valgfritt anker (fil pluss et linjeintervall; notater som gjelder hele repoet, har ingen) og en livssyklusstatus som går fra open til consensusReady når en kollega – aldri forfatteren – bekrefter den. Et funn der prioriteten eller konfidensen mangler eller er utenfor gyldig område, forkastes ved lesegrensen i stedet for å forurense dommen.

Dommen er ship, hold eller block, og den gjøres aldri annet enn strengere av resultatene per akse som flettes inn i den: en akse bak en port som mislyktes, tvinger frem block, og en akse bak en port som ikke kunne kjøres, tvinger frem minst hold. Fravær av bevis gjør aldri en port grønn.

I motsetning til plan og orkestrering har gjennomgang ingen fullføringskontrakt. Funn samles opp gjennom add_review_node og publiseres av finalize_review, og begge kan med rette kalles null ganger – en pipeline-agent som kjører i gjennomgangsmodus, kan være der for å fullføre en sak i stedet.

Orkestrering – skrivebeskyttet, foreslår et team

Orkestreringsmodus gjør ett mål om til en plan for et helt team. Som planmodus er den skrivebeskyttet og kan ikke skrive filer; oppå undersøkelsesflaten har den ett enkelt privilegert verb, propose_orchestration, som avgir et strukturert forslag: roller, et tre av undersaker, et syntesesteg og et budsjett. Prompten navngir bare verktøyene som finnes på flaten, så modellen bruker ikke turer på å fortelle om ansettelser eller sakearbeid den ikke kan kalle.

Ingenting i forslaget utføres før du godkjenner det. Ved godkjenning ansetter en deterministisk materialisator agentene, oppretter sakene og et prosjekt og kjører en generert pipeline. Godkjenning er kun for operatøren: det finnes ikke noe MCP-verktøy for det, så en agent kan foreslå, men aldri godkjenne sin egen plan. Nye forslag som settes i gang av en agent, begrenses av en nedkjølingstid på to minutter, så påfølgende omplanlegginger avvises og bes om å slås sammen. Se Orkestrering.

To regler det er verdt å kjenne

Resultatverbet til en modus kan aldri nektes. submit_plan og propose_orchestration er festet i verktøyflaten og forhåndsgodkjent forbi både verktøyfilteret, godkjenningsporten og handlingsvakten, så autonomiknotten per område ikke kan stilne leveransen til en modus. Harnessets ask_user er festet av samme grunn: det er måten en kjøring når operatøren på, så å portvokte det ville låse fast en kjøring som trenger å spørre om noe. Det ligger på lesenivå, så alle skrivebeskyttede moduser beholder det, og det er unntatt fra godkjenningsinnpakningen – en prompt foran en prompt feiler lukket når ingen godkjenner er tilkoblet, noe som ville nekte en agent selve handlingen å spørre.

Skrivebeskyttede moduser nekter ikke nettverkstilgang eller hemmeligheter. Effektklassene som gjennomgang, plan og orkestrering nekter, er de som endrer verden: sletting av filer, skriving utenfor worktreet, commits, pushes, oppretting og publisering av PR-er, synkroniseringsskrivinger mot leverandører, pakkeinstallasjoner, oppstart av prosesser, mutasjon av arbeidsområdet og kontroll av isolerte miljøer (stasjoner). Utgående nettverkstrafikk og tilgang til hemmeligheter forblir bevisst på standardverdiene sine – undersøkelse er hele poenget med en skrivebeskyttet modus.

Å velge og bytte modus

Modusnedtrekksmenyen i skrivefeltet tilbyr tre alternativer: Agent (chat), Plan og Orkestrer. review kan ikke velges av brukeren – den settes av systemet når et PR-gjennomgangsområde opprettes, og av pipeline-steg.

En pipeline-node som åpner et område, kan låse modusen til det rommet med en extras['mode']-nøkkel (chat, review eller plan). Nøkkelen krever eksakt samsvar: enhver annen stavemåte – inkludert orchestrate – ignoreres i stillhet, og rommet får standardverdien fra kallet (review i create-space-kallet). Et agentsteg blir med i et rom det ikke opprettet selv, og gir det ikke nye tillatelser.

Oppslaget i seg selv er enkelt. Utsenderen leser mode-kolonnen til området; en utsending uten område – en enkeltkjøring, et CLI-kall eller en område-id fra et annet arbeidsområde, som rett og slett ikke finnes i dette arbeidsområdets databasefil – løses opp til chat. Å bytte modus trer i kraft fra neste tur.

Hvor garantien faktisk holder

Verktøyflaten til en modus bygges og håndheves av det innebygde harnesset. Det er den eneste transporten som kan gjøre et verktøy usynlig i stedet for bare nektet, portvokte hvert kall før det kjøres og observere en fullføringskontrakt.

På Claude Code-transporten sendes en modus som ikke er chat, som --permission-mode plan. Claude respekterer det av konvensjon; dets egne verktøy for lesing, skriving og redigering kjører usett, og shell-kommandoene dets kontrolleres bare av en hook som leser kommandolinjen. For den transporten er modusen en veiledning, ikke en grense i Control Center – se Agentmodellen.

Tillatelseslistene begrenser verktøy på skrivenivå og høyere. Lesenivået i det innebygde harnesset når fortsatt verktøy som ingen liste navngir; på Claude Code nektes et verktøy som tillatelseslisten utelater, uansett om serveren har det.

Beslektede konsepter

Livssyklus for agentutsending: hvor modusen løses opp og projiseres
Agentmodellen: hvilke transporter som kan håndheve en modus
Tillatelsesregler: effektklassepolicyen som forhåndsinnstillingen til en modus mater inn i
Orkestrering: hva et godkjent orkestreringsforslag gjør
Bruk planmodus: den praktiske gjennomgangen