Claude Code-underagenter: struktur, fem roller og orkestrering

Hva er en underagent i Claude Code, og hvorfor er den ikke «bare enda en Skill»?#

Claude Code-dokumentasjonen definerer den slik:

Sagt på en måte en entreprenør ville forstå: se for deg et eiendomsbyrå. Der er det en direktør, en markedsfører, en jurist og salgsledere. At én ansatt veksler mellom alle disse rollene, gjør dem ikke til et team; det gjør dem til en overbelastet person. Et team oppstår når hver person har sin egen kontekst og sitt ansvarsområde, mens direktøren bare fordeler oppgaver og samler resultatene.

Underagenter i Claude Code fungerer på samme måte. Hovedchatten er direktøren. En underagent er en spesialist med en avgrenset oppgave, sin egen kontekst og sitt eget sett med verktøy. Når en oppgave samsvarer med en spesialists beskrivelse, delegerer direktøren den – og setter seg ikke fast i detaljene.

5 mål Anthropic laget underagenter for

Anthropics dokumentasjon oppgir nøyaktig fem grunner til å lage din egen underagent:

Det mest praktiske punktet på denne listen for en som ikke programmerer, er kostnadskontroll. Du kan sende en omfattende researchoppgave til den rimelige Haiku-modellen og fortsette hovedsamtalen med Sonnet eller Opus. Tokenbesparelsene er direkte proporsjonale.

Kontroller nestingstøtte for installert versjon

Malene i denne veiledningen bruker én hovedøkt som delegerer direkte til arbeidere. Ikke behandle eldre dokumentasjon om at underagenter ikke kan starte andre underagenter som en tidløs regel. Nesting avhenger av installert versjon og tillatte verktøy. Den separate veiledningen om nestede underagenter omtaler en versjonsspesifikk oppskrift. Verifiser støtte i installasjonen før du planlegger dypere delegering.

Hvordan skiller en underagent seg fra en Skill, skråstrekkommando og hook?#

Den forrige veiledningen om Skills forklarer at Skills og skråstrekkommandoer i Claude Code i praksis er slått sammen til ett format. Men en underagent er en annen enhet – ikke bare «en større Skill».

En oversiktstabell over de fire mekanismene:

En god måte å si det på i en engelskspråklig veiledning: Skills er oppskrifter; underagenter er spesialiserte kolleger.

Put simply: skills are recipes; subagents are specialized colleagues.

I praksis fungerer det slik: Skills aktiveres automatisk når beskrivelsen deres samsvarer med oppgaven, mens underagenter kalles eksplisitt – enten bestemmer hovedchatten seg for å delegere, eller så kaller du en ved navn.

Beslutningstre: «Hvilken bør jeg velge?»

Når du tenker «Jeg trenger at Claude gjør X», kan du gå gjennom disse fire spørsmålene:

1. Er dette kunnskap som alltid bør være tilgjengelig? For eksempel «vi lokaliserer til språket brukeren foretrekker» eller «vi bruker ikke em-dash». Legg det i CLAUDE.md.
2. Er dette en metode som utløses av en hendelse, og som du utfører manuelt nå? For eksempel «jeg skriver en salgsrapport hver mandag». Lag en Skill.
3. Er dette en oppgave som vil bruke opp konteksten i hovedchatten, eller kan den kjøres parallelt? For eksempel «grundig research på tvers av 30 kilder» eller «en sikkerhetsrevisjon mens jeg skriver en ny funksjon». Lag en underagent.
4. Trenger du et automatisk svar på en hendelse i Claude Code? For eksempel «kjør linteren etter hver Edit». Skriv en hook.

90 % av oppgavene til en entreprenør faller inn under de to første kategoriene. Underagenter er et verktøy på neste nivå, for når du går fra «én oppgave om gangen» til orkestrering.

Hvor finnes underagenter, og hvilken har forrang?#

Hierarkiet for underagenter har fem nivåer, ordnet fra høyeste til laveste prioritet:

