Claude Code subagenter: En praktisk guide (2026)

En subagent er en andre Claude, lansert av hovedøkten din i Claude Code, som kjører en oppgave i sitt eget kontekstvindu og gir tilbake et resultat. Den deler ikke samtalehistorikken din. Den ser ikke filene du allerede har lest eller beslutningene du allerede har tatt. Den får en prompt, gjør jobben, og returnerer.

Den isolasjonen er hele funksjonen. Parallelliteten, spesialiseringen, de tilpassede verktøybegrensningene, alt sammen er nedstrøms fra ett faktum: en subagent brenner sitt eget kontekstvindu, og bare sluttsvaret kommer tilbake til ditt.

Vi kjører dusinvis av subagenter om dagen for å bygge SkillProof, mest for forskningsutspredning og uavhengige fikser på tvers av katalogens datafiler. Noe av det vi har lært, er genuint nyttig. Noe av det lærte vi ved å se en agent hevde seier over arbeid den aldri gjorde. Begge typene er i denne guiden.

Hva en subagent faktisk er

I Claude Code er hovedøkten en loop: les, tenk, handle, observer, gjenta, med hvert steg lagt til én voksende samtale. En subagent er en separat instans av den samme loopen, startet midt i økten, med sin egen historikk som starter tom bortsett fra prompten du gir den.

Når subagenten er ferdig, reiser ingenting av det mellomliggende arbeidet tilbake. Ikke filene den leste, ikke kommandoene den kjørte, ikke blindveiene den utforsket. Bare teksten den velger å returnere, lander i hovedkonteksten din. Hvis den leste 40 filer for å svare på spørsmålet ditt, betaler hovedøkten din for ingen av de 40 lesingene. Den betaler for én oppsummering.

Det er derfor subagenter beskrives som en måte å bevare kontekst på: ikke fordi arbeidet er gratis (det koster de samme tokensene et sted), men fordi kostnaden er karantenesatt i et vindu som kastes bort, ikke ett du drar med deg gjennom resten av økten.

Avveiningen følger direkte. En subagent som ikke vet hva du allerede har prøvd, kan gjenta dine egne blindveier, og den kan ikke stille et oppklarende spørsmål midt i oppgaven slik hovedloopen kan, den har enten nok i prompten til å fortsette eller den gjetter. Delegering kjøper isolasjon og koster delt hukommelse. Enhver god subagent-prompt er skrevet av noen som har internalisert den avveiningen.

Hvorfor kontekstisolasjon er poenget

Se for deg en hovedøkt to timer inn i en refaktorering: førti filer lest, et dusin verktøykall, en designbeslutning revidert to ganger. Den historikken gjør reelt arbeid, det er det som gjør neste redigering sammenhengende, men det er også femti tusen tokens ballast.

Nå trenger du å vite hvordan ett urelatert delsystem håndterer nye forsøk. Les de filene i hovedloopen, og hver eneste blir permanent bagasje, som rir med i konteksten resten av økten uansett om du bruker den igjen eller ikke, helt til den er en del av grunnen til at modellen begynner å miste tråden i selve refaktoreringen. En subagent lar deg stille spørsmålet, få svaret, og gå fra lesingen. De førti filene den leste, kommer aldri inn i vinduet ditt. Du får ett avsnitt tilbake.

Det er mekanismen bak enhver legitim subagent-seier i denne guiden: forskning, parallelle fikser, støyende utforskning. Alle sammen er egentlig det samme trekket, gjør den kostbare lesingen et sted engangs, hold hovedtråden ren.

Når subagenter slår å jobbe i hovedloopen

Forskning på tvers av mange filer. «Hvordan flyter autentisering gjennom denne kodebasen» berører ruter, mellomvare, øktlagring, og tre konfigfiler. Å svare på det i hovedloopen betyr at alt det lander i konteksten din permanent. En subagent leser de samme filene, returnerer en syntese, og råmaterialet forsvinner med den.

Parallelle uavhengige oppgaver. Fem komponenter trenger hver den samme prop-omdøpingen. Ingen avhenger av hverandre. Fem subagenter som kjører samtidig, blir ferdige på omtrent tiden én tar, uten delt tilstand å koordinere mellom endringene.

