Livssyklus for agentutsending

Hva en utsending er

En utsending er én kjøring av én agent, i én samtale, på én adapter. Alt med den skjer på cc_server: klienten sender en melding og ser deretter på at hendelser strømmer tilbake. Det finnes ingen utsendingsbane i noen klient.

Agenter vekkes av seks årsaker, som kjøringen bærer med seg som sin vekkekontekst, slik at agenten vet hvorfor den er våken:

Vekkingsårsak	Utløser
userMessage	Noen sendte en melding i et område, eller nevnte agenten
assignment	En sak ble tildelt agenten
pipelineStep	Et pipeline-steg sendte den ut
childCompleted	En underordnet sak ble fullført
followUp	Et planlagt hjerteslag for oppfølging
recovery	Gjenopprettingsbanen sendte ut på nytt etter en feil

Vekkekonteksten bærer med seg id-ene som hører til årsaken — sak, område, melding, pipeline-kjøring — og de injiseres i agentens miljø og prompt.

Sammensetting av prompten

Prompten bygges i lag, hvert av dem en merket seksjon:

• Identitet — agentens egen id, navn og arbeidsområde-id, med en eksplisitt instruks om å sende disse eksakte UUID-ene til verktøy som er knyttet til arbeidsområdet. Arbeidsområdet er en iboende del av agenten, så det er alltid til stede.
• Verktøykatalog og ressursprotokoller, deretter oppsettet av arbeidsområdet.
• Overstyring av systemprompten, hvis agenten har en, deretter persona (parametrisert etter rolle) og teamorienteringen.
• Ferdigheter — navnene som ligger på agenten.
• Utførelseskontrakt og prosedyre for gjeldende modus.
• Vekkekontekst og omtalekontekst: hvem som tilkalte agenten, og listen rundt den.
• Modusblokk — generert fra modusens kapabilitetsprofil og dens materialiserte verktøyliste, så en prompt aldri kan navngi et verktøy kjøringen faktisk ikke har.
• Minnekontekst — fakta som hentes fram for oppgaven.
• Samtalekontekst — nyere historikk fra området, begrenset til 50 000 tegns ordrett vindu uavhengig av agentens konfigurerte kontekststørrelse. Eldre historikk blir ikke kuttet bort: agenten henter den ved behov med get_messages, og semantisk relevante eldre meldinger dukker fortsatt opp.

Skråstrekkommandoer analyseres fra den rå brukerteksten

Den lagdelte prompten starter med en kontekstblokk, så den begynner ikke med en skråstrek. Kommandoer analyseres ordrett fra brukerens melding og skjæres deretter ut fra halen av den lagdelte prompten, slik at hvert kontekstlag overlever.

Kommandoer er delt mellom to steder. /todo og /compact fanges opp i skrivefeltet og lagres bevisst aldri som meldinger eller sendes til agenten — å lagre /compact ville flytte komprimeringskuttet en tur tilbake og forurense transkriptet. /plan håndteres begge steder: skrivefeltet bytter modusen til området, og det er det som gjør at verktøyflaten, forhåndsvalget av tillatelsesregler og prompten stemmer overens for denne turen og hver tur etter den. /goal, /loop og /skill:<name> håndteres inne i selve kjøringen, og bare på det innebygde harnesset — /goal og /loop starter autonomt arbeid med et kostnadsbudsjett, og et navn med prefikset skill: slås opp som en ferdighet der kroppen i SKILL.md blir turens direktiv. Navnerommet er det som holder de to vokabularene fra hverandre: å slå opp et bart navn mot ferdigheter gjorde at en ferdighet som het plan eller compact var permanent skyggelagt av det innebygde. Et bart navn som ikke er innebygd, slås fortsatt opp, for meldinger skrevet før navnerommet fantes. Et ukjent navn faller bare gjennom som ren tekst.

Klargjøring av worktree

Før noe kjøres, får samtalen sin egen arbeidsrot, med en isolert copy-on-write-worktree per repo under den. Som standard er det hvert repo som er koblet til arbeidsområdet; et PR-område — eller et område opprettet med et eksplisitt utvalg — klargjør bare de som står på tillatelseslisten, og en PR-gjennomgangssamtale fester det ene repoet sitt til pull requestens head-ref mens de andre blir stående på standardgrenen. Kildeutsjekkingen endres aldri, og hele samtalekatalogen gjenvinnes når området slettes.

