Levenscyclus van agent-dispatch

Wat een dispatch is

Een dispatch is één run van één agent, in één gesprek, op één adapter. Alles eromheen gebeurt op cc_server: de client stuurt een bericht en kijkt daarna hoe gebeurtenissen terugstromen. Er is geen dispatchpad in welke client dan ook.

Agenten worden om zes redenen gewekt; de run draagt die reden mee als zijn wekcontext, zodat de agent weet waarom hij wakker is:

Wekreden	Trigger
userMessage	Iemand heeft een bericht in een ruimte gestuurd, of heeft de agent vermeld
assignment	Er is een ticket aan de agent toegewezen
pipelineStep	Een pipelinestap heeft hem gedispatcht
childCompleted	Een kindticket is afgerond
followUp	Een geplande vervolghartslag
recovery	Het herstelpad heeft hem na een fout opnieuw gedispatcht

De wekcontext draagt de id’s mee die bij de reden horen — ticket, ruimte, bericht, pipelinerun — en die worden in de omgeving en de prompt van de agent geïnjecteerd.

Promptopbouw

De prompt wordt in lagen opgebouwd, elk een gelabelde sectie:

• Identiteit — de eigen id, naam en werkruimte-id van de agent, met een expliciete instructie om die exacte UUID’s aan werkruimtegebonden tools door te geven. De werkruimte is intrinsiek aan de agent en is dus altijd aanwezig.
• Toolcatalogus en resourceprotocollen, daarna de indeling van de werkruimte.
• Systeemprompt-override, als de agent er een heeft, daarna persona (geparametriseerd op rol) en de teambriefing.
• Skills — de namen die aan de agent hangen.
• Uitvoeringscontract en -procedure voor de huidige modus.
• Wekcontext en vermeldingscontext: wie de agent heeft opgeroepen en het rooster eromheen.
• Modusblok — gegenereerd uit het mogelijkhedenprofiel van de modus en de gematerialiseerde toollijst ervan, zodat een prompt nooit een tool kan noemen die de run niet echt heeft.
• Geheugencontext — feiten die voor de taak zijn opgehaald.
• Gesprekscontext — recente geschiedenis van de ruimte, begrensd op 50.000 tekens letterlijk venster, ongeacht de ingestelde contextgrootte van de agent. Oudere geschiedenis wordt niet weggeknipt: de agent haalt die op verzoek op met get_messages, en semantisch relevante oudere berichten komen alsnog boven.

Slash-commando’s worden uit de ruwe gebruikerstekst geparseerd

De gelaagde prompt begint met een contextblok en begint dus niet met een slash. Commando’s worden letterlijk uit het bericht van de gebruiker geparseerd en daarna uit de staart van de gelaagde prompt geknipt, zodat elke contextlaag behouden blijft.

Commando’s zijn over twee plekken verdeeld. /todo en /compact worden in de composer onderschept en bewust nooit als bericht opgeslagen of naar de agent gestuurd — het opslaan van /compact zou de compactiegrens een beurt terugschuiven en het transcript vervuilen. /plan wordt op beide plekken afgehandeld: de composer zet de modus van de ruimte om, en dat is wat het tooloppervlak, de beveiligingspreset en de prompt voor deze beurt en elke beurt daarna met elkaar laat kloppen. /goal, /loop en /skill:<name> worden binnen de run zelf afgehandeld en alleen op de ingebouwde harness — /goal en /loop starten autonoom werk met een kostenbudget, en een naam met het voorvoegsel skill: wordt als skill opgezocht, waarbij de inhoud van de SKILL.md de richtlijn voor de beurt wordt. De namespace is wat de twee vocabularia uit elkaar houdt: een kale naam tegen skills oplossen betekende dat een skill met de naam plan of compact permanent door de ingebouwde variant werd overschaduwd. Een kale, niet-ingebouwde naam wordt nog steeds opgelost, voor berichten die zijn geschreven voordat de namespace bestond. Een niet-herkende naam valt gewoon door als platte tekst.

Worktree-voorbereiding