Prioritetslogikken er den samme som for Skills og CLAUDE.md: organisasjonen overstyrer CLI, CLI overstyrer prosjekt, prosjekt overstyrer personlig, og personlig overstyrer plugin.

Dette bør du vite om innlasting

Underagenter lastes inn når en Claude Code-økt starter. Hvis du redigerer en agentfil manuelt på disk, blir endringene ikke tatt i bruk før du starter økten på nytt. Endringer via det interaktive /agents-grensesnittet gjelder umiddelbart.

Én underagent per omfang betyr én fil. Hvis .claude/agents/ inneholder code-reviewer.md og en annen code-reviewer.md ved siden av den (for eksempel fra en gammel sikkerhetskopi), vil Claude Code ignorere den ene i det stille. Du får ingen varsling.

Underagenter fra plugins er noe annet. De har sikkerhetsbegrensninger: de støtter ikke feltene hooks, mcpServers og permissionMode. Dette hindrer installasjon av en tredjepartsplugin i å gi den tillatelse til å kjøre vilkårlig kode på maskinen din.

Slik er en underagentfil strukturert: frontmatter og brødtekst#

Et minimalt eksempel fra den offisielle dokumentasjonen – bare 9 linjer:

---
name: code-reviewer
description: Gjennomgår kode med tanke på kvalitet og beste praksis
tools: Read, Glob, Grep
model: sonnet
---

Du er en kodegjennomgår. Når du kalles, analyserer du koden og gir
spesifikke, handlingsrettede tilbakemeldinger om kvalitet, sikkerhet og beste praksis.

Det er nok. Hvis en bruker sier «se gjennom PR-en min» i hovedchatten, kobler Claude «gjennomgår / kode / kvalitet» til beskrivelsen og delegerer til underagenten. Underagenten leser diffen, skriver kommentarer og returnerer et sammendrag til hovedchatten. Hovedchatten fylles ikke opp med logger og mellomliggende analyser.

Fullstendig frontmatter-skjema

Feltet model: haiku er nettopp denne «kostnadskontrollen» fra listen over fem mål. Hvis du har en researchagent som leser 50 sider dokumentasjon, kan du kjøre den på Haiku for å spare 5–7 ganger sammenlignet med Opus.

Feltet isolation: worktree løser et viktig problem: En underagent gjør potensielt farlige endringer (refaktorering, migrering), men du vil ikke at den skal berøre arbeidskopien din. Sett isolation: worktree, så oppretter Claude Code en midlertidig git-kopi av prosjektet; underagenten jobber der og returnerer en diff som kan gjennomgås.

Filens brødtekst er systemprompten

Etter frontmatter kommer vanlig Markdown – altså underagentens systemprompt. Det kreves ingen spesiell struktur, men dette er et utprøvd mønster:

1. Hvem du er – én setning: «du er en kodegjennomgår», «du er en sikkerhetsrevisor», «du er en dokumentasjonsansvarlig».
2. Når du kalles, og hva du gjør først – de første 2–3 handlingene etter at du har fått oppgaven.
3. En sjekkliste med kontroller eller steg – 5–10 punkter underagenten følger.
4. Hva du returnerer – formatet på sluttrapporten. Dette er avgjørende: Hvis du ikke spesifiserer et format, vil underagenten skrive en «stil» i stedet for et strukturert sammendrag.
5. Hva du IKKE gjør – eksplisitte begrensninger. Uten denne delen begynner underagenten å improvisere.

Hold filens brødtekst på 200–500 linjer. Hvis den blir lengre, kan du flytte omfattende referanser til egne nærliggende filer og lenke til dem i prompten.

Slik skriver du en beskrivelse som gjør at Claude definitivt kaller underagenten din#

A common pain point is setting up a subagent for code review, only to see Claude do everything itself without using the agent. Det er som regel én grunn: Beskrivelsen er skrevet som «Hjelper med kodegjennomgang». Claude forstår ikke når den skal utløse den.

