Agentmodellen

Hva er en agent?

En agent er en navngitt aktør med en persona, et sett med skills og en adapter å kjøre på. Agenter er aktører på samme måte som mennesker: de skriver meldinger, eier saker, legger igjen gjennomganger og vises på den samme oversikten. De er de tingene som gjør arbeid.

Hver agent tilhører nøyaktig ett arbeidsområde. Dette er en hard invariant — agent.workspaceId er ikke null, det er agentens eget arbeidsområde som bestemmer hvilken databasefil radene havner i, og å opprette en agent uten arbeidsområde avvises.

En agent er også en mappe. Definisjonen ligger i agents/<slug>/AGENTS.md under arbeidsområdets datamappe, med skillene den har, symlenket inn i agents/<slug>/.agents/skills. Databaseraden og filen skrives sammen. Opprettingen av startinnhold er idempotent: finnes agentraden allerede, skrives filene på disk og skill-lenkene likevel på nytt. Den som kaller dette i produksjon, er opprettelsen av arbeidsområdet, ikke hver serveroppstart.

Hva en agent rommer

Attributt	Hva den gjør
name	Kort slug-lignende identifikator (architect, qa). Også det @mentions løses mot
title	Lesbar stillingstittel
persona	Fritekst med personlighet og atferdsinstruksjoner, injisert som en promptseksjon
systemPrompt	Valgfrie tilleggsinstruksjoner, injisert som en «Agent instructions»-seksjon — de erstatter ikke resten av den sammensatte prompten
skills	Sett med skill-navn uten hensyn til store og små bokstaver, speilet som skill-lenker på disk
adapterId	Hvilken kjører agenten sender til. Null faller tilbake til den innebygde løkken
modelId	Hvilken modell innenfor den adapteren
effort	Resonneringsnivå, hentet fra den valgte modellens eget vokabular
contextSize	Overstyring av kontekstvinduet
silenceTimeoutMinutes	Overstyring per agent (1–240) for stillhetsvakten
reportsTo	Id-en til overordnet agent — rapporteringskjeden organisasjonskartet tegner opp

Du redigerer alt dette under Innstillinger → Arbeidsområde → Agenter. Ny agent oppretter en navnløs agent som du deretter fyller ut.

Skills

Skills er navn uten hensyn til store og små bokstaver på agententiteten. To forskjellige ting skjer med dem:

• Navnene listes opp i den sammensatte prompten under overskriften «Skills». Det er alt settet på entiteten gjør i seg selv — det finnes ikke noe promptbibliotek per skill som styres av det.
• Mappen til hver navngitte skill (skills/<slug>/SKILL.md i arbeidsområdet) lenkes inn i agentens egen mappe. På det innebygde harnesset lastes frontmatteren til de lenkede skillene automatisk inn i systemprompten, og agenten leser en brødtekst ved behov; å skrive /skill:<name> i en samtale laster den brødteksten som et direktiv for turen.

Skills som hentes fra utsiden, passerer en forsyningskjedeskanning som feiler lukket, mellom henting og skriving — ingen skill-innhold når disken eller en prompt uten en dom. Utsiden er GitHub-repositorier du registrerer selv som skill-kilder: det finnes ingen kuratert butikk, så repositoriets egne metadata (beskrivelsen, stjernene, skillens navn) er visningsdata uten tillit, og skanningsdommen er det eneste sikkerhetssignalet. En installasjon henter hele mappen til skillen, fester den til commiten den kom fra i skills-lock.json, og en senere oppdatering passerer porten på nytt før noe erstattes. Fremgangsmåten står i installer og administrer skills.

Repo-avgrensede skills

Et repo kan levere sine egne skills, på hvilken som helst av de vanlige plassene (.agents/skills/, .claude/skills/, .opencode/skills/). Et område sjekker ut hvert lenket repo side om side under repos/<name>/, men en agent jobber i ett repo om gangen — så den har bare det repositoriets skills, og de byttes ut når den flytter seg.

Hvilket repo som er aktivt, utledes fra filene agenten berører: å skrive en fil under repos/<name>/ gjør det til det aktive repositoriet, mens det å bare lese på tvers av repoer ikke gjør det, så det å følge et symbol inn i en søstertjeneste bytter aldri ut settet under en oppgave. I et område med ett repo er svaret kjent før første tur.

Avgrensningen er en beslutning om kontekstbudsjettet. Skill-indeksen ligger i prompten ved hver tur, mens brødtekstene ikke gjør det, så å liste opp alle repoers skills samtidig koster tokens kontinuerlig — og en testing-skill fra én tjeneste villeder aktivt når arbeidet er i en annen. Samme resonnement forklarer hvorfor indeksen til en agent har ett repo, mens komponisten ikke er avgrenset slik: å navngi en skill selv er én eksplisitt handling, så /skill:<repo>:<name> når hvilket som helst repo i området.

Repo-skills lastes for hver adapter, ikke bare det innebygde harnesset. Skillene til det aktive repositoriet materialiseres inn i agentens arbeidsmappe, som er stien Claude Code allerede skanner; den samme indeksen settes sammen i AGENTS.md som det innebygde harnesset leser. Skillene til et repo passerer den samme skanningen som feiler lukket, som en installert skill gjør, før noe av dette skjer — et utsjekket repo er klonet innhold, og frontmatteren når en prompt.

Tillatelser

En agent har ingen egne tillatelsesflagg. Om den får opprette en commit, pushe, åpne en pull request, skrive til et oppfølgingssystem eller nå nettverket, avgjøres av tillatelsesreglene for handlinger — tillat, spør først eller nekt, i omfanget arbeidsområde, agent eller område — og de samme reglene gjelder uansett hvilken adapter som kjører den.