Voordat er iets draait, krijgt het gesprek zijn eigen werk-root, met daaronder per repo een geïsoleerde copy-on-write-worktree. Standaard is dat elke repo die aan de werkruimte is gekoppeld; een PR-ruimte — of een ruimte die met een expliciete selectie is aangemaakt — provisioneert alleen de toegestane repo’s, en een PR-reviewgesprek zet zijn ene repo vast op de head-ref van de pull request terwijl de andere op hun standaardbranch blijven. De broncheckout wordt nooit gewijzigd en de hele gespreksmap wordt vrijgegeven wanneer de ruimte wordt verwijderd.

Copy-on-write is de enige implementatie overal waar rift meelevert, ondersteund door de meegeleverde native. Een bestandssysteem dat niet kan reflinken — of een datadir op een ander volume dan de repo — laat de provisioning mislukken in plaats van terug te vallen. git worktree is de backend op Windows, waar geen copy-on-write-backend te bouwen is, en het is op andere hosts geen stille verslechtering. Een ontbrekende rift op een platform dat het meelevert is een kapotte installatie — de server weigert op te starten in plaats van stil terug te vallen, want een stille terugval verbergt de breuk voor altijd achter een langzamer pad.

Identiteit en inloggegevens

Per run worden twee identiteiten bepaald, voordat er een proces start.

Git-auteurschap. Commits die een agent maakt, worden als de agent toegeschreven — <Name> (agent) <agentId@agents.control-center.local> in zowel GIT_AUTHOR_* als GIT_COMMITTER_* — en nooit als een mens. Het local-part is de UUID van de agent, niet de slug van zijn naam. De mens die het verzoek doet, krijgt een Co-Authored-By:-trailer, die in de omgeving wordt meegegeven en in de systeemprompt wordt geïnstrueerd. Een expliciete identiteit die de aanroeper instelt, wint altijd van beide.

Codehost-identiteit. De GitHub-inloggegevens van de run zijn altijd alleen die van de broker — een App-installatietoken met repo-scope, of de PAT-fallback uit de omgeving — nooit het eigen opgeslagen token van het aanvragende lid. actingUserId begrenst de PAT-fallback, zodat een lid dat niet de servereigenaar is niet het bereik van de server erft; het legt geen persoonlijk token over de agentomgeving heen.

Inloggegevens van modelproviders worden in een vaste volgorde bepaald, en die volgorde is belangrijk:

1. een omgevings-override per adapter,
2. de omgeving van de aanroeper,
3. de credential-store van de server (waarbij een OAuth-token wordt vernieuwd als het bijna verloopt),
4. de omgeving van het proces.

Omdat de override per adapter vooraan staat, wint die stil van een provideraccount dat in de app is gekoppeld. Als een run op de verkeerde rekening afrekent, is die override de eerste plek om te kijken. Providergegevens zijn host-globaal — gedeeld over elke werkruimte op de installatie.

Het GitHub-token van de run komt van de credentialbroker: een token met alleen leesrechten, beperkt tot de repo van de worktree. Een push loopt via de agentrun-gateway, die de regel Naar een remote pushen raadpleegt voordat hij hem doorstuurt, en er wordt geen ticketingsleutel geïnjecteerd. Zie Sandbox en beveiliging.

Starten

De run wordt gestart met zijn worktree als werkmap en — voor Claude Code — een gegenereerde MCP-configuratie, zodat de agent het tooloppervlak van Control Center kan bereiken. ACP en de bash van de harness krijgen een gesaneerde omgeving; Claude Code via NoSandboxAdapter erft de omgeving van de host.

De OS-sandbox omhult een run alleen waar de host een backend heeft

cc_server probeert de host één keer bij het opstarten en omhult agentprocessen ermee wanneer er een backend beschikbaar is — Seatbelt op macOS, bubblewrap op Linux en WSL2. Beide dispatchnaden worden omhuld, omdat ze er geen delen: de Claude Code CLI gaat via de sandboxpoort; ACP-adapters en de bash-tool van de ingebouwde harness gaan via de sandboxmanager. Het is ook wat de beschermde paden van de run toepast: je geregistreerde repocheckouts zijn deny-write binnen de sandbox, in elke modus.

Waar geen backend is, wordt de run niet gesandboxed en verandert er verder niets als compensatie. Dat betekent: altijd Windows (geen native omhulling — microvm is een apart, door een probe geactiveerd pad voor terminals en rigs) en Linux of WSL2 zonder bwrap en socat op het PATH. De server noemt in welke toestand hij verkeert op zijn opstartregel in het log, en --sandbox off kiest er bewust voor om af te zien van sandboxing.