Formel for en effektiv beskrivelse (3 deler)

Del 1 – hva den gjør. Én setning om resultatet, ikke prosessen. Ikke «analyserer kode», men «finner sårbarheter i kode og returnerer en liste med alvorlighetsgrad og en løsning».

Del 2 – når den skal utløses. 3–5 fraser i anførselstegn, slik brukere faktisk formulerer forespørsler. Ikke gjett – se på chatloggen din og den faktiske ordlyden.

Del 3 – når den IKKE skal utløses. 1–2 fraser om lignende oppgaver som denne underagenten ikke skal svare på. Uten denne delen kommer to lignende agenter stadig i konflikt.

Tryllefrasen «Bruk proaktivt»

Anthropics offisielle dokumentasjon gir en direkte anbefaling:

Med andre ord er Claude tilbøyelig til ikke å kalle en underagent som standard hvis beskrivelsen ikke inneholder tydelige signaler. Legg til «bruk proaktivt» eller «bruk umiddelbart etter at du har skrevet kode», så øker aktiveringen kraftig.

En god beskrivelse ser slik ut

description: |
  Ekspert på kodegjennomgang. Gjennomgår kode proaktivt med tanke på kvalitet,
  sikkerhet og vedlikeholdbarhet. Bruk umiddelbart etter at du har skrevet eller
  endret kode. Returnerer en prioritert liste over problemer med alvorlighetsgrad
  og anbefalte løsninger.
  Ikke kall den for dokumentasjonsendringer, README-redigeringer eller omskrivinger av
  commit-meldinger – disse håndteres av doc-maintainer.

Dette fungerer:

• Verbene «gjennomgår» + «returnerer» spesifiserer et konkret resultat, ikke en prosess.
• «Proaktivt» og «umiddelbart etter» er eksplisitte utløserfraser.
• «Ikke kall den for ...» avgrenser konflikter med en lignende underagent.
• Engelsk i beskrivelsen er standard. Claude matcher bedre på engelsk.

5 underagentroller klare til bruk på 10 minutter#

Hver rolle nedenfor er én fil, .claude/agents/<name>.md. Når du har opprettet filen, starter du Claude Code på nytt, åpner /agents og sjekker at den nye agenten vises i listen. Deretter kan du kalle den med @agent-name.

1. code-reviewer – gjennomgå kode etter hver endring

Dette er det offisielle eksemplet fra Anthropics dokumentasjon, tilpasset en arbeidsprosess:

---
name: code-reviewer
description: |
  Ekspert på kodegjennomgang. Gjennomgår kode proaktivt med tanke på kvalitet,
  sikkerhet og vedlikeholdbarhet. Bruk umiddelbart etter at du har skrevet eller
  endret kode.
tools: Read, Grep, Glob
model: inherit
color: blue
---

Du er en erfaren kodegjennomgår som sørger for høy standard på kodekvalitet.

Når du kalles:
1. Les diff og liste over endrede filer som hovedøkten har levert. Be hovedøkten sende dem hvis de mangler.
2. Bruk Read, Grep og Glob til å undersøke relevante filer.
3. Returner funn uten å endre filer eller kjøre shell-kommandoer.

Sjekkliste for gjennomgang:
- Koden er tydelig og lettlest
- Funksjoner og variabler har gode navn
- Ingen duplisert kode
- Riktig feilhåndtering
- Ingen eksponerte hemmeligheter eller API-nøkler
- Inndatavalidering er implementert
- Testdekningen er tilstrekkelig
- Ytelseshensyn er ivaretatt

Gi tilbakemeldinger organisert etter prioritet:
- Kritiske problemer (må løses før sammenslåing)
- Advarsler (bør løses)
- Forslag (vurder å forbedre)

Format: for hvert problem – fil:linje + én setning om hvorfor det er et problem + konkret løsning.