Copy-on-write er den eneste implementasjonen overalt der rift leveres, støttet av den medfølgende native-koden. Et filsystem som ikke kan reflinke — eller en datakatalog på et annet volum enn repoet — får klargjøringen til å feile i stedet for å falle tilbake. git worktree er backenden på Windows, der det ikke finnes noen copy-on-write-backend å bygge, og det er ikke en stille degradendering på andre verter. En manglende rift på en plattform som leverer den, er en ødelagt installasjon — serveren nekter å starte i stedet for å falle stille tilbake, fordi en stille reserveløsning skjuler bruddet bak en tregere bane for alltid.

Identitet og legitimasjon

To identiteter løses per kjøring, før noen prosess startes.

Git-forfatterskap. Commitene en agent lager, forfattes som agenten — <Name> (agent) <agentId@agents.control-center.local> i både GIT_AUTHOR_* og GIT_COMMITTER_* — og utgir seg aldri for å være et menneske. Lokal-delen er agentens UUID, ikke navneslugen. Mennesket som ba om det, krediteres med en Co-Authored-By:-trailer, som bæres i miljøet og instrueres om i systemprompten. En eksplisitt identitet satt av kalleren vinner alltid over begge.

Forge-identitet. Kjøringens GitHub-legitimasjon er alltid bare meglerens — et App-installasjonstoken begrenset til repoet, eller dens PAT-reserveløsning fra miljøet — aldri det egne lagrede tokenet til medlemmet som ba om det. actingUserId begrenser PAT-reserveløsningen slik at et medlem som ikke er servereier, ikke arver serverens rekkevidde; den legger ikke et personlig token oppå agentmiljøet.

Legitimasjon for modelltilbydere løses i en fast rekkefølge, og rekkefølgen betyr noe:

1. en miljøoverstyring per adapter,
2. kallerens miljø,
3. serverens legitimasjonslager (fornyer et OAuth-token hvis det nærmer seg utløp),
4. prosessmiljøet.

Fordi overstyringen per adapter kommer først, slår den stille en tilbyderkonto som er koblet til i appen. Hvis en kjøring faktureres til feil konto, er den overstyringen det første stedet å se. Tilbyderlegitimasjon er global for verten — delt på tvers av alle arbeidsområder i installasjonen.

Kjøringens GitHub-token kommer fra legitimasjonsmegleren: et token som bare kan lese, begrenset til worktreens repo. En push går gjennom agentkjøringsgatewayen, som spør regelen Push til en remote før den sendes videre, og ingen saksnøkkel injiseres. Se Sandkasse og sikkerhet.

Oppstart

Kjøringen startes med worktreen sin som arbeidskatalog og — for Claude Code — en generert MCP-konfigurasjon, slik at agenten kan nå Control Centers verktøyflate. ACP og harnessets bash får et renset miljø; Claude Code gjennom NoSandboxAdapter arver vertsmiljøet.

OS-sandkassen omslutter en kjøring bare der verten har en backend

cc_server sonderer verten én gang ved oppstart, og når en backend er tilgjengelig, omslutter den agentprosesser i den — Seatbelt på macOS, bubblewrap på Linux og WSL2. Begge utsendingssømmene omsluttes, fordi de ikke deler ett: Claude Code-CLI-en går gjennom sandkasseporten; ACP-adaptere og det innebygde harnessets bash-verktøy går gjennom sandkassestyringen. Det er også den som bruker kjøringens beskyttede stier: de registrerte repo-utsjekkingene dine har skriveforbud inne i sandkassen, i alle moduser.

Der det ikke finnes noen backend, er kjøringen ikke sandkasset, og ingenting annet endres for å kompensere. Det betyr Windows alltid (ingen innebygd omslutning — microvm er en egen, sondestyrt bane for terminaler og stasjoner) og Linux eller WSL2 uten bwrap og socat på PATH. Serveren navngir hvilken tilstand den er i på oppstartslinjen i loggen, og --sandbox off melder seg bevisst ut.