Støyende utforskning. Å grepe etter et mønster på tvers av et stort repo, prøve tre søkestrategier før én treffer, lese filer som viser seg irrelevante. Dette er akkurat det arbeidet du vil karantenesette. En subagent kan famle en stund, og bare den nyttige delen kommer tilbake.

Isolere en spesialisert persona. En kode-gjennomgangs-subagent som bare noensinne gjennomgår, med et smalere verktøysett og en prompt tunet for skepsis, oppfører seg mer konsistent enn å be hovedagenten din kontekstbytte til «vær nå kritisk til ditt eget arbeid» midt i økten.

Når subagenter er verre

Tette iterative løkker. Å feilsøke en mislykket test ved å endre én linje, kjøre på nytt, lese den nye feilen, endre en annen linje, trenger den fulle historikken av hva du allerede har prøvd. Å gi det til en fersk subagent for hver iterasjon betyr å forklare hele etterforskningen på nytt hver gang, tregere og verre enn å bli i hovedloopen. Dette er territoriet våre systematiske feilsøkingsnotater dekker: feilsøking vil ha kontinuitet, ikke delegering.

Oppgaver som trenger hele samtalen. Hvis brukeren brukte ti meldinger på å finpusse nøyaktig hva «rydd opp i dette API-et» betyr, vil en subagent som bare ser den siste instruksjonen, rydde det opp etter sin egen gjetning på «rydd opp», ikke den du forhandlet fram. Alt der kravene lever i samtalen snarere enn en prompt du kan gjenskape, er en dårlig match.

Enkle énfilsredigeringer. Å delegere «gi nytt navn til denne variabelen i denne filen» til en subagent legger til en rundtur, en fersk kontekstlasting, og et resultat du fortsatt må lese og stole på, for arbeid som ville tatt femten sekunder direkte. Å spinne opp en isolert arbeider lønner seg bare når arbeidet den skjermer deg fra, er genuint stort.

Mønsteret på tvers av alle tre: subagenter er verre nøyaktig når verdien av delt kontekst overgår kostnaden ved å bære den. Isolasjon slutter å være en funksjon i det øyeblikket kontinuitet er det oppgaven trengte.

Egendefinerte agentdefinisjoner

Claude Code laster egendefinerte subagenter fra markdown-filer under .claude/agents/ (prosjektnivå, delt gjennom git) eller ~/.claude/agents/ (personlig, hvert prosjekt). Hver fil er én agent: frontmatter pluss en systemprompt, samme form som en skill, men beskriver en persona i stedet for en prosedyre.

Her er et fullt, kommentert eksempel, en kode-gjennomgangsagent avgrenset til lese-bare gjennomgangsarbeid:

---
name: code-reviewer
description: Reviews a diff or pull request for correctness bugs,
  security issues, and missed edge cases. Use after a change is
  written and before it's committed, not while still drafting.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You are a senior engineer doing a pre-commit review. You did not
write this code and you have no attachment to it.

When given a diff or a set of changed files:

1. Read every changed file in full, not just the diff hunks.
   Bugs hide in the context around a change as often as in the
   change itself.
2. Check for: unhandled errors, off-by-one boundaries, null or
   undefined paths the type system doesn't catch, and any
   secret or credential that shouldn't be committed.
3. Do not comment on style or formatting unless it hides a bug.
   A linter's job is not your job.
4. For each finding, cite the file and line, and say what
   breaks and how you'd confirm it. If you're not sure something
   is a bug, say so explicitly instead of stating it as fact.
5. If you find nothing, say that plainly. Do not invent minor
   issues to look thorough.

Never run commands that modify files. You are reviewing, not fixing.

Noen ting betyr noe her. name er hvordan du kaller den (Use the code-reviewer agent to check this diff) eller hvordan Claude Code kaller den automatisk på en matchende oppgave. description-feltet bærer den samme vekten det gjør i en skill: spesifikke triggerbetingelser slår en vag oppsummering.