Nøkkelen er tools: Read, Grep, Glob: Gjennomgåeren har fil- og søkeverktøy uten Bash, Write eller Edit. Hovedøkten klargjør diffen og sender den videre. En instruksjon om bare å kjøre git diff begrenser ikke et fullt tildelt Bash-verktøy.

2. security-auditor – finn sårbarheter og lekkasjer

Rollen bruker opus til grundigere resonnering og samme begrensning til Read, Grep og Glob. Varig minne utelates fra denne skrivebeskyttede malen fordi agentminne også gir evne til å skrive minnefiler:

---
name: security-auditor
description: |
  Spesialist på sikkerhetsrevisjon. Bruk proaktivt til å finne sårbarheter fra OWASP Top 10,
  eksponerte hemmeligheter, injeksjonsrisikoer og svak autentisering.
  Kjør før enhver utrulling eller sammenslåing til main.
tools: Read, Grep, Glob
model: opus
color: red
---

Du er en sikkerhetsrevisor. Finn sårbarheter som kan utnyttes, ikke stilproblemer.

Sjekkliste for revisjon:
- SQL- / NoSQL-injeksjon
- XSS (lagret, reflektert, DOM-basert)
- Risiko for CSRF / SSRF
- Hardkodede hemmeligheter (API-nøkler, tokener, passord)
- Svak autentisering / økthåndtering
- Usikker deserialisering
- Manglende inndatavalidering
- Path traversal
- Åpne videresendinger
- Usikre direkte objektreferanser (IDOR)

For hvert funn:
- Alvorlighetsgrad: Critical / High / Medium / Low
- Fil:linje
- Angrepsscenario i 1–2 setninger
- Anbefalt løsning med kodeeksempel

Hopp over støy fra linter eller stil. Rapporter bare sårbarheter som kan utnyttes.

Skrivebeskyttet med tanke på verktøy, med model: opus for komplekse kontroller som sårbarhetskjeder.

3. research-agent – grundig research på tvers av 8+ kilder

Dette mønsteret er beskrevet av Anthropic selv i artikkelen deres om multiagent-researchsystemet. Nøkkelen er et eksplisitt utdataformat og et forbud mot å dumpe råresultater:

---
name: research-agent
description: |
  Spesialist på grundig research på nettet. Bruk proaktivt til faktainnhenting,
  konkurrentanalyse, innhenting av ekstern dokumentasjon og sammenligning av
  tilnærminger på tvers av flere kilder.
tools: WebFetch, WebSearch, Read, Write
model: sonnet
maxTurns: 30
color: purple
---

Du er en researchanalytiker. Målet er et syntetisert notat, ikke rå søkeresultater.

Prosess:
1. Del spørsmålet inn i 3–5 delspørsmål
2. Bruk WebSearch for hvert delspørsmål, og hent de 3–5 beste kildene per spørsmål
3. Kryssjekk påstander mot minst 2 uavhengige kilder
4. Avvis SEO-farmer og aggregatorinnhold; foretrekk primærkilder
5. Siter ordrett med URL-attribusjon for enhver konkret påstand
6. Returner: TL;DR (3 punkter) + Funn + Kilder (minst 8 domener)

Anti-mønstre du bør unngå:
- Ikke vis til et faktum fra én enkelt kilde
- Ikke parafraser sitater som om de var ordrette
- Ikke returner rå søkeresultater som dump til den overordnede agenten
- Ikke ta med tom innledning / avslutning («Håper dette hjelper»)

maxTurns: 30 er en beskyttelse mot at researchen går inn i endeløse iterasjoner. Anthropic rapporterer dette tallet i multiagentsystemet sitt:

Nitti prosent gjelder researchoppgaver på benchmarker. I praksis er forbedringen mindre for forretningsoppgaver, men den generelle størrelsesordenen er tilsvarende.

4. doc-maintainer – hold dokumentasjonen synkronisert med koden

Denne rollen bruker model: haiku – et typisk eksempel på «kostnadskontroll». Dokumentasjon krever ikke Opus; Haiku gjør jobben for en tredel av prisen:

