Agentmodellen

Vad är en agent?

En agent är en namngiven aktör med en persona, en uppsättning skills och en adapter att köra på. Agenter är principaler i samma mening som människor är det: de författar meddelanden, äger ärenden, lämnar granskningar och syns i samma personallista. De är sakerna som utför arbete.

Varje agent tillhör exakt en arbetsyta. Detta är en hård invariant — agent.workspaceId är icke-null, agentens egen arbetsyta är det som avgör vilken databasfil dess rader hamnar i och att skapa en agent utan arbetsyta avvisas.

En agent är också en katalog. Dess definition ligger i agents/<slug>/AGENTS.md under arbetsytans datakatalog, med de skills den har symlänkade in i agents/<slug>/.agents/skills. Databasraden och filen skrivs tillsammans. Seeding är idempotent: om agentraden redan finns skrivs filerna på disk och skillänkarna fortfarande om. Anroparen i produktion är skapandet av arbetsytan, inte varje serverstart.

Vad en agent innehåller

Attribut	Vad det gör
name	Kort sluggliknande identifierare (architect, qa). Även det som @mentions matchas mot
title	Människoläsbar jobbtitel
persona	Fritext med personlighet och beteendeinstruktioner, injicerad som ett promptavsnitt
systemPrompt	Valfria extra instruktioner, injicerade som ett avsnitt “Agentinstruktioner” — de ersätter inte resten av den sammansatta prompten
skills	Skiftlägesokänslig uppsättning skillnamn, speglad som skillänkar på disk
adapterId	Vilken körare agenten skickar till. Null faller tillbaka på den inbyggda loopen
modelId	Vilken modell inom den adaptern
effort	Resonemangsnivå, hämtad från den valda modellens eget vokabulär
contextSize	Överstyrning av kontextfönstret
silenceTimeoutMinutes	Per-agent-överstyrning (1–240) för tystnadsövervakningen
reportsTo	Förälderagentens id — rapporteringskedjan som organisationsschemat ritar

Du redigerar alla dessa under Inställningar → Arbetsyta → Agenter. Ny agent skapar en namnlös agent som du sedan fyller i.

Skills

Skills är skiftlägesokänsliga namn på agententiteten. Två separata saker händer med dem:

• Namnen listas i den sammansatta prompten under en rubrik “Skills”. Det är allt entitetens uppsättning gör i sig — det finns inget promptbibliotek per skill som styrs av den.
• Varje namngiven skills katalog (skills/<slug>/SKILL.md i arbetsytan) länkas in i agentens egen mapp. På den inbyggda harnessen läses de länkade skillsens frontmatter automatiskt in i systemprompten och agenten läser en brödtext vid behov; att skriva /skill:<name> i ett samtal laddar den brödtexten som ett direktiv för turen.

Skills som hämtas utifrån passerar en fail-closed-scan av leveranskedjan mellan hämtning och skrivning — inget skillinnehåll når disken eller en prompt utan ett utfall. Det yttre är GitHub-repositorier som du själv registrerar som skillkällor: det finns ingen kurerad butik, så repositoriets egen metadata (dess beskrivning, dess stjärnor, skillens namn) är opålitlig visningsdata och scanresultatet är den enda säkerhetssignalen. En installation hämtar skillens hela katalog, fäster den vid den commit den kom från i skills-lock.json, och en senare uppdatering passerar grinden på nytt innan något ersätts. Guiden finns i installera och hantera skills.

Reposcopade skills

Ett repo kan leverera sina egna skills, på någon av de konventionella platserna (.agents/skills/, .claude/skills/, .opencode/skills/). En yta checkar ut varje länkat repo sida vid sida under repos/<name>/, men en agent arbetar i ett repo i taget — så den bär bara det repots skills, och de byts ut när den flyttar.

Vilket repo som är aktivt härleds från filerna agenten rör: att skriva en fil under repos/<name>/ gör det till det aktiva repot, medan ren läsning över repo-gränser inte gör det, så att följa en symbol in i en systertjänst byter aldrig ut uppsättningen mitt under en uppgift. På en yta med ett enda repo är svaret känt före första turen.

Avgränsningen är ett beslut om kontextbudget. Skillindexet ligger i prompten vid varje tur medan brödtexterna inte gör det, så att lista varje repos skills på en gång kostar tokens kontinuerligt — och en testing-skill från en tjänst vilseleder aktivt när arbetet är i en annan. Samma resonemang förklarar varför en agents index bär ett repo men skrivfältet inte är avgränsat på det sättet: att namnge en skill själv är en explicit handling, så /skill:<repo>:<name> når vilket repo som helst på ytan.

Repo-skills laddas för varje adapter, inte bara den inbyggda harnessen. Det aktiva repots skills materialiseras i agentens arbetskatalog, vilket är den sökväg Claude Code redan skannar; samma index komponeras in i den AGENTS.md som den inbyggda harnessen läser. Ett repos skills genomgår samma fail-closed-scan som en installerad skill innan något av detta sker — ett utcheckat repo är klonat innehåll, och dess frontmatter når en prompt.

Behörigheter

En agent bär inga egna behörighetsflaggor. Om den får skapa en commit, pusha, öppna en pull request, skriva till ett ärendesystem eller nå nätverket avgörs av åtgärdsräckena — tillåt, fråga först eller neka, i omfånget arbetsyta, agent eller yta — och samma regler gäller oavsett vilken adapter som kör den.