To hull overlever sandkassen selv der den er på. Harnessets filverktøy i prosessen (read, write, edit, apply patch, search, find, search_files) kjører inne i serverprosessen, så ingen profil begrenser dem — grensen deres er verktøyenes egen baneinneslutning pluss tillatelsesreglene. Og Claude Code startes med --dangerously-skip-permissions, så dets egne filkall er ikke portvoktet av Control Center, og skallkommandoene bare av en hook som leser kommandolinjen; OS-sandkassen er grensen rundt dem.

De gjenværende grensene gjelder på alle verter, med eller uten sandkasse: kjøringens egen worktree (copy-on-write der rift leveres; git worktree på Windows), et kodeverttoken som bare kan lese, formidlet per oppstart og tilbakekalt ved avslutning, pusher som må gjennom push-regelen i agentkjøringsgatewayen, de samlede tillatelsesreglene for handlinger (feiler lukket — en prompt-beslutning uten noen tilkoblet godkjenner avslås) og verktøyflaten samtalens modus tillater. ACP og harnessets bash renser fortsatt miljøet; Claude Code gjennom NoSandboxAdapter arver vertsmiljøet.

Strømming

Kjøringen strømmer en typet hendelsessekvens tilbake, som strømmeprosessoren lagrer som meldingsdeltaer, folder inn i transkriptsegmenter og gjør om til meldingshendelser:

Hendelse	Hva den inneholder
thinking	Resonneringsutdata, gjengitt inline
text	Synlig utdata
toolCall	Et verktøykall, med sin id og strukturerte argumenter
toolResult	Det tilhørende resultatet, flagget når det feilet eller er en delvis strøm
usage	Token-tellinger og kostnad for et målevindu
error	En feil, med adapterens strukturerte kode når den rapporterte en
sandboxViolation	OS nektet et systemkall. Sendes bare der en sandkasse faktisk omslutter prosessen — se merknaden over
debug	Kjøretidsdiagnostikk (oppstartsmarkører, beslutninger fra tillatelsesreglene, påminnelser fra kontrakten)
done	Kjøringen er ferdig

Hva som begrenser en kjøring

Det finnes bevisst ingen turgrense noe sted. Et hardt iterasjonstall dreper legitimt langt arbeid (migreringer, opprydding etter vifteutrulling) og fanger ingenting som vaktene nedenfor fanger tidligere. En kjøring avsluttes når:

• modellen stopper av seg selv;
• et menneske stopper den, eller tar over samtalen (som setter det innebygde harnesset på pause ved neste rene turgrense — en Claude Code-kjøring, som ikke har noen trygg grense, stoppes i stedet);
• stillhetsvakthunden slår til. Ingen utdata i terskelperioden, og økten avsluttes med en silentRun-feil. Standard er 15 minutter, som synker til 10 i de leseorienterte modusene (gjennomgang og plan); en agent kan overstyre den mellom 1 og 240 minutter. Vakthunden armeres når en underprosess rapporterer PID-en sin, så den dekker Claude Code-CLI-en — ikke det innebygde harnesset, som ikke starter noen prosess;
• et kostnadstak slår inn — men bare for autonome kommandoer.

Vakten mot gjentakelsesløkker er ikke en terminator: tre identiske verktøykall på rad, og løkken styrer agenten til å bytte tilnærming.

En vanlig tur har ingen kostnadsgrense

Kostnadsvakten i økten er bare koblet inn for /goal og /loop; alle andre kjøringer sender ikke inn noe budsjett i det hele tatt. For disse kommandoene kan ett uovervåket segment brenne 500 cent ($5.00) som standard, med en myk styring ved 80 % som ber agenten avslutte ryddig før den harde stoppen, og et varig mål-budsjett på 5000 cent ($50.00) på tvers av segmenter. En eksplisitt /goal --budget overskrides aldri med et helt segment.

Samlet sett har en vanlig interaktiv tur på det innebygde harnesset ingen turgrense, ingen kostnadsgrense og ingen stillhetsvakthund. Den avsluttes når modellen stopper, eller når du stopper den. Det er en bevisst avveining — alternativene dreper alt legitimt langt arbeid — men det betyr at en uovervåket interaktiv kjøring ikke begrenses av annet enn modellens egen dømmekraft.