---
name: doc-maintainer
description: |
  Spesialist på synkronisering av dokumentasjon. Bruk etter sammenslåing av funksjoner for å oppdatere
  README, API-dokumentasjon og CHANGELOG. Leser nylige commits, finner
  udokumenterte endringer og oppdaterer dokumentasjonen proaktivt.
tools: Read, Write, Edit, Glob, Grep, Bash
model: haiku
memory: project
color: green
---

Du holder dokumentasjonen synkronisert med koden.

Når du kalles:
1. Kjør `git log --since="last release"` for å se nylige endringer
2. Les README.md, docs/ og CHANGELOG.md
3. Finn mangler: nye funksjoner uten dokumentasjon, fjernede API-er som fortsatt
   er dokumentert, versjonsavvik

Utdata:
- Oppdaterte filer (bruk Edit, ikke Write – bevar den eksisterende strukturen)
- Oppføring i CHANGELOG.md i Keep-A-Changelog-format
- Liste over endringer du har gjort (faktisk diff-sammendrag, ikke parafrase)

Stilregler:
- Aktiv form, presens
- Kodeeksempler skal kunne kopieres og limes inn
- Ingen markedsføringsspråk («kraftig», «robust», «sømløs»)
- Ingen fyll («Denne veiledningen hjelper deg ...»)

5. refactor-agent – trygg refaktorering gjennom et worktree

Denne rollen bruker isolation: worktree – underagenten arbeider i en separat kopi av repositoriet, og du fletter bare inn hvis det går bra:

---
name: refactor-agent
description: |
  Spesialist på trygg refaktorering. Brukes til omdøping, uttrekk og innfletting som
  ikke bør påvirke arbeidskopien din før de er gjennomgått. Kjøres i et
  midlertidig git-worktree.
tools: Read, Edit, Write, Bash, Grep, Glob
model: sonnet
isolation: worktree
permissionMode: acceptEdits
color: yellow
---

Du refaktorerer kode uten å endre atferd.

Strenge regler:
1. Tester må bestå FØR og ETTER refaktoreringen.
   Hvis tester feiler før refaktoreringen, STOPP og rapporter.
2. Én atomær refaktorering per commit (trekk ut, gi nytt navn, flett inn).
3. Endre aldri offentlige API-er uten uttrykkelig instruksjon.
4. Endre aldri tester med mindre de tester implementeringen som refaktoreres direkte.

Prosess:
- Kjør testpakken -> grunnlinje
- Gjør én atomær refaktorering
- Kjør testpakken -> verifiser
- Commit med konvensjonell melding: refactor(scope): what

Returner: sammendrag av endringer + worktree-bane, slik at brukeren kan sammenligne og flette inn.

Med denne rollen forsvinner det mest frustrerende refaktoreringsproblemet – «jeg ødela noe og vet ikke hvordan jeg ruller tilbake»: Den opprinnelige kopien forblir urørt, og underagenten jobber i en isolert worktree.

Vil du ikke bare kopiere ferdige underagenter, men sette sammen en kombinasjon som gjør Claude til et stabilt verktøy? Underagenter er en del av din AI-klone: en måte å gi Claude et spesialisert team som arbeider etter din logikk. Metodikkens tre søyler er: AI-klone (Skills + underagenter) + Second Brain + konteksteknikk. Denne kombinasjonen gjør Claude til et verktøy som tenker etter din logikk, i stedet for en assistent som gjetter.

Start 5 underagenter parallelt: orkestrator + arbeidere#

Parallell orkestrering er et oppsett med «dirigent + orkester». Dirigenten holder planen, skriver ikke notene og kontrollerer det musikerne spiller. Hvis noen spiller en feil tone, ber dirigenten dem spille på nytt i stedet for å prøve å fullføre i deres sted.

