# Slik delegerer du en stor oppgave i Claude Code med nestede subagenter
> I v2.1.172 gjorde Anthropic det mulig for Claude Code-subagenter å starte egne subagenter opptil 5 nivåer dypt. Slik delegerer du en stor oppgave.
Source: https://ailoot.ai/blog/nb/claude-code-nested-subagents/
Canonical: https://ailoot.ai/blog/nb/claude-code-nested-subagents/
Language: nb
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-232
Revision: sha256-ae514eb6caaa47cb117769bb9129620ad5c49386b32e0e8586e5afc3a84583e6
[Ailoot-dokumentasjon](https://ailoot.ai/docs/) — referansemateriale om bruk av tjenesten.
## Hva endret seg i Claude Code v2.1.172?
Hovedpoeng
Anthropic lanserte v2.1.172 og fjernet en to år gammel regel med én linje i endringsloggen. Subagenter kan nå starte sine egne subagenter, opptil 5 nivåer dypt. Denne funksjonen handler ikke om hastighet eller mer CPU. Hovedideen er å holde støyende forarbeid ute av hovedkonteksten din.
Hvis du har lest noe om AI-agenter i Claude Code de siste månedene, har du støtt på den samme formuleringen. Den står i den offisielle dokumentasjonen, i guiden min [om subagenter](https://ailoot.ai/blog/nb/claude-code-subagents/) og i analysene til alle konkurrentene. Den lyder slik: «En subagent kan ikke starte en annen subagent.» Per 11. juni 2026 står den setningen fortsatt tre forskjellige steder på `code.claude.com/docs/en/sub-agents`. Anthropic har rett og slett ikke oppdatert den ennå.
10. juni kl. 20:44 UTC dukket Claude Code v2.1.172 opp på GitHub Releases. Hovedpunktet i endringsloggen var én linje:
Subagenter kan nå starte sine egne subagenter, opptil 5 nivåer dypt.
— Claude Code Changelog, https://github.com/anthropics/claude-code/releases/tag/v2.1.172
Denne samme utgivelsen rettet også en feil som bare kunne oppstå ved nesting: En bakgrunnssubagent ble fortsatt markert som aktiv i agentpanelet etter at den nestede subagenten den hadde startet, allerede var stoppet.
Dette er et sjeldent tilfelle der den offisielle dokumentasjonen fortsatt motsier den utgitte versjonen. Videre forklarer jeg hvordan nesting skiller seg fra parallelle subagenter, hva «dybde 5» betyr, og de tre scenarioene der dette faktisk er nyttig i dag.
## Hvordan skiller nestede subagenter seg fra parallelle og sekvensielle?
Hovedpoeng
Hvis du er forvirret, er du ikke alene. Parallellisering, kjeding og nesting er tre uavhengige topologier. Parallellisering handler om hastighet, kjeding om å fastsette rekkefølgen på utførelsen, og nesting om noe helt annet: å holde støyende arbeid ute av hovedvinduet. Hvis du blander dem sammen, bruker du opp tokens på et par timer og klarer deretter ikke å finne hvor feilen ligger.
Jeg brukte lang tid på å prøve disse tre tilnærmingene selv, og slik ser jeg det: Delegering har tre dimensjoner. Bredde, lengde og dybde. Hver av dem løser et eget problem.
**Bredde — parallelle subagenter.** Hovedchatten starter N uavhengige subagenter på samme nivå. Hver får en avgrenset oppgave, jobber i sitt eget isolerte vindu og returnerer bare resultatet. Bredde gir hastighet: 5 subagenter som jobber parallelt, blir ferdige på den tiden én bruker på å gjøre den samme jobben sekvensielt. Dette er modellen jeg tok for meg i guiden min [om parallelle subagenter med worktrees](https://ailoot.ai/blog/nb/claude-code-parallel-worktree-agents/).
**Lengde — en kjede av subagenter.** A jobber og gir resultatet videre til B, B jobber og gir det videre til C. Hver ser inndataene fra den forrige. Lengde fastsetter rekkefølgen: B kan ikke starte før den får data fra A. Et klassisk eksempel: Først samler en undersøkende subagent kilder, deretter skriver en redigeringssubagent en artikkel basert på kildene, og så kontrollerer en faktasjekkende subagent artikkelen. Det er en flat sekvens; hovedchatten holder hele fortellingen.
**Dybde — nestede subagenter.** A starter B, B starter C, C starter D. Hvert barn jobber inne i sin forelder, i sitt eget isolerte vindu, og returnerer **bare resultatet** til forelderen. Hovedchatten ser ingenting av det som skjer hos barna, barnebarna og oldebarna. Dette er det nye i v2.1.172.
Den største forvirringen er at folk tror dybde 5 betyr «du kan starte 5 subagenter samtidig». Det stemmer ikke. Dybde er et vertikalt nivå i treet, ikke antallet samtidige barn. Det kan være én eller hundre subagenter på hvert nivå. Dybde 5 betyr at delegeringskjeden kan gå 5 trinn ned: hovedchat → barnebarn-1 → barnebarn-2 → barnebarn-3 → barnebarn-4 → barnebarn-5. Og det kan være forgreninger på hvert nivå.
Versjon 2.1.172 fjernet regelen om at en subagent ikke kunne starte en annen subagent.
Hvis du er ute etter hastighet, trenger du bredde. Hvis du har en streng utførelsesrekkefølge, trenger du lengde. Dybde er nyttig i nøyaktig ett tilfelle: når en av oppgavene dine inneholder en **støyende deloppgave** (15 nettførspørsler, gjennomgang av logger, lesing av et dusin filer). Og du ikke vil at all den støyen skal fylle hovedvinduet.
## Hva betyr «5 nivåer dypt» i praksis?
Hovedpoeng
5 nivåer er den maksimale vertikale avstanden fra hovedchatten til det fjerneste oldebarnet. Det er en grense på serversiden; du kan ikke øke eller senke den, eller slå den av med et flagg. Og offisielle kilder sier fortsatt ikke om hovedchatten selv regnes med blant de 5 nivåene.
Her er et viktig poeng om ærlighet. Jeg brukte en halv dag på dokumentasjon og miljøanalyser for å finne ut at Anthropic ikke har gitt en presis definisjon. Dette trenger du å vite.
**Det er en grense, ikke en innstilling.**
Grensen er innebygd på serversiden. Reverse engineering av klient v2.1.172 fant ingen `MAX_DEPTH`-konstant. Det betyr at kontrollen skjer et sted i Anthropic API-et, ikke lokalt på maskinen din. Du kan ikke angi `--max-depth 7` for å gjøre treet dypere. Du kan heller ikke angi `--max-depth 2` for å etablere en lavere og tryggere grense. Den eneste kontrollen du har, er `Agent(agent_type)`-tillatelseslisten i frontmatter — men den begrenser **typene** barneagenter, ikke dybden.
**Anthropic har ikke definert «5» presist.** Det er det andre viktige poenget:
**Anthropic har ikke definert «5» presist.** Offisielle kilder spesifiserer ikke om depth=5 betyr fem nivåer under roten eller fem agenter totalt, inkludert roten.
Tredjepartsintegrasjoner tolker dette ulikt foreløpig. ADR-147 i prosjektet `ruvnet/ruflo` legger til grunn «5 barnenivåer under roten = 6 agenter i kjeden». Jeg bruker samme konvensjon i eksperimentene mine: Hovedchatten er nivå 0, de direkte barna er nivå 1, og så videre opp til nivå 5. Men dette står ikke i den offentlige dokumentasjonen.
**Grensen er allerede aktivert, uten flagg.** Du trenger ikke å aktivere noe. Etter at du har oppdatert Claude Code til v2.1.172, kan du legge til `Agent` i `tools` for en barneagent, og den vil starte enda en subagent. Nøkkelen er at foreldreagenten må tillate det (`tools: Agent(...)`).
## Hvor foregår delegeringen din i dag: bredde, lengde eller dybde?
Hovedpoeng
I virkelige vibe-coding-prosjekter ser jeg nesten alltid bredde og av og til lengde. Dybde utfører folk manuelt: De åpner et nytt vindu, kopierer en prompt og kommer tilbake med resultatet. Før 9. juni var dette ikke innebygd. Derfor er det mange som ikke engang skjønner at de mangler denne muligheten.
Gå gjennom de siste 5 promptene dine. Hvor ofte har du gjort dette: En oppgave starter, Claude begynner å søke gjennom filer, gjør 10 nettførspørsler, dumper en hel vegg med logger inn i konteksten — og 20 minutter senere innser du at vinduet er fullt. Det endelige svaret må allerede klare seg med et magert tokenbudsjett fordi 70 prosent av konteksten gikk med til midlertidige utdrag.
Dette er et scenario der du trenger **dybde**. Ikke parallellisering, ikke en kjede — dybde. Hovedchatten bør delegere «undersøkelse» til én subagent, som deretter starter sine egne barn i vinduet sitt for bestemte nettsøk, filopplesninger og søk i filer. Barna returnerer bare sammenfattede vurderinger. Et barnebarn sier til forelderen sin: «fant det, bekreftet» eller «fant det ikke, årsak X». Forelderen setter dette sammen til ett sammendrag og returnerer det til deg. Hovedchatten forblir ryddig.
Før 9. juni etterlignet jeg dette manuelt. Jeg åpnet en ny Claude Code-instans, kopierte prompten «undersøk dette», kjørte den og overførte deretter resultatet manuelt tilbake til hovedvinduet. Jeg beskrev dette oppsettet i detalj i guiden min om delegering av kodearbeid til mange AI-agenter. Med v2.1.172 kan du beskrive det direkte i systemprompten til orkestratoren — Claude bygger treet selv.
## I hvilke 3 scenarioer er nestede subagenter faktisk nyttige?
Hovedpoeng
Ikke for alle oppgaver. Dybde er berettiget når én delegering inneholder en støyende deloppgave du ikke vil legge i hovedvinduet. Jeg tar for meg tre typiske scenarioer som stadig dukker opp blant vibe-kodere: grundig research med faktasjekking, analyse av et stort repository og ende-til-ende-revisjon av avhengigheter når et skjema eller en kontrakt endres.
### Scenario 1. Grundig research med faktasjekking
Tenk deg at du samler materiale til en artikkel eller et salgstilbud. Først må du hente inn 5–10 påstander fra offentlige kilder, og deretter kontrollere hver enkelt — finne originalkilden, forsikre deg om at sitatet er nøyaktig og beregne de faktiske tallene.
Før v2.1.172 hadde du to alternativer. Enten gjorde du alt med én subagent, som sleit seg gjennom 30 nettførspørsler og stappet alt inn i konteksten sin. Eller så delte du det opp manuelt: én prompt for å hente ut påstandene, deretter en runde gjennom påstandene med en separat subagent for hver. Hovedchatten ville blitt fylt med vegger av mellomliggende lister.
I oppskriften nedenfor delegerer hovedchatten til `research-orchestrator` (nivå 1). Orkestratoren henter ut påstander selv, sender hver til `fact-verifier` (nivå 2), og hver kontrollør delegerer fokuserte søk til `web-deep-search` (nivå 3). Hovedchatten mottar bare en samling med kontrollerte påstander og kilder. Alt annet forblir i barnevinduer og kommer aldri inn i konteksten din.
### Scenario 2. Analyse av et stort repository
Du har fått et prosjekt med 200 filer. Du må forstå arkitekturen, finne hovedmodulene og vurdere teknisk gjeld. Kjør `Glob` pluss et dusin `Read`-kall manuelt, så fyller du vinduet på 10 minutter.
Dybde løser det slik: Hovedchatten starter en «arkitekt»-subagent. Arkitekten starter tre barn internt — én undersøker katalogstrukturen (kjører `Glob` og oppsummerer), den andre leser 5 viktige konfigurasjonsfiler, og den tredje søker etter hovedmønstrene. Hver returnerer en kortfattet oppsummering til arkitekten. Arkitekten setter sammen bildet og gir hovedchatten en sluttrapport på en halv skjerm. Du får et kart over prosjektet uten at en vegg av `cat`-utdata fra alle filene oversvømmer konteksten.
### Scenario 3. Analyse av ende-til-ende-avhengigheter
Du endrer et databaseskjema, en API-kontrakt eller en delt konfigurasjonsfil. Du må forstå hvor effektene vil vise seg. Denne oppgaven fyller konteksten raskest fordi det finnes mange avhengigheter, og hver av dem må kontrolleres i kildekoden.
Med dybde starter hovedchatten en `impact-analyzer` (nivå 1). Den starter én `dependency-tracer` for hver berørte fil (nivå 2). Hver tracer starter internt en `consumer-finder` (nivå 3), som søker gjennom kodebasen etter brukere av denne avhengigheten. Deretter returnerer hver av dem bare kjernen: «disse tre stedene vil slutte å fungere». Hovedchatten setter sammen en tabell over «berørte filer → påvirkning» uten å kjenne til søkeresultatene.
## Slik setter du opp nestede subagenter på 10 minutter
Hovedpoeng
Du trenger ingen flagg eller konfigurasjonsoppdateringer. Bare legg til `Agent` i `tools` for en barneagent, så kan den starte sine egne subagenter. For å hindre at treet blir et kasino, bruk tillatelseslisten `Agent(name1, name2)`. Nå får du en ferdig mal for en orkestrator på tre nivåer som du kan kopiere.
**Trinn 1. Sørg for at du bruker v2.1.172 eller nyere.**
```bash
claude --version
```
Hvis versjonen er eldre, må du oppdatere. Hovedfunksjonen i utgivelsen er én linje i endringsloggen: «Subagenter kan nå starte sine egne subagenter, opptil 5 nivåer dypt» ([hele teksten](https://github.com/anthropics/claude-code/releases/tag/v2.1.172)).
**Trinn 2. Opprett en foreldreagent som kan starte barn.**
Filen `.claude/agents/research-orchestrator.md`:
```markdown
---
name: research-orchestrator
description: Delegerer research med grundig faktasjekk
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---
Du er en research-orkestrator. Når du får et tema:
1. Les det tilførte materialet eller hent de oppgitte offentlige kildeadressene.
Hent selv ut opptil 5 konkrete påstander. Registrer påstandstekst,
kildeadresse eller fil og eksakt støttende tekstutdrag for hver.
Hvis kildemateriale mangler, be om det før delegering.
2. Kall fact-verifier for hver påstand — den starter selv
sine egne barne-subagenter for nettsøk og kontroll.
3. fact-verifier returnerer bare de endelige vurderingene til deg —
ikke last mellomliggende utdrag inn i konteksten din.
Sluttrapporten skal bare være en array { claim, sources[], confidence }.
```
`tools`-linjen tillater bare barnetypen `fact-verifier`. Påstandsuttrekk er orkestratorens eget første trinn, slik at ingen udefinert `claim-extractor`-fil trengs. En typetillatelsesliste begrenser hvilken barneagent som kan kalles, ikke antall starter av typen. Avgrens oppskriften til høyst fem uthentede påstander.
**Trinn 3. Opprett en barneagent som selv kan starte barnebarn.**
Filen `.claude/agents/fact-verifier.md`:
```markdown
---
name: fact-verifier
description: Kontrollerer en påstand gjennom nettsøk utført av barn
tools: Agent(web-deep-search), Read
model: sonnet
---
Du er en faktasjekker. Når du får en påstand:
1. Formuler 2-3 søkespørsmål.
2. Start web-deep-search for hvert spørsmål — den utfører selv
WebSearch og WebFetch og returnerer verifiserte utdrag.
3. Samle alt i én vurdering: { claim, sources[], confidence }.
```
Ser du hovedpoenget? `tools`-linjen sier igjen `Agent(web-deep-search)`. Det betyr at fact-verifier (nivå 2 i treet vårt) selv kan starte enda en subagent (nivå 3). Tidligere hadde denne linjen ingen effekt — dokumentasjonen inneholder fortsatt formuleringen:
Subagenter kan ikke starte andre subagenter, så Agent(agent_type) fungerer ikke i subagentdefinisjoner.
— Claude Code Docs, https://code.claude.com/docs/en/sub-agents
Med v2.1.172 er denne linjen utdatert. Syntaksen er den samme, men nå fungerer den på alle nivåer i treet.
**Trinn 4. Opprett et barnebarn.**
Filen `.claude/agents/web-deep-search.md`:
```markdown
---
name: web-deep-search
description: Utfører nettsøk og returnerer utdrag
tools: WebSearch, WebFetch
model: haiku
---
Du har fått et søkespørsmål. Kjør WebSearch, velg de 3 mest
relevante URL-ene, og hent ordrette bekreftelser av påstanden
med WebFetch. Returner en array { url, snippet, supports_claim: yes|no }.
```
Barnebarnet har ikke `Agent` i `tools`, så det starter ikke flere agenter lenger ned i treet.
**Trinn 5. Kjør orkestratoren.**
```bash
claude --agent research-orchestrator
```
Tilfør deretter kildetekst eller offentlige kildeadresser i chatten: «Hent ut og kontroller opptil 5 konkrete påstander fra disse kildene; returner påstander, kilder og sikkerhetsgrad.» Med `--agent research-orchestrator` er økten selv orkestratoren; kontrollør- og søkebarna legger til to delegerte nivåer under den. Hvis en vanlig hovedøkt i stedet delegerer til orkestratoren, blir det tre delegerte nivåer under hovedøkten.
## Hvilke 5 antipatterner sløser med tokens og ødelegger oversikten?
Hovedpoeng
Dybde er kostbart. Hvert nivå nedover mangedobler tokenbruken, og denne multiplikasjonen forsterkes. Her er fem scenarioer der nesting skader deg. Ikke gjør dette — ellers bruker du opp dagsbudsjettet på en time og mister oversikten over feilen fire etasjer ned i treet.
**Antipattern 1. Oppgaven får plass i ett vindu.**
Hvis én subagent kan håndtere oppgaven uten støy, tilfører nesting bare kostnader og forsinkelser uten grunn.
**Antipattern 2. Du er ute etter hastighet, ikke isolasjon.**
Hvis du vil ha hastighet, trenger du **parallellisering**, ikke dybde. Start 5 subagenter side om side på samme nivå i stedet for å bygge en kjede. Dybde er ment for å flytte støyende forarbeid til et barnevindu, ikke for å gjøre ting raskere.
**Antipattern 3. Arbeidet er i sin natur grunt.**
«Finn denne filen og vis den til meg» er en **forespørsel i to trinn**; den trenger ikke et hierarki på tre nivåer. Nesting lønner seg når en oppgave inneholder en støyende deloppgave. Hvis det ikke er støy, ikke legg til subagenter.
**Antipattern 4. Vage prompts på første nivå.**
Dette er det farligste scenarioet. Hvis du gir orkestratoren på nivå 1 en vag prompt, mangedobles uklarheten. Én vag prompt på nivå 1 blir til 4 vage prompts på nivå 2 og 16 på nivå 3. Når barnebarna begynner å jobbe, vet de ikke engang hva de skal lete etter.
**Antipattern 5. Geometrisk kostnadsvekst.**
Det viktigste økonomiske argumentet: Nesting mangedobler tokenbruken, og multiplikasjonen forsterkes med dybden.
Et grovt regnestykke: En kjede med dybde 3 og en forgrening på 3 på hvert nivå betyr 27 subagenter. Det er minst 27 ganger flere tokens enn for en enkel forespørsel. Med Claude Pro-abonnementet bruker du opp dagsgrensen på et par timer. Har du Max-abonnement, bruker du opp en ukes kvote på én dag.
**Bonus-antipattern (min erfaring): «50 agenter som gjør meningsløst arbeid.»**
Når jeg ser på prosjektene til andre, ser jeg ofte dette: «Jeg har 50 agenter i arbeid.» Jeg spør hva de gjør. Og de 50 agentene **gjør meningsløst arbeid**. De produserer haugevis av unødvendige resultater, mengder med råsammendrag, duplikater og vegger av logger. Hver agent gjør noe «nyttig i en eller annen sammenheng», og resultatet er en kontekst som drukner i innhold og en tokenregning som for et lite selskap. Dybde 5 løser ikke dette problemet — det **gjør det verre**. Hvis det allerede er uklart på nivå 1 hvem som gjør hva, betyr dybde 5 fem nivåer med forvirring.
Før du starter en subagent, test den ved å svare på 4 spørsmål på et halvt minutt:
- Hva gjør den helt konkret (i én setning)?
- Hvilke filer berører den?
- Hva returnerer den til forelderen?
- Hvem kontrollerer den?
Hvis du ikke kan svare innen 30 sekunder, bør ikke denne subagenten finnes. Jeg forklarte denne regelen separat i guiden min [om parallelle subagenter](https://ailoot.ai/blog/nb/claude-code-parallel-worktree-agents/).
## Hvorfor fører nesting uten kontekstteknikk til 5 nivåer med hallusinasjoner?
Hovedpoeng
Den største fallgruven ved dyp delegering er manglende oppgavekontekst. Et barn mottar ikke automatisk hele foreldresamtalen eller alle leste filer. Egendefinerte subagenter laster vanligvis relevante CLAUDE.md-instruksjoner med mindre de er konfigurert til å utelate dem; dette laster ikke automatisk alle refererte forretningsfiler. Send eksakt kildemateriale, filbaner og resultatkontrakt ved hver overlevering. Hvis prosjektet ditt mangler en god kontekststruktur, driver hvert barnebarn lenger ut i fantasien jo dypere treet blir. Du får 5 etasjer med hallusinasjoner, én på hvert nivå.
Her spør folk ofte: «Jeg oppdaterte Claude Code, la til Agent i tools, og treet bygges — men sluttsvaret er fortsatt feil. Hvorfor?»
Svaret er enkelt. Hver subagent i Claude Code starter **helt fra begynnelsen**. Fra den offisielle dokumentasjonen:
Hver subagent starter i et nytt, isolert vindu. Den kan ikke se samtalehistorikken, ferdighetene du allerede har kalt, eller filene Claude allerede har lest.
— Claude Code Docs, https://code.claude.com/docs/en/sub-agents
På nivå 1 er dette håndterbart: Orkestratoren gir barnet en kort oppgavebeskrivelse. Men på nivå 3 får barnebarnet en delegeringsmelding fra forelderen sin, som selv bare hadde en delegeringsmelding. Hvert ledd ga bare litt videre. På nivå 5 har du en subagent med vinduet fullt av formuleringen «kontroller påstand X», og ingenting annet. Den vet ikke hvilket prosjekt den jobber med, hvilken oppgave den løser eller hva den skal fokusere på.
Uten [CLAUDE.md](https://ailoot.ai/blog/nb/claude-md-template/) er et barnebarn på nivå fem som en ansatt som møter opp på kontoret for aller første gang uten noen introduksjon. Den vil gjøre noe fordi den fikk en oppgave. Men det blir ikke det prosjektet trenger.
**Derfor er oppsettet helt nødvendig.** Dybde 5 uten en riktig konfigurert `CLAUDE.md`, `business/` og en ferdighetspipeline er et kasino. Med dette på plass er det et verktøy.
## Hva annet endret seg i v2.1.172 enn nesting?
Hovedpoeng
Utgivelsen handler utelukkende om subagenter. I tillegg til hovedfunksjonen inneholder den 4 rettelser i delegeringsinfrastrukturen. Én av dem retter en feil som bare kan oppstå ved nesting.
Åpne hele endringsloggen for v2.1.172, så ser du at hele utgivelsen handler om subagenter.
**Rettelse 1.** En bakgrunnssubagent blir ikke lenger «hengende» som aktiv i agentpanelet etter at den nestede subagenten den startet, er stoppet. Denne feilen kan bare oppstå med nesting.
**Rettelse 2.** Begrensninger for `availableModels` gjelder nå også for subagenter. Tidligere kunne subagenter omgå regelen med en overstyring i sin egen konfigurasjon hvis du begrenset hvilke modeller teamet kunne bruke (for eksempel ved å forby opus for å spare penger). Med v2.1.172 gjelder regelen overalt.
**Rettelse 3.** Pil opp i promptloggen viser nå promptene fra subagentens **gjeldende** fane, ikke hovedagentens. En forbedring av oversikten.
**Rettelse 4.** CPU-bruken i hvilemodus er redusert: `/goal`-indikatoren tegner ikke lenger terminalen på nytt med 5 Hz når den er inaktiv, og brukergrensesnittet tegnes sjeldnere på nytt mens parallelle subagenter jobber.
Jeg vil påpeke at alle fire rettelsene gjelder subagenter. Det betyr at Anthropic lanserte hele infrastrukturen for nesting, ikke bare én linje i endringsloggen. Nesting hadde allerede vært i bruk internt hos Anthropic en stund før publiseringen.
## Sjekkliste: når nesting hjelper og når det skader
Hovedpoeng
Gå gjennom 6 kontroller for oppgaven før du starter en ny subagent. Hvis minst 3 svar er «ja, bruk dybde», gjør det. Hvis færre svar er det, hold deg til parallellisering eller én subagent. Da sparer du tokens, nerver og et par timer på å finne ut hva en kjede med 27 nestede starter egentlig holdt på med.
Bruk nesting hvis:
- Oppgaven inneholder en deloppgave med mange nettførspørsler, filsøk eller filopplesninger.
- Det er greit å miste deloppgaven (hvis barnebarnet returnerer «fant ingenting», kan orkestratoren fortsette).
- Du **ikke trenger** mellomresultater i hovedvinduet.
- Du har en `CLAUDE.md` og en samlet prosjektkontekst som subagenten kan stole på.
- Du tydelig kan beskrive hva hvert nivå skal returnere (inndata, utdata, format).
- Du har et Max-abonnement eller en buffer for ×27 tokens.
Ikke bruk nesting hvis:
- Én subagent kan løse oppgaven uten støy.
- Du trenger mellomresultater i hovedvinduet (da vil du ha parallellisering).
- Prosjektet ikke har en CLAUDE.md eller bare har sparsom forretningskontekst.
- Promptene på nivå 1 er vage (uklarheten vil forplante seg eksponentielt nedover i treet).
- Du trenger hastighet — parallellisering er raskere enn dybde for et tilsvarende resultat.
- Du har Pro-abonnementet og jobber hele dagen — du bruker opp grensen i løpet av et par timer.
Flere materialer er tilgjengelige på [Ailoot](https://ailoot.ai/).
## Spørsmål om denne veiledningen: Slik delegerer du en stor oppgave i Claude Code med nestede subagenter
### Må jeg opprette claim-extractor for den kopierte oppskriften?
Nei. Den korrigerte research-orchestrator henter selv ut opptil fem påstander fra tilført materiale. Opprett de tre viste filene: research-orchestrator, fact-verifier og web-deep-search. Tilfør deretter kildetekst eller adresser.
### Begrenser tillatelse bare til fact-verifier antall barnestarter?
Nei. En tillatelsesliste for agenttyper begrenser hvilke typer som kan kalles, ikke antall kall. Oppskriften avgrenser påstandsuttrekket separat til fem påstander. Overvåk faktiske kall og tokenbruk.
## Ailoot · Selskapet og dets prosjektportefølje
Ailoot bygger på etablert driftserfaring, en stor kundebase, stabil tjeneste og løpende KPI-kontroll.
Selskapet og dets prosjektportefølje: millioner av kunder; månedlig salg for milliarder.
Ailoot bruker denne driftserfaringen til API-tilgang til AI-funksjoner i kundenes produkter, agenter, applikasjoner og automatiseringer.