tools er en genuin sikkerhetsgrense, ikke et forslag. Å liste bare Read, Grep, Glob, Bash betyr at denne agenten fysisk ikke kan kalle Edit eller Write, selv om dens egen resonnering bestemte at en fiks var åpenbar. Det er bevisst: en gjennomgangsagent som også kan patche koden den gjennomgår, er én du ikke kan stole på til bare å gjennomgå. model lar deg rute en mekanisk, godt spesifisert agent til en billigere modell enn hovedøkten din, siden oppgaven ikke trenger hovedmodellens fulle vekt.

Kroppen er samme håndverk som en skill: negative begrensninger («ikke kommenter på stil», «ikke finn opp mindre problemer») gjør mer jobb enn positive, fordi de er det som stopper en gjennomgangsagent fra å polstre resultatet sitt for å se grundig ut.

Parallelle mønstre som faktisk fungerer

Utspredningslesinger. Lanser flere subagenter samtidig, hver tildelt en annen del av det samme spørsmålet: én leser autentiseringsmodulen, én datalaget, én testsuiten. Hver returnerer en kort syntese. Du får tre svar på tiden én sekvensiell gjennomgang ville tatt, og det rå filinnholdet berører aldri hovedkonteksten din.

N uavhengige fikser. En batch komponenter trenger den identiske mekaniske endringen, og ingen importerer fra hverandre. Lanser én subagent per komponent, hver med en selvstendig prompt: den eksakte endringen, den eksakte filen, den eksakte aksepttesten. Dette er det reneste parallelle tilfellet, ingen subagent trenger å vite hva en annen gjorde.

Begge mønstrene deler et krav som er lett å hoppe over og dyrt når du gjør det: hver prompt må være selvstendig. Den har ikke samtalen din. Hvis oppgaven avhenger av en beslutning tatt tre meldinger tidligere, må den beslutningen gjentas i prompten, ellers vil subagenten selvsikkert gjøre det gale.

Feilmoduser vi faktisk har truffet

Dette er delen de fleste guider hopper over, skrevet av noen som kjørte en subagent to ganger og det fungerte. Vi kjører dem daglig, og her er hva som går galt i praksis.

Agenter som rapporterer «ferdig» uten å ha gjort arbeidet. En subagent kommer tilbake med en ren, selvsikker oppsummering: «Oppdaterte de tre filene, testene består, klar til å committe.» Du sjekker, og én fil er urørt. Dette er ikke modellen som er uærlig i noen bevisst forstand, det er returoppsummeringen som driver bort fra hva som faktisk skjedde, spesielt på lengre oppgaver der agentens egen redegjørelse for sitt arbeid blir komprimert. Fiksen er kjedelig og ikke-forhandlingsbar: verifiser med artefakt, ikke rapport. Les diffen selv. Kjør testen selv. En subagents oppsummering er en påstand, ikke en kvittering.

Agenter som venter på fantomvarsler. Vi har hatt subagenter pause midt i oppgaven mens de forventer et tilbakekall eller et signal fra en annen prosess som aldri kom, fordi koordineringsmekanismen bare eksisterte i promptens fantasi, ikke i noe faktisk koblet opp. Fiksen er å aldri designe en subagent-prompt rundt en hendelse du ikke har verifisert utløses. Hvis en subagents neste steg avhenger av en annen agents resultat, gi den resultatet direkte når du lanserer den, ikke be den oppdage et fullføringssignal du ikke har bygget.

Begge feilene spores tilbake til den samme disiplinen: en prompt som ikke lener seg på delt kontekst eller et antatt varsel, er én en agent faktisk kan fullføre riktig, og et utfall du sjekker ved å lese filen, ikke ved å lese agentens redegjørelse for filen, er den eneste måten å vite at den gjorde det. Ingenting av dette er et argument mot subagenter. Det er et argument mot å stole på en tekstoppsummering på samme måte som du ville stolt på en diff. Vi kjører dem konstant. Vi slår bare ikke sammen noe på deres ord alene.

Skills fungerer inne i subagenter også

En subagent er fortsatt en Claude-instans, så den laster skills på samme måte som hovedøkten din gjør: matcher oppgaven sin mot installerte skill-beskrivelser og trekker inn kroppen ved trigger. En kode-gjennomgangs-subagent med vår code review checklist-skill installert, får den samme strukturerte gjennomgangen den ville fått i hovedloopen, avgrenset til hvilken diff du enn ga den.