For en entreprenør er en nærmere sammenligning et markedsføringsbyrå som utarbeider en strategi for en ny kunde. Én analytiker gjør en SWOT-analyse, en annen analyserer konkurrenter, en tredje lager en målgruppeprofil, en senioranalytiker luker ut hypoteser som ikke passer budsjettet, og prosjektlederen setter sammen den endelige presentasjonen. I Claude Code starter denne prosessen med én setning – og kritikeren er en integrert del av prosessen i stedet for å komme inn i etterkant.

Minimal orkestreringsprompt

Én setning i hovedchatten er nok:

Start fem underagenter parallelt: tre research-agenter på ulike kilder
(Anthropic-dokumentasjon, GitHub-repoer, AI-bloggere), én critic-agent som luker ut
svake konklusjoner, og én summary-agent for sluttdokumentet.

Kontekst: Jeg skriver en veiledning om X. Mållengde: 2,000 ord med kilder.
Før de starter, skal alle lese CLAUDE.md.

Claude delegerer deretter til de fem agentene. Hver arbeider i sin egen kontekst: research-agentene bruker hver sine kilder, kritikeren luker ut, og oppsummeringsagenten setter sammen resultatene. Bare endelige sammendrag returneres til hovedchatten.

Når lønner parallellisering seg?

Ikke alltid. Parallell kjøring gir bare mening når:

1. Oppgavene er uavhengige. Hvis research-agent #2 venter på resultatet fra research-agent #1, blir det ingen parallellitet – arbeidet foregår i praksis sekvensielt.
2. Oppgavene tar lang tid. Det er meningsløst å parallellisere «fjern etterfølgende mellomrom»; tidsbruken på å starte underagenter vil spise opp gevinsten.
3. Du har tilstrekkelige grenser. Mer om dette i en egen del nedenfor – parallelle underagenter bruker opp tokener raskt.

Anthropics Multi-Agent v2: et steg videre

I mai 2026 lanserte Anthropic Multi-Agent Orchestration v2 med tre viktige forskjeller fra den klassiske tilnærmingen med å starte parallelle underagenter. Mer om dette i neste del.

Nytt i Multi-Agent v2: orkestrering, Outcomes, Dreaming#

Multi-Agent Orchestration: delt filsystem + innsjekking underveis

Anthropic beskriver funksjonen slik:

Den viktigste forskjellen fra klassiske underagenter er et delt filsystem. Før arbeidet hver underagent helt isolert, og utvekslingen skjedde bare gjennom sammendraget som ble returnert. Nå kan spesialister skrive til en delt mappe, og hovedagenten leser resultatene etter hvert som arbeidet skrider fram, ikke bare til slutt. Dette løser problemet med «alle jobbet hele dagen, og til slutt viste det seg at to personer hadde tilnærminger som ikke lot seg forene».

Den andre forskjellen er innsjekking underveis. Hovedagenten kan sette arbeidet på pause og spørre en hvilken som helst spesialist «hvordan går det?», og deretter justere den overordnede planen. Dette ligner på hvordan en ekte teamleder arbeider.

Outcomes: en rubrikk i stedet for trinnvise instruksjoner

Med Outcomes skriver du suksesskriterier, og agenten finner en måte å oppfylle dem på. En separat graderingsagent kontrollerer resultatet i sin egen kontekst, slik at det ikke blir «forurenset» av hovedagentens resonnement.

Ti prosent på utfordrende oppgaver er en betydelig forbedring. Særlig når oppgaven formuleres som «sett sammen en lang artikkel som oppfyller disse kvalitetskriteriene» i stedet for «følg trinn 1–7».

Dreaming: agenter samler erfaring mellom økter

Dette er den mest konseptuelt nye funksjonen. En agent går gjennom tidligere økter, finner mønstre i suksesser og feil og oppdaterer minnelageret. Du kan konfigurere en manuell gjennomgang før endringene tas i bruk, eller la agenten redigere minnet selv.