Twee hiaten overleven de sandbox, ook waar die aanstaat. De in-process bestandstools van de harness (read, write, edit, apply patch, search, find, search_files) draaien in het serverproces, dus geen enkel profiel beperkt ze — hun grens is de eigen padbeperking van de tools plus de beveiligingen. En Claude Code wordt gestart met --dangerously-skip-permissions, dus zijn eigen bestandsaanroepen worden niet door Control Center bewaakt en zijn shellopdrachten alleen door een hook die de opdrachtregel leest; de OS-sandbox is de grens eromheen.

De overige grenzen gelden op elke host, met of zonder sandbox: de eigen worktree van de run (copy-on-write waar rift meelevert; git worktree op Windows), een forge-token met alleen leesrechten dat per start via de broker wordt verstrekt en bij het opruimen wordt ingetrokken, pushes die bij de agentrun-gateway langs de pushregel moeten, de uniforme actiebeveiligingen (fail-closed — een prompt-beslissing zonder verbonden goedkeurder wordt geweigerd) en het tooloppervlak dat de modus van het gesprek toestaat. ACP en de bash van de harness saneren de omgeving nog steeds; Claude Code via NoSandboxAdapter erft de omgeving van de host.

Streamen

De run streamt een getypeerde reeks gebeurtenissen terug, die de streamprocessor opslaat als berichtdelta’s, samenvoegt tot transcriptsegmenten en omzet in berichtgebeurtenissen:

Gebeurtenis	Wat het meedraagt
thinking	Redeneeruitvoer, inline weergegeven
text	Zichtbare uitvoer
toolCall	Een toolaanroep, met zijn id en gestructureerde argumenten
toolResult	Het bijbehorende resultaat, gemarkeerd wanneer het een fout gaf of een gedeeltelijke stream is
usage	Tokentellingen en kosten voor een meetvenster
error	Een fout, met de gestructureerde code van de adapter wanneer die er een rapporteerde
sandboxViolation	Het besturingssysteem weigerde een syscall. Wordt alleen uitgezonden waar een sandbox het proces daadwerkelijk omhult — zie de opmerking hierboven
debug	Runtime-diagnostiek (startmarkeringen, beveiligingsbeslissingen, contractduwtjes)
done	De run is afgerond

Wat een run begrenst

Er is bewust nergens een beurtplafond. Een harde iteratietelling doodt legitiem lang werk (migraties, fan-out-opruiming) en vangt niets wat de beveiligingen hieronder eerder vangen. Een run eindigt wanneer:

• het model zelf stopt;
• een mens hem stopt, of het gesprek overneemt (waardoor de ingebouwde harness pauzeert bij zijn volgende schone beurtgrens — een Claude Code-run, die geen veilige grens heeft, wordt in plaats daarvan gestopt);
• de stiltewatchdog afgaat. Geen uitvoer binnen de drempel en de sessie wordt beëindigd met een silentRun-fout. De standaard is 15 minuten, wat terugloopt naar 10 in de vooral lezende modi (review en plan); een agent mag hem tussen 1 en 240 minuten overschrijven. De watchdog wordt bewapend wanneer een kindproces zijn PID rapporteert, dus hij dekt de Claude Code CLI — niet de ingebouwde harness, die niets start;
• een kostenplafond toeslaat — maar alleen voor autonome commando’s.

De doom-loopbeveiliging is geen terminator: drie identieke toolaanroepen op een rij en de lus stuurt de agent bij om van aanpak te veranderen.

Een normale beurt heeft geen kostenplafond

De kostenbeveiliging binnen de sessie is alleen aangesloten voor /goal en /loop; elke andere run geeft helemaal geen budget mee. Voor die commando’s mag één onbeheerd segment standaard 500 cent ($5.00) verbruiken, met een zachte bijsturing op 80% die de agent vraagt om netjes af te ronden vóór de harde stop, en een duurzaam doelbudget van 5000 cent ($50.00) over segmenten heen. Een expliciet /goal --budget wordt nooit met een heel segment overschreden.

Alles bij elkaar heeft een gewone interactieve beurt op de ingebouwde harness geen beurtplafond, geen kostenplafond en geen stiltewatchdog. Hij eindigt wanneer het model stopt of wanneer jij hem stopt. Dat is een bewuste afweging — de alternatieven doden allemaal legitiem lang werk — maar het betekent wel dat een onbeheerde interactieve run door niets anders wordt begrensd dan het eigen oordeel van het model.