Dette komponerer rent. Subagenten håndterer hvor arbeidet skjer, skillen håndterer hvordan det gjøres. Ingen av dem trenger å vite om den andre; de stables automatisk så lenge begge er installert der subagenten kan se dem, prosjektskills i .claude/skills/, personlige skills i ~/.claude/skills/. Vår side med beste kodeskills rangerer de verdt å installere før du kobler opp en gjennomgangs- eller forskningsagent.

Subagenter vs hooks vs skills

Tre forskjellige mekanismer, tre forskjellige jobber, og de blandes sammen konstant:

	Hva den gjør	Trigges på	Kjører hvor
Skill	Lærer Claude en prosedyre eller stil	Claude matcher forespørselen din mot en beskrivelse	Inne i gjeldende kontekst
Hook	Kjører en fast skallkommando automatisk	En livssyklushendelse (før et verktøykall, etter et svar, øktstart)	Utenfor modellen, deterministisk
Subagent	Delegerer en oppgave til en isolert Claude-instans	Et eksplisitt kall, av deg eller av hovedagenten	Et separat kontekstvindu

En skill endrer hvordan Claude nærmer seg noe den allerede skal gjøre. En hook håndhever noe hver gang, ubetinget, uten å be modellen huske: kjør tester etter hver redigering, blokker en commit hvis hemmeligheter oppdages. En subagent endrer hvor arbeidet skjer, og flytter det inn i et engangsvindu i stedet for ditt hoved. Vi dekker hooks i dybden, inkludert samme type arrvev som over, i vår Claude Code hooks-guide.

De stables. Et teamoppsett kan bruke en hook til å linte etter hver skriving, en skill til å lære husets kodestil, og en subagent til å kjøre hele gjennomgangen før sammenslåing, tre lag, ingen redundante. Setter du fortsatt sammen resten av oppsettet ditt, går vår 2026-oppsettguide gjennom hvor hver del hører hjemme, og vår tokenkostnadsguide dekker hva alle tre koster i hvile.

Ofte stilte spørsmål

Deler subagenter hovedøktens kontekst?

Nei, og det er hele poenget. En subagent starter med en tom historikk bortsett fra prompten du gir den. Ingenting fra hovedsamtalen din følger automatisk med, og ingenting subagenten leser eller gjør, følger tilbake bortsett fra den endelige teksten den returnerer. Trenger den bakgrunn fra samtalen din, legg den bakgrunnen i prompten.

Kan subagenter kjøre parallelt?

Ja. Å lansere flere samtidig er standardmønsteret for utspredningsforskning og for uavhengige, ikke-overlappende fikser. Hver får sitt eget kontekstvindu, så de forstyrrer ikke hverandre, men de kan heller ikke koordinere midt i oppgaven med mindre du eksplisitt har matet én sitt resultat inn i en annens prompt.

Hvordan vet jeg om en subagent faktisk gjorde det den hevdet?

Sjekk artefaktet, ikke oppsummeringen. Les diffen, kjør testen, åpne filen. Vi har hatt subagenter rapportere ren suksess på arbeid som var delvis gjort om igjen, ikke av uærlighet, men fordi en oppsummering er en rekonstruksjon, og rekonstruksjoner driver. Behandle hver subagent-rapport som en påstand å verifisere.

Hvor lever egendefinerte agentdefinisjoner?

.claude/agents/*.md for prosjektnivå-agenter som følger med repoet gjennom git, og ~/.claude/agents/*.md for personlige som er tilgjengelige på tvers av hvert prosjekt. Hver fil trenger name og description i frontmatteren som et minimum; tools og model er valgfrie, men verdt å sette bevisst i stedet for å la stå på standardverdiene sine.

Bør jeg begrense hvilke verktøy en subagent kan bruke?

Ja, når agenten har en smal jobb. En gjennomgangsagent som ikke kan kalle Edit, kan ikke ved et uhell patche det den skal kritisere. En lese-bare forskningsagent som ikke kan kalle Bash, kan ikke kjøre noe destruktivt ved et uhell mens den roter rundt. tools-feltet i en agents frontmatter er mekanismen, og å sette det er billigere enn å feilsøke hva en overdrevent mektig agent gjorde med tiden sin.