Anthropic rapporterer at Harvey (et selskap innen juridisk teknologi) så omtrent en seksdobling i suksess på oppgaver innen juridisk utforming etter at de implementerte Dreaming. Dette fungerer allerede i produksjon, det er ikke bare en demo.

Hva dette betyr for entreprenører som ikke programmerer

Multi-Agent Orchestration er for øyeblikket tilgjengelig gjennom Claude Agent SDK, ikke direkte i Claude Code CLI. Men retningen er tydelig: Orkestreringen går fra «du starter N underagenter manuelt» til «du beskriver oppgaven, og hovedagenten bestemmer hvem den skal delegere til, og hvordan». Hvis du nettopp har begynt med underagenter, trenger du ikke bekymre deg for v2 ennå. Lær deg det klassiske mønsteret «1 hovedchat + 3–5 underagenter med ulike roller», så kan du naturlig gå over til Managed Agents om 3–6 måneder.

7 feil som gjør at underagenter ikke kommer av flekken#

Feil 1. Beskrivelser som «Hjelper med X» utløser ingenting

Symptom: Du skrev en underagent, kontrollerte strukturen, og alt er gyldig, men Claude kaller den ikke for brukerforespørsler. Grunnen er nesten alltid den samme: Beskrivelsen er abstrakt, for eksempel «Hjelper med kodegjennomgang». Løsningen: Skriv 3–5 faktiske brukerfraser i anførselstegn direkte inn i beskrivelsen, pluss «bruk proaktivt» / «bruk umiddelbart etter».

Feil 2. Lage en underagent når det trengs en Skill

En underagent koster mer enn en Skill – den oppretter sin egen kontekst, laster inn sin egen systemprompt og bruker flere tokener. Hvis en oppgave er kort, ikke bruker opp hovedkonteksten og kan løses i ett forsøk, bør den håndteres av en Skill, ikke en underagent. Et eksempel på et ant mønster: en format-validator-underagent som kontrollerer et JSON-skjema mot 20 regler. Dette bør være en Skill: én modell, ikke behov for isolasjon, ingen ekstra kontekst å laste inn.

Feil 3. Starte «60 parallelle agenter» fra begynnelsen

Dette er den mest utbredte illusjonen. Du ser en tweet som sier «jeg har 1,500 agenter i arbeid», og tenker «det burde jeg også gjøre». I praksis bruker 60 agenter opp grensene på et Pro-abonnement på en time, produserer en haug med motstridende resultater, og til slutt har du ingenting ferdig.

En praktiker på Medium sier det slik:

Løsningen: Start med én underagent for én oppgave. Når du har lært deg det, kan du legge til en nummer to med en annen rolle. Når du har lært deg å orkestrere to, kan du gå videre til et team på 3–5. Å gå fra «installerte Claude Code i går» til «20 parallelt i dag» vil garantert ødelegge kode og bruke opp grensene.

Feil 4. Gi alle agenter alle verktøy

Hvis kodegjennomgåeren din har tilgang til Bash, Write og WebFetch, er det et stort sikkerhetshull og en stor kostnadsrisiko. En gjennomgår bør ikke ha tillatelse til å skrive filer, langt mindre tilgang til internett.

Løsningen: Begrens tools strengt. En kodegjennomgår får bare Read, Grep, Glob. En sikkerhetsrevisor får samme lese- og søkeverktøy og en diff levert av hovedøkten. Bash gir shell-tilgang; det begrenser ikke automatisk agenten til git diff. En researchagent får WebFetch, WebSearch, Read, Write. Ikke gi en underagent flere tillatelser enn den trenger til én bestemt oppgave.

Feil 5. En underagent dumper råresultater inn i hovedkonteksten

Hvis en researchagent returnerer «her er alle de 30 sidene jeg fant; finn ut av resten selv» til hovedchatten, har du mistet den største fordelen med underagenter: isolering fra støy. Løsningen: Krev eksplisitt et utdataformat i underagentens systemprompt. «Returner BARE: TL;DR med 3 punkter + liste med 5 kilder. INGEN kodedumper, INGEN rå søkeresultater.» Formatet bør være strengt – underagenten skal ikke kunne velge å «gjøre det om til en stil».