Tijdens een run wordt een bericht dat naar een draaiende agent wordt gestuurd in de wachtrij gezet als bijsturing en bij de volgende beurtgrens geleegd, zodat je een run kunt bijsturen zonder hem te doden. Bijsturing, pauzeren, subagenten en het afrondingscontract zijn functies van de ingebouwde harness; Claude Code heeft ze geen van alle.

Hoe een run wordt vastgelegd

Elke dispatch schrijft een AgentRunLog: begin- en eindtijd, samenvatting, tokentellingen en geschatte kosten (inclusief kosten die van subagenten worden opgeteld), adapter en model, proces-id en logpad, het gesprek en elk ticket of pipelinerun waartoe hij hoort, plus twee classificatievelden die het meeste van de waarheid dragen.

• Status is grof: pending, running, completed, error.
• Levendigheid is de fijnere lezing: alive, productive, completed, blocked, empty, looping, failed, stalled, dead.
• Foutfamilie groepeert fouten nuttig: transientUpstream, sandboxInfrastructure, budgetExceeded, processLost, silentRun, unknown.

completed betekent niet “geleverd”

Wanneer een run eindigt zonder het resultaat dat zijn modus vereiste — een planmodus-run die nooit submit_plan heeft aangeroepen, een orkestratierun die nooit iets heeft voorgesteld — blijft de status completed, omdat het proces wel netjes is afgesloten. Het eerlijke signaal zit op levendigheid (empty), foutfamilie (silentRun) en een samenvatting die precies zegt wat er niet is geproduceerd. Die samenvatting is beschermd: de afronding overschrijft hem niet met het laatste geklets van het model.

Dit is bewust. De status omzetten zou ticket- en pipelinestatemachines verplaatsen die niets met het ontbrekende artefact te maken hebben. Het betekent ook dat “status: completed” alleen nooit genoeg is om te concluderen dat een run is geslaagd — lees de samenvatting.

Het sluiten van de run publiceert AgentRunCompleted en daar hangt veel aan: kostenoptelling van de pipeline, het hervatten van een pipelinestap die op de run wachtte, het afronden van het onderliggende ticket, het mappen van een orkestratie op een eindtoestand, de voort-of-stopbeslissing van de doelsupervisor, de rol van controleur en de budgetevaluatie na de run. Het aanwezigheidsrooster volgt apart, door naar de recente run-logs te kijken in plaats van naar de gebeurtenis. De melding “agent voltooid” staat niet in dat rijtje: de gebeurtenis vuurt zodra de processtroom eindigt, voordat het antwoord is weggeschreven, dus de melding is de MessageReceived van de beurt, gepubliceerd zodra het bericht is opgeslagen.

Budgetten, achteraf

Budgethandhaving is een reactie, geen poort. Wanneer een run klaar is, vergelijkt de evaluator de uitgaven van de agent van deze maand tot nu toe met het effectieve plafond (een gekoppeld budgetbeleid als dat er is, anders het eigen maandbedrag van de agent; nul betekent onbeperkt). Het overschrijden van de zachte drempel legt een waarschuwingsincident vast; het uitputten van het budget legt een hard incident vast en zet de levenscyclusstatus van de agent op paused in het organigram. Dispatch accepteert nog steeds werk van die agent. Een pipelinetrigger BudgetThresholdCrossed kan vervolgwerk vanuit dezelfde gebeurtenis starten.

Afstamming van nieuwe pogingen

Elke run-log kan afstamming van nieuwe pogingen bevatten — een bovenliggende run-id, een pogingsteller en een samenvatting voor continuering. De gespreksrunboom toont het pogingsnummer wanneer dat niet nul is. Een “opnieuw proberen” vanuit de chat is een nieuwe dispatch met een verse run-log.

Gerelateerde concepten

• Het agentmodel: wat de adapter wel en niet kan afdwingen
• Modi: waar het tooloppervlak en het afrondingscontract vandaan komen
• Beveiligingen: het effectklassebeleid dat elke bewaakte aanroep passeert
• Sandbox en beveiliging: het volledige isolatieverhaal
• Multiplayer: bijsturing, overnemen en de autonomieknop
• Domeingebeurtenissen: wat AgentRunCompleted in gang zet