Midt i en kjøring settes en melding som sendes til en kjørende agent, i kø som styring og tømmes ved neste turgrense, så du kan dytte på en kjøring uten å drepe den. Styring, pause, underagenter og fullføringskontrakten er funksjoner i det innebygde harnesset; Claude Code har ingen av dem.

Hvordan en kjøring registreres

Hver utsending skriver en AgentRunLog: start- og sluttid, sammendrag, token-tellinger og estimert kostnad (inkludert kostnad samlet opp fra underagenter), adapter og modell, prosess-id og loggsti, samtalen og eventuell sak eller pipeline-kjøring den hører til, pluss to klassifiseringsfelt som bærer det meste av sannheten.

• Status er grovkornet: pending, running, completed, error.
• Livstilstand er den finere lesningen: alive, productive, completed, blocked, empty, looping, failed, stalled, dead.
• Feilfamilie grupperer feil på en nyttig måte: transientUpstream, sandboxInfrastructure, budgetExceeded, processLost, silentRun, unknown.

completed betyr ikke «levert»

Når en kjøring avsluttes uten leveransen modusen krevde — en plan-modus-kjøring som aldri kalte submit_plan, en orkestrer-kjøring som aldri foreslo noe — forblir statusen completed, fordi prosessen faktisk avsluttet rent. Det ærlige signalet ligger på livstilstanden (empty), feilfamilien (silentRun) og et sammendrag som sier nøyaktig hva som ikke ble produsert. Det sammendraget er beskyttet: finaliseringen overskriver det ikke med modellens siste prat.

Dette er bevisst. Å vippe statusen ville flytte saks- og pipeline-tilstandsmaskiner som ikke har noe med den manglende artefakten å gjøre. Det betyr også at «status: completed» alene aldri er nok til å konkludere med at en kjøring lyktes — les sammendraget.

Å lukke kjøringen publiserer AgentRunCompleted, og mye henger på den: oppsamling av pipeline-kostnader, gjenopptakelse av et pipeline-steg som ventet på kjøringen, fullføring av den bakenforliggende saken, kartlegging av en orkestrering til en sluttilstand, målvokterens beslutning om å fortsette eller stoppe, kontrollørrollen og budsjettvurderingen etter kjøringen. Tilstedeværelseslisten følger separat, ved å se på de nyeste kjøringsloggene i stedet for hendelsen. «Agent ferdig»-varselet står ikke på den listen: hendelsen utløses når prosessstrømmen slutter, før svaret er skrevet, så varselet er turens MessageReceived, som publiseres når meldingen er lagret.

Budsjetter, i etterkant

Budsjetthåndheving er en reaksjon, ikke en port. Når en kjøring fullføres, sammenligner evaluatoren agentens forbruk så langt i måneden med det effektive taket (en koblet budsjettpolicy hvis det finnes en, ellers agentens eget månedstall; null betyr ubegrenset). Å krysse den myke terskelen registrerer en varselhendelse; å bruke opp budsjettet registrerer en hard hendelse og vipper agentens livssyklusstatus til paused i organisasjonskartet. Utsending godtar fortsatt arbeid fra den agenten. En BudgetThresholdCrossed-pipeline-utløser kan starte oppfølgingsarbeid fra den samme hendelsen.

Forsøksavstamning

Hver kjøringslogg kan bære forsøksavstamning — en foreldrekjørings-id, en forsøksteller og et sammendrag for videreføring. Kjøringstreet i samtalen viser forsøksnummeret når det ikke er null. Et «prøv på nytt» fra chatten er en ny utsending med en fersk kjøringslogg.

Beslektede konsepter

• Agentmodellen: hva adapteren kan og ikke kan håndheve
• Moduser: hvor verktøyflaten og fullføringskontrakten kommer fra
• Tillatelsesregler: effektklassepolicyen hvert bevoktede kall går gjennom
• Sandkasse og sikkerhet: hele historien om isolasjon
• Flerbruker: styring, overtakelse og autonomibryteren
• Domenehendelser: hva AgentRunCompleted setter i gang