Feil 6. Vage forespørsler: uklare delegeringsbestillinger

En underagent kan ikke se historikken i hoveddialogen. Den begynner med en ren kontekst + CLAUDE.md + det du uttrykkelig har skrevet til den. Hvis du skriver «fiks autentisering», vil underagenten dikte opp detaljer. Skriv heller: «Fiks OAuth-viderekoblingsløkken der brukeren etter vellykket innlogging sendes videre til /login i stedet for /dashboard. Fil: src/lib/auth.ts.»

En tydelig regel: Når du delegerer, bør du gi underagenten like mye kontekst som du ville gitt en ny konsulent som nettopp har begynt i prosjektet.

Feil 7. Rollebaserte agenter i stedet for oppgavebaserte agenter

Et fristende mønster er: «La oss lage en frontend-utvikler, backend-utvikler og QA-ingeniør og la dem jobbe som et team.» Det fungerer ikke. Hver «rolle» mister konteksten for hele prosjektet, og agentene kan ikke bli enige om detaljer fordi de ikke kan se hverandre.

Løsningen: En underagent bør håndtere en tilbakevendende oppgave med et tydelig resultat, ikke en rolle. Ikke «frontend-developer», men «explore-ui-tree», «refactor-component», «audit-accessibility». Hver oppgavebaserte underagent gjør én spesifikk jobb og returnerer ett spesifikt resultat.

Hvor mye koster parallelle underagenter, og når lønner de seg?#

Et Pro-abonnement blir brukt opp i løpet av en time hvis du starter 5 parallelle underagenter på komplekse oppgaver. Max 5x ($100) er et realistisk minimum for regelmessig parallell jobbing. For team og Enterprise håndteres pengespørsmålet allerede på nivået for verktøybudsjettet.

Hvis du vil lese mer om å spare tokener i Claude Code, kan du se den separate veiledningen om grenser. For underagenter gjelder hovedregelen at de lønner seg på oppgaver som krever minst 10 minutter med fokusert arbeid. Hvis en oppgave er kortere, bør du ikke opprette en underagent; gjør den i hovedchatten eller med en Skill.

Hvordan integrerer du underagenter i AI-klonen og Second Brain?#

En underagent bygger på tre ting som bør finnes i prosjektet før du oppretter din første spesialist:

1. Riktig CLAUDE.md. En underagent leser CLAUDE.md før den starter – det er dens «arbeidsavtale». Uten den kjenner ikke underagenten prosjektkonteksten, begrensningene eller tonen. Den vil finne på ting.

2. Grunnleggende Skills. En Skill er en innpakket metode. En underagent laster bare inn Skills den trenger, ikke alt på én gang. Uten Skills gjentar en underagent det samme arbeidet fra bunnen av hver gang.

3. Second Brain: en kunnskapsstruktur. Mappen business/ (eller tilsvarende på ditt fagområde) er et bibliotek som alle underagentene bruker. Uten den gir en underagent et gjennomsnittlig ChatGPT-svar som ikke skiller seg fra alle andres.

Å snu på denne rekkefølgen gir hype uten resultater. «Jeg har 60 parallelle underagenter» med en tom business/-mappe betyr 60 gjennomsnittlige ChatGPT-økter med samme tilnærming.

Den komplette kombinasjonen – AI-klone + Second Brain + kontekstkonstruksjon – er de tre søylene som gjør Claude konsistent. Underagenter er en del av AI-klonen: en måte å gi Claude et spesialisert team som arbeider etter din logikk.

Den raskeste måten å komme i gang på er å kopiere code-reviewer fra det første eksemplet ovenfor til .claude/agents/code-reviewer.md, starte Claude Code på nytt og kalle @agent-code-reviewer ved neste commit. På 5 minutter vet du om du trenger underagenter, eller om hovedchatten er nok.