Hva en kjøring blir tildelt, endres ikke av disse reglene. En kjøring i en GitHub-worktree får alltid et GitHub-token som bare kan lese, og en push blir spurt om i det øyeblikket den skjer: agentens git-konfigurasjon sender hver GitHub-push gjennom Control Center, som bruker regelen Push til en remote før den sendes videre.

Se Sandkasse og sikkerhet for hvordan det virker, inkludert hva som håndheves og ikke håndheves på filsystemnivå.

Adapteren avgjør hva som kan håndheves

Det desidert mest avgjørende feltet på en agent er adapteren, fordi adapterens transport bestemmer hvor mye av policyen til Control Center som faktisk kan håndheves.

Transport	Adaptere	Hva Control Center håndhever
Innebygd harness	Control Center (built-in)	Alt. Verktøyflaten er bygget fra modusen, så et forbudt verktøy er usynlig i stedet for bare avvist; hvert kall passerer godkjenningsporten og tillatelsesreglene for handlinger; fullføringskontrakten kan dytte på og deretter feile en kjøring som avsluttes uten leveransen sin
Claude CLI	Claude Code	mcp__*-verktøyene den får servert, pluss Bash-kommandoene dens, som en hook sender til handlingspolicyen før de kjører. Claudes egne lese-, skrive- og redigeringsverktøy lever i prosessen dens og kjører usett — og den startes med --dangerously-skip-permissions, fordi ikke-interaktiv claude -p ellers ville blokkere for alltid på sin egen prompt

Konkret: bare det innebygde harnesset støtter underagenter, styring midt i en kjøring, pause og gjenopptaking (og dermed overtaking) og strukturell modushåndhevelse. Claude Code får ingen av disse.

OS-sandkassen er et gulv, ikke en håndhever av modus, og ikke alle verter har én

Matrisen over handler om hva Control Center kan se og styre. Under den pakker cc_server inn Claude Code-CLI-en i vertens OS-sandkasse der en finnes — Seatbelt på macOS, bubblewrap på Linux og WSL2 — så en usett rm eller en usett skriving er fortsatt avgrenset av OS-et. På Windows finnes det ingen backend i det hele tatt, og på Linux eller WSL2 uten bwrap og socat rapporterer sonden ingen, så der faller slike kjøringer tilbake til sanering av miljøet, brokerlevert påloggingsinformasjon, tillatelsesreglene for kallene Control Center kan se, og samtalens egen worktree (copy-on-write der rift følger med; git worktree på Windows).

Det sandkassen ikke er, er en port. Den avgrenser hvor en prosess kan lese, skrive og koble til — en skrivebeskyttet modus kommer faktisk fram til den, i form av skrivebeskyttede bind-monteringer — men den kan ikke avskjære et kall, reise en godkjenning eller fortelle deg etterpå hva CLI-en forsøkte. Det, pluss de fire kapasitetene nevnt rett over, er fortsatt det det innebygde harnesset har og de andre ikke har. Se Sandkasse og sikkerhet.

En agent uten adapter faller tilbake til Control Center (built-in) — løkken inne i serveren, så det finnes ingen CLI å installere — og kjøringsloggen dens registrerer cc-harness. Hver standardopprettet agent opprettes uten adapter eller modell, så de fem agentene i et nytt arbeidsområde kjører alle der, på Anthropics standardmodell, til du setter en adapter og modell per agent. Onboarding-valget av standardadapter er en klientinnstilling serveren aldri leser, og den anvendes ikke i ettertid på agenter som allerede er opprettet.

Hvor agentene kommer fra

• Opprettes sammen med arbeidsområdet. Hvert arbeidsområde — ikke bare det første — får en CEO pluss fire spesialister (qa, architect, engineer, librarian) som rapporterer til den, opprettet idempotent i bakgrunnen når arbeidsområdet opprettes. Se Arbeidsområder og isolasjon.
• Legges til manuelt under Innstillinger → Arbeidsområde → Agenter. Å be en agent ansette en kollega oppretter ikke en rad; bruk det skjermbildet.

Sanntidstilstand

En agent har ingen lagret statuskolonne. Sanntidstilstanden utledes fra de nyeste kjøringsloggene hver gang den leses:

Tilstand	Betydning
neverRun	Ingen kjøringslogg finnes
running	Minst én kjøring pågår nå
failed	Den siste kjøringen feilet, eller livsstatusen er mislykket eller død
blocked	Livsstatusen til den siste kjøringen er blokkert, stanset eller i løkke
idle	Alt annet — agenten har kjørt før og har ingenting i gang

To andre tilstander, queued og succeeded, finnes for enkeltkjøringer i kjøringstreet til samtalen; oversikten produserer dem aldri, fordi en avsluttet kjøring er grønn, er et faktum om kjøringen, ikke om agenten.

Tilstedeværelsesoversikten viser et parallelt, grovere bilde som settes sammen på serversiden fra hendelser i sanntid fra kjøringer — tenker, kjører, blokkert på godkjenning, ferdig — og det er dette som gjør at agenter vises ved siden av mennesker. Se Flerbruker og tilstedeværelse.

Beslektede konsepter

• Livssyklus for agentutsending: hva som skjer når en agent faktisk kjøres
• Moduser: innstillingen per samtale som former verktøyflaten til en agent
• Flerbruker og tilstedeværelse: agenter som aktører, tilstedeværelse og autonomibryteren
• Sandkasse og sikkerhet: hva som begrenser en kjøring i dag
• Agentkonfigurasjon: den fullstendige feltlisten