# Så delegerar du en stor uppgift i Claude Code med nästlade underagenter

> I v2.1.172 kan Claude Code-underagenter starta egna underagenter upp till fem nivåer djupt. Här finns instruktioner för att delegera en stor uppgift.

Source: https://ailoot.ai/blog/sv/claude-code-nested-subagents/
Canonical: https://ailoot.ai/blog/sv/claude-code-nested-subagents/
Language: sv
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-232
Revision: sha256-604727d7b0c92311d890411abfeef8487fcabcac82604531917753a7bd3090c4


<div class="aside" data-semantic="editorial-reference" role="note" aria-label="Ailoot-dokumentation">

[Ailoot-dokumentation](https://ailoot.ai/docs/) — referensmaterial om hur tjänsten används.

</div>

## Vad ändrades i Claude Code v2.1.172?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Det viktigaste i det här avsnittet">

Det viktigaste

Anthropic släppte Claude Code v2.1.172 och tog bort en två år gammal regel enligt en enda rad i ändringsloggen. Underagenter kan nu starta egna underagenter, upp till fem nivåer djupt. Funktionen handlar inte om hastighet eller mer CPU. Huvudidén är att hålla rörigt förarbete borta från huvudkontexten.

</div>

Om du har läst något om AI-agenter i Claude Code under de senaste månaderna har du stött på samma fras. Den finns i den officiella dokumentationen, i min guide [om underagenter](https://ailoot.ai/blog/sv/claude-code-subagents/) och i varje konkurrents analys. Den lyder: ”en underagent kan inte starta en annan underagent”. Den 11 juni 2026 står den raden fortfarande på tre olika ställen på `code.claude.com/docs/en/sub-agents`. Anthropic har helt enkelt inte uppdaterat den än.

Den 10 juni klockan 20:44 UTC dök Claude Code v2.1.172 upp på GitHub Releases. Den viktigaste punkten i ändringsloggen var en enda rad:

<figure>
<blockquote>
Underagenter kan nu starta egna underagenter, upp till 5 nivåer djupt.
</blockquote>
<figcaption>— Claude Code Changelog, https://github.com/anthropics/claude-code/releases/tag/v2.1.172</figcaption>
</figure>

Samma version rättade också en bugg som bara kunde uppstå vid nästling: en underagent som kördes i bakgrunden fortsatte att markeras som aktiv i agentpanelen efter att den nästlade underagent som den startat redan hade stoppats.

Det här är ett ovanligt fall där den officiella dokumentationen fortfarande motsäger den släppta versionen. Nu förklarar jag hur nästling skiljer sig från parallella underagenter, vad ”djup 5” betyder och de tre scenarier där det faktiskt är användbart i dag.

## Hur skiljer sig nästlade underagenter från parallella och sekventiella?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Det viktigaste i det här avsnittet">

Det viktigaste

Om du är förvirrad är du inte ensam. Parallellism, kedjor och nästling är tre oberoende topologier. Parallellism handlar om hastighet, kedjor om att fastställa körordningen och nästling om något helt annat: den döljer rörigt arbete från huvudfönstret. Blandar du ihop dem förbrukar du mängder av tokens på ett par timmar och kan sedan inte hitta var felet finns.

</div>

Jag har lagt lång tid på att prova de här tre metoderna för hand, och så här tänker jag på dem: delegering har tre dimensioner. Bredd, längd och djup. Var och en löser ett annat problem.

**Bredd — parallella underagenter.** Huvudchatten startar N oberoende underagenter på samma nivå. Var och en får en avgränsad uppgift, arbetar i ett eget isolerat fönster och returnerar endast resultatet. Bredd löser hastighetsproblemet: 5 underagenter som arbetar parallellt blir klara på den tid det tar en att göra samma arbete sekventiellt. Det här är modellen jag tog upp i min guide [om parallella underagenter med worktrees](https://ailoot.ai/blog/sv/claude-code-parallel-worktree-agents/).

**Längd — en kedja av underagenter.** A arbetar och lämnar resultatet till B, B arbetar och lämnar det till C. Var och en ser indata från föregående steg. Längd fastställer ordningen: B kan inte börja förrän den får data från A. Ett klassiskt exempel: först samlar en researchunderagent in källor, sedan skriver en redigeringsunderagent en artikel baserad på källorna, och därefter granskar en faktakontrollerande underagent artikeln. Det är en platt sekvens; huvudchatten har hela händelseförloppet.

**Djup — nästlade underagenter.** A startar B, B startar C, C startar D. Varje barn arbetar inuti sin förälder, i ett eget isolerat fönster, och returnerar **endast resultatet** till sin förälder. Huvudchatten ser inget av det som händer hos barnen, barnbarnen och barnbarnsbarnen. Det här är nyheten i v2.1.172.

Den vanligaste missuppfattningen är att djup 5 betyder ”du kan starta 5 underagenter samtidigt”. Så är det inte. Djup är en vertikal nivå i trädet, inte antalet samtidiga barn. Det kan finnas en underagent eller hundra på varje nivå. Djup 5 betyder att delegeringskedjan kan gå ner 5 steg: huvudchatt → barnbarn-1 → barnbarn-2 → barnbarn-3 → barnbarn-4 → barnbarn-5. Och det kan förgrena sig på varje nivå.





Version 2.1.172 tog bort regeln att en underagent inte kunde starta en annan underagent.

Om du vill ha hastighet behöver du bredd. Om du har en strikt körordning behöver du längd. Djup är användbart i precis ett fall: när en av dina uppgifter innehåller en **rörig deluppgift** (15 webbförfrågningar, genomgång av loggar, läsning av ett dussin filer). Och du inte vill att allt det ska fylla huvudfönstret.

## Vad innebär ”5 nivåers djup” i praktiken?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Det viktigaste i det här avsnittet">

Det viktigaste

5 nivåer är det maximala vertikala avståndet från huvudchatten till det yttersta barnbarnsbarnet. Det är en gräns på serversidan; du kan inte höja eller sänka den eller stänga av den med en flagga. Och officiella källor säger fortfarande inte om själva huvudchatten räknas in bland de 5 nivåerna.

</div>

Här är en viktig uppriktighetsmarkering. Jag lade en halv dag på dokumentation och communityanalyser för att ta reda på att Anthropic inte har gett någon exakt definition. Det här behöver du veta.

**Det är en gräns, inte en inställning.**



Begränsningen är inbyggd på serversidan. Reverse engineering av klienten v2.1.172 hittade ingen konstant `MAX_DEPTH`. Det betyder att kontrollen sker någonstans i Anthropic API, inte lokalt på din dator. Du kan inte ange `--max-depth 7` för att göra trädet djupare. Du kan inte heller ange `--max-depth 2` för att sätta en lägre och säkrare gräns. Den enda kontroll du har är tillåtelselistan `Agent(agent_type)` i frontmatter — men den begränsar **typerna** av barnagenter, inte djupet.

**Anthropic har inte definierat ”5” exakt.** Det är den andra viktiga punkten:

**Anthropic har inte preciserat vad ”5” betyder.** Officiella källor anger inte om depth=5 betyder fem nivåer under roten eller fem agenter totalt, inklusive roten.

Tredjepartsintegrationer tolkar det olika för närvarande. ADR-147 i projektet `ruvnet/ruflo` antar ”5 barnnivåer under roten = 6 agenter i kedjan”. Jag använder samma konvention i mina experiment: huvudchatten är nivå 0, dess direkta barn är nivå 1 och så vidare upp till nivå 5. Men det här finns inte dokumenterat offentligt.

**Gränsen är redan aktiverad, utan flaggor.** Du behöver inte aktivera något. När du har uppdaterat Claude Code till v2.1.172 kan du lägga till `Agent` i en barnagents `tools`, så startar den en annan underagent. Nyckeln är att föräldraagenten måste tillåta det (`tools: Agent(...)`).

## Var sker din delegering i dag: bredd, längd eller djup?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Det viktigaste i det här avsnittet">

Det viktigaste

I verkliga projekt med vibe coding ser jag nästan alltid bredd och ibland längd. Djup hanterar folk manuellt: de öppnar ett nytt fönster, kopierar en prompt och kommer tillbaka med resultatet. Före den 9 juni var det inte inbyggt. Därför inser de flesta inte ens att de saknar det.

</div>

Gå igenom dina senaste 5 promptar. Hur ofta har du gjort så här: en uppgift börjar, Claude börjar söka bland filer, gör 10 webbförfrågningar, lägger in en hel vägg av loggar i kontexten — och 20 minuter senare inser du att fönstret är fullt. Det slutliga svaret har redan en knapp tokenbudget kvar eftersom 70 procent av kontexten förbrukades av mellanliggande utdrag.

Det är ett scenario där du behöver **djup**. Inte parallellism eller en kedja — djup. Huvudchatten ska delegera ”research” till en underagent, som sedan startar egna barn inifrån för specifika webbsökningar, filläsningar och greps. Barnen returnerar endast destillerade bedömningar. Ett barnbarn säger till sin förälder: ”hittade det, bekräftat” eller ”hittade det inte, orsak X”. Föräldern sammanställer det till en enda sammanfattning och returnerar den till dig. Huvudchatten förblir ren.

Före den 9 juni gjorde jag det här för hand. Jag öppnade en andra Claude Code-instans, kopierade prompten ”undersök det här”, körde den och förde sedan över resultatet manuellt till huvudfönstret. Jag beskrev upplägget i detalj i min guide om att delegera kodning till många AI-agenter. Med v2.1.172 kan du beskriva det direkt i orkestratorns systemprompt – Claude bygger trädet själv.



## I vilka 3 scenarier är nästlade underagenter faktiskt användbara?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Det viktigaste i det här avsnittet">

Det viktigaste

Inte för varje uppgift. Djup är motiverat när en delegering innehåller en rörig deluppgift som du inte vill lägga i huvudfönstret. Jag tar upp tre typiska scenarier som återkommer bland vibe coders: djup research med faktakontroll, analys av ett stort kodförråd och granskning av beroenden från början till slut vid en ändring av schema eller kontrakt.

</div>

### Scenario 1. Djup research med faktakontroll

Anta att du samlar material till en artikel eller ett säljerbjudande. Först behöver du hämta 5–10 påståenden från offentliga källor och sedan verifiera vart och ett — hitta originalkällan, kontrollera att citatet är exakt och räkna ut de faktiska siffrorna.

Före v2.1.172 hade du två alternativ. Antingen gjorde du allt med en underagent, som slet sig igenom 30 webbförfrågningar och stoppade in allt i sin kontext. Eller så delade du upp arbetet manuellt: en prompt för att ta fram påståendena och sedan en loop över påståendena, där du startade en separat underagent för vart och ett. Huvudchatten fylldes av väggar av mellanliggande listor.

I receptet nedan delegerar huvudchatten till `research-orchestrator` (nivå 1). Orkestratorn extraherar påståenden själv och skickar varje till `fact-verifier` (nivå 2), där varje verifierare delegerar fokuserade sökningar till `web-deep-search` (nivå 3). Huvudchatten får endast en lista med verifierade påståenden och källor. Allt annat stannar i barnens fönster och kommer aldrig in i din kontext.

### Scenario 2. Analys av ett stort kodförråd

Du har fått ett projekt med 200 filer. Du behöver förstå arkitekturen, hitta huvudmodulerna och bedöma den tekniska skulden. Kör `Glob` och ett dussin `Read`-anrop för hand, så fyller du fönstret på 10 minuter.

Djup löser det så här: huvudchatten startar en ”arkitekt”-underagent. Arkitekten startar internt tre barn — ett granskar katalogstrukturen (kör `Glob` och sammanfattar), det andra läser 5 viktiga konfigurationsfiler och det tredje söker efter huvudmönstren med grep. Var och en returnerar en kortfattad sammanfattning till arkitekten. Arkitekten sammanställer helhetsbilden och ger huvudchatten en slutrapport som är en halv skärm lång. Du får en karta över projektet utan att dränka kontexten i en vägg av `cat`-utdata från alla filer.

### Scenario 3. Analys av beroenden från början till slut

Du ändrar ett databasschema, ett API-kontrakt eller en delad konfigurationsfil. Du behöver förstå var effekterna kommer att märkas. Den här uppgiften tömmer kontexten snabbast eftersom det finns många beroenden och vart och ett måste kontrolleras i källkoden.

Med djup startar huvudchatten en ”impact-analyzer” (nivå 1). Den startar en `dependency-tracer` för varje berörd fil (nivå 2). Varje tracer startar internt en `consumer-finder` (nivå 3), som söker igenom kodbasen efter användare av beroendet. Sedan returnerar varje agent bara kärnan: ”de här tre ställena kommer att gå sönder”. Huvudchatten sammanställer en tabell med ”berörda filer → påverkan” utan att känna till grep-resultaten.





## Så ställer du in nästlade underagenter på 10 minuter

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Det viktigaste i det här avsnittet">

Det viktigaste

Inga flaggor eller konfigurationsändringar behövs. Lägg bara till `Agent` i en barnagents `tools`, så kan den starta egna underagenter. För att hindra trädet från att förvandlas till ett kasino använder du tillåtelselistan `Agent(name1, name2)`. Härnäst får du en färdig mall för en orkestrator med tre nivåer som du kan kopiera.

</div>

**Steg 1. Kontrollera att du använder v2.1.172 eller senare.**

```bash
claude --version
```

Om versionen är lägre uppdaterar du. Den viktigaste funktionen i släppet är en enda rad i ändringsloggen: ”Underagenter kan nu starta egna underagenter, upp till 5 nivåer djupt” ([hela texten](https://github.com/anthropics/claude-code/releases/tag/v2.1.172)).

**Steg 2. Skapa en föräldraagent som kan starta barn.**

Filen `.claude/agents/research-orchestrator.md`:

```markdown
---
name: research-orchestrator
description: Delegates research with a deep fact-check
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---

You are a research orchestrator. When you get a topic:
1. Read the supplied material or fetch the supplied public source URLs.
   Extract up to 5 concrete claims yourself. For each, record the claim text,
   its source URL or file, and the exact supporting passage.
   If no source material was supplied, ask for it before delegating.
2. For each claim call fact-verifier - it spawns
   its own child subagents for web search and cross-checking.
3. fact-verifier returns only the final verdicts to you -
   do not load intermediate dumps into your context.

Final report - only an array { claim, sources[], confidence }.
```

Raden `tools` tillåter bara barntypen `fact-verifier`. Extraktion av påståenden är orkestratorns eget första steg, så ingen odefinierad `claim-extractor`-fil behövs. En typbegränsning styr vilket barn som får anropas; den begränsar inte hur många gånger typen startas. Håll receptet avgränsat till högst fem extraherade påståenden.

**Steg 3. Skapa en barnagent som själv kan starta barnbarn.**

Filen `.claude/agents/fact-verifier.md`:

```markdown
---
name: fact-verifier
description: Checks a claim through child web searches
tools: Agent(web-deep-search), Read
model: sonnet
---

You are a fact-checker. When you get a claim:
1. Write 2-3 search queries.
2. For each one run web-deep-search - it will do
   WebSearch and WebFetch itself and return verified snippets.
3. Combine them into one verdict: { claim, sources[], confidence }.
```

Ser du den viktiga delen? `tools` säger återigen `Agent(web-deep-search)`. Det betyder att faktagranskaren (nivå 2 i vårt träd) själv kan starta ytterligare en underagent (nivå 3). Tidigare hade den här raden ingen effekt — dokumentationen innehåller fortfarande frasen:

<figure>
<blockquote>
Underagenter kan inte starta andra underagenter, så Agent(agent_type) fungerar inte i underagentdefinitioner.
</blockquote>
<figcaption>— Claude Code Docs, https://code.claude.com/docs/en/sub-agents</figcaption>
</figure>

Med v2.1.172 är den raden inaktuell. Syntaxen är densamma, men nu fungerar den på alla nivåer i trädet.

**Steg 4. Skapa ett barnbarn.**

Filen `.claude/agents/web-deep-search.md`:

```markdown
---
name: web-deep-search
description: Runs a web search and returns snippets
tools: WebSearch, WebFetch
model: haiku
---

You received a search query. Run WebSearch, pick the top 3
relevant URLs, use WebFetch to pull verbatim confirmations
of the claim. Return an array { url, snippet, supports_claim: yes|no }.
```

Barnbarnet har inte `Agent` i `tools`, så det startar inga fler agenter längre ner i trädet.

**Steg 5. Kör orkestratorn.**

```bash
claude --agent research-orchestrator
```

Lämna sedan källtext eller offentliga källadresser i chatten: ”Extrahera och verifiera upp till 5 konkreta påståenden ur dessa källor; returnera påståenden, källor och säkerhetsgrad.” Med `--agent research-orchestrator` är sessionen själv orkestratorn; dess verifierar- och sökbarn lägger till två delegerade nivåer under den. Om en vanlig huvudsession i stället delegerar till orkestratorn finns tre delegerade nivåer under huvudsessionen.

## Vilka 5 antityper slösar med tokens och förstör observerbarheten?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Det viktigaste i det här avsnittet">

Det viktigaste

Djup är dyrt. Varje nivå nedåt multiplicerar antalet tokens, och multiplikationen växer med djupet. Här är fem scenarier där nästling skadar dig. Gör inte så här — då bränner du igenom dagsbudgeten på en timme och tappar bort felet fyra våningar ner i trädet.

</div>

**Antityp 1. Uppgiften ryms i ett fönster.**

Om en underagent kan hantera uppgiften utan brus ska du inte lägga till nivåer: nästling tillför kostnad och fördröjning i onödan.

Om en underagent kan hantera uppgiften utan brus ska du inte lägga till nivåer: nästling tillför kostnad och fördröjning i onödan.

**Antityp 2. Du vill ha hastighet i stället för isolering.**

Om du vill ha hastighet behöver du **parallellism**, inte djup. Starta 5 underagenter sida vid sida på samma nivå i stället för att bygga en kedja. Djup finns till för att flytta rörigt förarbete till ett barnfönster, inte för att snabba upp arbetet.

**Antityp 3. Arbetet är i grunden enkelt.**

”Hitta den här filen och visa mig den” är en **förfrågan i två steg**; den behöver ingen hierarki i tre nivåer. Nästling lönar sig när en uppgift innehåller en rörig deluppgift. Om det inte finns något brus ska du inte lägga till underagenter.

**Antityp 4. Otydliga promptar på första nivån.**

Det här är det farligaste scenariot. Om du ger orkestratorn på nivå 1 en otydlig prompt mångfaldigas otydligheten. En otydlig prompt på nivå 1 blir 4 otydliga promptar på nivå 2 och 16 på nivå 3. När barnbarnen börjar arbeta vet de inte ens vad de ska leta efter.

**Antityp 5. Geometrisk kostnadsökning.**

Det främsta ekonomiska argumentet: nästling multiplicerar tokenanvändningen, och den effekten växer med djupet.

Det främsta ekonomiska argumentet: nästling multiplicerar tokenanvändningen, och den effekten växer med djupet.

En grov kalkyl: en kedja med djup 3 och en förgrening på 3 på varje nivå innebär 27 underagenter. Det är minst 27 gånger fler tokens än för en enkel förfrågan. På Claudes Pro-plan räcker den kalkylen för att bränna igenom dagsgränsen på ett par timmar. Om du har Max-plan förbrukar du en veckas tilldelning på en dag.

**Bonusantityp (min erfarenhet): ”50 agenter som gör meningslöst arbete.”**

När jag tittar på andras projekt ser jag ofta det här: ”Jag har 50 agenter i arbete.” Jag frågar vad de gör. Och de 50 agenterna **gör meningslöst arbete**. De genererar högar av onödiga utdata, massor av råa sammanfattningar, dubletter och väggar av loggar. Var och en gör något ”i allmänhet användbart”, och resultatet är en kontext som dränks och en tokenräkning som för ett litet företag. Djup 5 löser inte problemet — det **förvärrar det**. Om det redan är oklart på nivå 1 vem som gör vad innebär djup 5 fem nivåer av förvirring.

Innan du startar någon underagent ska du testa den genom att besvara 4 frågor på en halv minut:

- Vad gör den exakt (med en mening)?
- Vilka filer rör den?
- Vad returnerar den till sin förälder?
- Vem kontrollerar den?

Om du inte kan svara på 30 sekunder ska den här underagenten inte finnas. Jag förklarade den här regeln separat i min guide [om parallella underagenter](https://ailoot.ai/blog/sv/claude-code-parallel-worktree-agents/).

## Varför innebär nästling utan kontextteknik 5 nivåer av hallucinationer?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Det viktigaste i det här avsnittet">

Det viktigaste

Den största fällan med djup delegering är saknad uppgiftskontext. Ett barn får inte automatiskt förälderns hela samtal eller varje fil den läste. Anpassade subagenter läser normalt tillämpliga CLAUDE.md-instruktioner om de inte konfigurerats att utelämna dem; det läser inte automatiskt in alla refererade affärsfiler. Skicka exakt källmaterial, sökvägar och resultatkontrakt vid varje överlämning. Om projektet saknar en sund kontextstruktur driver varje barnbarn längre in i fantasier ju djupare trädet blir. Du får 5 våningar av hallucinationer, en på varje nivå.

</div>

Det är här folk ofta frågar mig: ”Artemij, jag uppdaterade Claude Code, lade till Agent i tools och trädet byggs — men slutresultatet är fortfarande fel. Varför?”

Svaret är enkelt. Varje underagent i Claude Code börjar **från början**. Från den officiella dokumentationen:

<figure>
<blockquote>
Varje underagent startar i ett nytt, isolerat fönster. Den kan inte se konversationshistoriken, färdigheterna du redan har anropat eller filerna Claude redan har läst.
</blockquote>
<figcaption>— Claude Code Docs, https://code.claude.com/docs/en/sub-agents</figcaption>
</figure>

På nivå 1 går det att hantera: orkestratorn skickar en kort uppgiftsbeskrivning till sitt barn. Men på nivå 3 får barnbarnet ett delegeringsmeddelande från sin förälder, som också bara hade fått ett delegeringsmeddelande. Var och en skickade bara vidare lite information. På nivå 5 har du en underagent vars fönster innehåller frasen ”kontrollera påstående X” och inget annat. Den vet inte vilket projekt den arbetar med, vilken uppgift den löser eller vad den ska fokusera på.

Utan [CLAUDE.md](https://ailoot.ai/blog/sv/claude-md-template/) är ett barnbarn på nivå fem som en anställd som kommer till kontoret för första gången i sitt liv utan någon introduktion. Den kommer att göra något eftersom den fått en uppgift. Men det blir inte det projektet behöver.



## Vad mer ändrades i v2.1.172 utöver nästling?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Det viktigaste i det här avsnittet">

Det viktigaste

Versionen handlar helt om underagenter. Utöver huvudfunktionen innehåller den fyra rättningar av delegeringsinfrastrukturen. En rättning gäller en bugg som kan uppstå vid nästling.

</div>

Öppna hela ändringsloggen för v2.1.172, så ser du att hela versionen handlar om underagenter.

**Rättning 1.** En underagent som körs i bakgrunden markeras inte längre som aktiv i agentpanelen efter att den nästlade underagent som den startade har stoppats. Den här buggen kan bara uppstå vid nästling.

**Rättning 2.** Begränsningar för `availableModels` gäller nu även underagenter. Tidigare kunde underagenter kringgå en begränsning av vilka modeller teamet fick använda (till exempel ett förbud mot opus för att spara pengar) genom en åsidosättning i den egna konfigurationen. Med v2.1.172 gäller regeln överallt.

**Rättning 3.** Uppåtpilen i prompthistoriken visar nu promptar från underagentens **aktuella** flik, inte huvudagentens. En finslipning av observerbarheten.

**Rättning 4.** CPU-användningen i viloläge har minskat: indikatorn `/goal` ritar inte längre om terminalen med 5 Hz i viloläge, och gränssnittet ritas om mer sällan medan parallella underagenter arbetar.

Jag vill påpeka att alla fyra rättningar gäller underagenter. Det betyder att Anthropic släppte hela infrastrukturen för nästling, inte bara en rad i ändringsloggen. Nästling hade redan använts internt på Anthropic en tid före publiceringen.

## Checklista: när nästling hjälper och när det stjälper

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Det viktigaste i det här avsnittet">

Det viktigaste

Gå igenom 6 kontroller innan du startar varje ny underagent. Om minst 3 svar är ”ja, använd djup”, gör det. Om färre svarar ja ska du hålla dig till parallellism eller en enda underagent. Det sparar tokens, nerver och ett par timmar som annars går åt till att förstå vad en kedja med 27 nästlade starter ens höll på med.

</div>

Använd nästling om:

- Uppgiften innehåller en deluppgift med många webbförfrågningar, grep-sökningar eller filläsningar.
- Det är acceptabelt att förlora den deluppgiften (om barnbarnet returnerar ”hittade inget” kan orkestratorn fortsätta).
- Du **inte behöver** mellanresultat i huvudfönstret.
- Du har en `CLAUDE.md` och en sammanställd projektkontext som underagenten kan förlita sig på.
- Du kan tydligt beskriva vad varje nivå ska returnera (indata, utdata, format).
- Du har en Max-plan eller en reserv för ×27 tokens.

Använd inte nästling om:

- En underagent kan lösa uppgiften utan brus.
- Du behöver mellanresultat i huvudfönstret (det betyder att du vill ha parallellism).
- Projektet saknar CLAUDE.md eller bara har knapphändig affärskontext.
- Promptarna på nivå 1 är otydliga (otydligheten mångfaldigas exponentiellt ner genom trädet).
- Du behöver hastighet — parallellism är snabbare än djup för ett jämförbart resultat.
- Du har Pro-planen och arbetar hela dagen — du kommer att förbruka gränsen på ett par timmar.

<div class="section" role="doc-bibliography" aria-label="Källor">

### Källor

- [Claude Code Release v2.1.172 - GitHub Releases](https://github.com/anthropics/claude-code/releases/tag/v2.1.172)
- [Create custom subagents - Claude Code Docs](https://code.claude.com/docs/en/sub-agents)

</div>





Fler material finns på [Ailoot](https://ailoot.ai/).

## Frågor om den här guiden: Så delegerar du en stor uppgift i Claude Code med nästlade underagenter

### Behöver jag skapa claim-extractor för det kopierade receptet?

Nej. Den rättade research-orchestrator tar själv fram upp till fem påståenden ur tillhandahållet material. Skapa de tre visade filerna: research-orchestrator, fact-verifier och web-deep-search; lämna sedan källtext eller URL:er.

### Begränsar bara tillåtna fact-verifier antalet barnstarter?

Nej. En lista över tillåtna agenttyper begränsar vilken typ som får anropas, inte antalet anrop. Receptet begränsar separat den första extraktionen till fem påståenden; följ faktiska anrop och tokenanvändning.


## Ailoot · Företaget och dess projektportfölj

Ailoot bygger på etablerad driftserfarenhet, en stor kundbas, stabil service och löpande KPI-kontroll.

Företaget och dess projektportfölj: miljontals kunder; månatlig försäljning för miljarder.

Ailoot använder denna driftserfarenhet för API-åtkomst till AI-funktioner i kundernas produkter, agenter, applikationer och automatiseringar.