Vad en körning tilldelas ändras inte av de reglerna. En körning i en GitHub-worktree får alltid en GitHub-token som bara kan läsa, och en push frågas om i samma stund som den sker: agentens git-konfiguration skickar varje GitHub-push genom Control Center, som tillämpar regeln Pusha till en remote innan pushen skickas vidare.

Se Sandlåda och säkerhet för hur det fungerar, inklusive vad som framtvingas och inte framtvingas på filsystemsnivå.

Adaptern avgör vad som kan framtvingas

Det enskilt mest konsekvensrika fältet på en agent är dess adapter, eftersom adapterns transport avgör hur mycket av Control Centers policy som faktiskt kan framtvingas.

Transport	Adaptrar	Vad Control Center framtvingar
Inbyggd harness	Control Center (inbyggd)	Allt. Verktygsytan byggs från läget, så ett otillåtet verktyg är osynligt snarare än bara nekat; varje anrop passerar godkännandegrinden och åtgärdsräcken; slutförandekontraktet kan puffa och sedan underkänna en körning som avslutas utan sin leverans
Claude CLI	Claude Code	De mcp__*-verktyg den serveras, plus dess Bash-kommandon, som en hook skickar till åtgärdspolicyn innan de körs. Claudes egna läs-, skriv- och redigeringsverktyg lever i dess process och körs osedda — och den startas med --dangerously-skip-permissions, eftersom icke-interaktiv claude -p annars skulle blockera för evigt på sin egen prompt

Konkret: endast den inbyggda harnessen stöder subagenter, styrning under körning, pausa och återuppta (och därmed övertagande) samt strukturell lägestillämpning. Claude Code får inget av detta.

OS-sandlådan är ett golv, inte en lägestillämpare, och inte varje värd har en

Matrisen ovan handlar om vad Control Center kan se och grinda. Under den lindar cc_server in Claude Code-CLI:n i värdens OS-sandlåda där en sådan finns — Seatbelt på macOS, bubblewrap på Linux och WSL2 — så ett osynligt rm eller en osynlig skrivning begränsas fortfarande av OS:et. På Windows finns ingen backend alls och på Linux eller WSL2 utan bwrap och socat rapporterar sonden ingen, så där faller de körningarna tillbaka på miljösanering, förmedlade inloggningsuppgifter, räckena på de anrop Control Center kan se och samtalets egen worktree (copy-on-write där rift finns; git worktree på Windows).

Vad sandlådan inte är är en grind. Den begränsar var en process får läsa, skriva och ansluta — ett skrivskyddat läge når den verkligen, som skrivskyddade bind-monteringar — men den kan inte fånga upp ett anrop, resa ett godkännande eller i efterhand berätta vad CLI:n försökte göra. Det, plus de fyra förmågor som just nämndes, är fortfarande vad den inbyggda harnessen har och de andra inte. Se Sandlåda och säkerhet.

En agent utan adapter faller tillbaka på Control Center (inbyggd) — loopen inuti servern, så det finns ingen CLI att installera — och dess körningslogg registrerar cc-harness. Varje seedad agent skapas utan adapter och modell, så en ny arbetsytas fem agenter körs alla där, på Anthropics standardmodell, tills du anger en adapter och modell per agent. Onboardingens val av “standardadapter” är en klientinställning som servern aldrig läser och den tillämpas inte i efterhand på redan skapade agenter.

Var agenter kommer ifrån

• Seeds med arbetsytan. Varje arbetsyta — inte bara den första — får en VD plus fyra specialister (qa, architect, engineer, librarian) som rapporterar till den, skapade idempotent i bakgrunden när arbetsytan skapas. Se Arbetsytor och isolering.
• Läggs till manuellt under Inställningar → Arbetsyta → Agenter. Att be en agent anställa en kollega skapar ingen rad; använd den skärmen.

Live-tillstånd

En agent har ingen lagrad statuskolumn. Dess live-tillstånd härleds från dess senaste körningsloggar varje gång den läses:

Tillstånd	Betydelse
neverRun	Ingen körningslogg finns
running	Minst en körning pågår för närvarande
failed	Den senaste körningen misslyckades, eller dess livskraft är misslyckad eller död
blocked	Den senaste körningens livskraft är blockerad, stillastående eller loopande
idle	Allt annat — agenten har kört tidigare och har inget i luften

Ytterligare två tillstånd, queued och succeeded, finns för enskilda körningar i samtalets körningsträd; personallistan producerar dem aldrig, eftersom att en avslutad körning är grön är ett faktum om körningen, inte om agenten.

Närvarolistan visar en parallell, grövre bild som syntetiseras på serversidan från livedata om körningar — tänker, kör, blockerad på godkännande, klar — och det är vad som får agenter att synas bredvid människor. Se Multiplayer och närvaro.

Relaterade koncept

• Livscykel för agentdispatch: vad som händer när en agent faktiskt körs
• Lägen: inställningen per samtal som formar en agents verktygsyta
• Multiplayer och närvaro: agenter som principaler, närvaro och autonomireglaget
• Sandlåda och säkerhet: vad som begränsar en körning i dag
• Agentkonfiguration: den fullständiga fältlistan