Sådan delegerer du en stor opgave i Claude Code med indlejrede underagenter

Hvad ændrede sig i Claude Code v2.1.172?#

Hvis du har læst noget om AI-agenter i Claude Code i løbet af de seneste måneder, er du stødt på den samme sætning. Den står i den officielle dokumentation, i min guide om underagenter og i alle konkurrentanalyser. Den lyder sådan: »En underagent kan ikke oprette en anden underagent.« Pr. 11. juni 2026 står den sætning stadig tre forskellige steder på code.claude.com/docs/en/sub-agents. Anthropic har bare ikke opdateret den endnu.

Den 10. juni kl. 20:44 UTC dukkede Claude Code v2.1.172 op på GitHub Releases. Det vigtigste punkt i ændringsloggen var én linje:

Denne udgivelse rettede også en fejl, der kun kunne opstå ved indlejring: En underagent i baggrunden blev ved med at være fremhævet som aktiv i agentpanelet, efter at den indlejrede underagent, den havde startet, allerede var blevet stoppet.

Det er et sjældent tilfælde, hvor den officielle dokumentation stadig modsiger den udgivne version. Næste gang forklarer jeg, hvordan indlejring adskiller sig fra parallelle underagenter, hvad »dybde 5« betyder, og i hvilke tre scenarier det faktisk er nyttigt i dag.

Hvordan adskiller indlejrede underagenter sig fra parallelle og sekventielle?#

Jeg brugte lang tid på at afprøve disse tre tilgange manuelt, og sådan tænker jeg på dem: Delegering har tre dimensioner. Bredde, længde og dybde. Hver af dem løser et forskelligt problem.

Bredde — parallelle underagenter. Hovedchatten starter N uafhængige underagenter på samme niveau. Hver får en afgrænset opgave, arbejder i sit eget isolerede vindue og returnerer kun resultatet. Bredde løser hastighedsproblemet: 5 underagenter, der arbejder parallelt, bliver færdige på den tid, det tager én at udføre det samme arbejde sekventielt. Det er den model, jeg beskrev i min guide om parallelle underagenter med worktrees.

Længde — en kæde af underagenter. A arbejder og giver resultatet videre til B, B arbejder og giver det videre til C. Hver ser inputtet fra den foregående. Længde fastlægger rækkefølgen: B kan ikke begynde, før den får data fra A. Et klassisk eksempel: Først indsamler en research-underagent kilder, derefter skriver en redigerings-underagent en artikel baseret på kilderne, og så kontrollerer en faktatjek-underagent artiklen. Det er en flad sekvens; hovedchatten holder styr på hele forløbet.

Dybde — indlejrede underagenter. A starter B, B starter C, C starter D. Hvert barn arbejder inde i sin forælder, i sit eget isolerede vindue, og returnerer kun resultatet til sin forælder. Hovedchatten ser intet af det, der foregår hos børn, børnebørn og oldebørn. Det er det nye i v2.1.172.

Den største forvirring er, at folk tror, dybde 5 betyder »du kan starte 5 underagenter samtidig«. Det passer ikke. Dybde er et lodret niveau i træet, ikke antallet af samtidige børn. Der kan være én underagent eller hundrede på hvert niveau. Dybde 5 betyder, at delegeringskæden kan gå 5 trin ned: hovedchat → oldebarn-1 → oldebarn-2 → oldebarn-3 → oldebarn-4 → oldebarn-5. Og der kan være forgreninger på hvert niveau.

Version 2.1.172 fjernede reglen om, at en underagent ikke kunne oprette en anden underagent.

Hvis du går efter hastighed, har du brug for bredde. Hvis du har en streng rækkefølge for udførelsen, har du brug for længde. Dybde er nyttig i præcis ét tilfælde: Når en af dine opgaver indeholder en støjende delopgave (15 webanmodninger, gennemgang af logfiler, læsning af et dusin filer). Og du ikke vil have, at støjen oversvømmer dit hovedvindue.

Hvad betyder »5 niveauer i dybden« i praksis?#

Her er et vigtigt punkt om ærlighed. Jeg brugte en halv dag på dokumentation og analyser fra fællesskabet for at finde ud af, at Anthropic ikke har givet en præcis definition. Her er, hvad du skal vide.

Det er en grænse, ikke en indstilling.

Grænsen er indbygget på serversiden. Reverse engineering af klienten v2.1.172 fandt ingen MAX_DEPTH-konstant. Det betyder, at kontrollen foregår et sted i Anthropics API, ikke lokalt på din maskine. Du kan ikke indstille --max-depth 7 for at gøre træet dybere. Du kan heller ikke indstille --max-depth 2 for at fastsætte en lavere, sikrere grænse. Den eneste kontrol, du har, er tilladelseslisten Agent(agent_type) i frontmatter, men den begrænser typerne af underagenter, ikke dybden.

Anthropic har ikke præcist defineret, hvad »5« betyder. Det er det andet vigtige punkt:

Anthropic har ikke præciseret, hvad “5” betyder. De officielle kilder angiver ikke, om depth=5 betyder fem niveauer under roden eller fem agenter i alt, inklusive roden.

Tredjepartsintegrationer fortolker det forskelligt indtil videre. ADR-147 i projektet ruvnet/ruflo antager »5 underniveauer under roden = 6 agenter i kæden«. Jeg bruger samme konvention i mine eksperimenter: Hovedchatten er niveau 0, dens direkte børn er niveau 1 og så videre op til niveau 5. Men det er ikke dokumenteret i den offentlige dokumentation.

Grænsen er allerede aktiveret, uden flag. Du behøver ikke aktivere noget. Når du har opdateret Claude Code til v2.1.172, kan du tilføje Agent til en underagents tools, og den vil starte endnu en underagent. Det afgørende er, at den overordnede agent skal tillade det (tools: Agent(...)).

Hvor foregår din delegering i dag: i bredden, længden eller dybden?#

Gå dine seneste 5 prompts igennem. Hvor ofte har du gjort det her: En opgave begynder, Claude starter med at søge i filer med grep, laver 10 webanmodninger, dumper en hel mur af logfiler i konteksten — og 20 minutter senere opdager du, at vinduet er fyldt. Det endelige svar bliver allerede genereret med et sparsomt tokenbudget, fordi 70 procent af konteksten blev brugt på mellemliggende dumps.

Det er et scenarie, hvor du har brug for dybde. Ikke parallelisering eller en kæde — dybde. Hovedchatten bør delegere »research« til én underagent, som derefter starter sine egne børn indefra til specifikke websøgninger, fillæsninger og grep-søgninger. Børnene returnerer kun destillerede vurderinger. Et oldebarn fortæller sin forælder: »fandt det, bekræftet« eller »fandt det ikke, årsag X«. Forælderen samler det i ét resumé og returnerer det til dig. Hovedchatten forbliver ryddelig.

Før den 9. juni efterlignede jeg det manuelt. Jeg åbnede en anden Claude Code-instans, kopierede prompten »undersøg det her«, kørte den og overførte derefter resultatet manuelt tilbage til hovedvinduet. Jeg beskrev denne opsætning i detaljer i min guide om delegering af kodning til mange AI-agenter. Med v2.1.172 kan du beskrive den direkte i orkestratorens systemprompt — Claude bygger selv træet.

Vil du forstå indlejrede underagenter og samtidig opbygge en opsætning, der gør Claude pålidelig? Indlejring er kun én byggesten. Den fulde opsætning indeholder alle tre søjler: AI-klon + Anden hjerne + Kontekstteknik — det er det, der gør Claude til et pålideligt værktøj i stedet for »en assistent, der hallucinerer«.

I hvilke 3 scenarier er indlejrede underagenter faktisk nyttige?#

Scenarie 1. Dyb research med faktatjek

Forestil dig, at du samler materiale til en artikel eller et salgstilbud. Først skal du hente 5–10 påstande fra offentlige kilder og derefter verificere hver enkelt — finde den oprindelige kilde, sikre dig, at citatet er nøjagtigt, og beregne de faktiske tal.

Før v2.1.172 havde du to muligheder. Enten gjorde du det hele med én underagent, som sled sig igennem 30 webanmodninger og fyldte sin kontekst med det hele. Eller også delte du det op manuelt: én prompt til at udtrække påstandene og derefter en løkke over påstandene, hvor du startede en separat underagent for hver enkelt. Hovedchatten blev fyldt med mure af mellemliggende lister.

I opskriften nedenfor delegerer hovedchatten til research-orchestrator (niveau 1). Orkestratoren udtrækker selv påstande, sender hver til fact-verifier (niveau 2), og hver faktatjekker delegerer fokuserede søgninger til web-deep-search (niveau 3). Hovedchatten modtager kun en liste over verificerede påstande med kilder. Alt andet bliver i børnenes vinduer og kommer aldrig ind i din kontekst.

Scenarie 2. Analyse af et stort repository

Du har fået udleveret et projekt med 200 filer. Du skal forstå arkitekturen, finde de vigtigste moduler og vurdere den tekniske gæld. Kør Glob plus et dusin Read-kald manuelt, så fylder du vinduet på 10 minutter.

Dybde løser det sådan: Hovedchatten starter en »arkitekt«-underagent. Arkitekten starter internt tre børn — ét undersøger mappestrukturen (kører Glob og opsummerer), det andet læser 5 centrale konfigurationsfiler, og det tredje søger efter de vigtigste mønstre med grep. Hver returnerer et kortfattet resumé til arkitekten. Arkitekten samler billedet og giver hovedchatten en endelig rapport på en halv skærm. Du får et kort over projektet uden at oversvømme konteksten med en mur af cat-output fra alle filerne.

Scenarie 3. Analyse af end-to-end-afhængigheder

Du ændrer et databaseskema, en API-kontrakt eller en fælles konfigurationsfil. Du skal forstå, hvor virkningerne vil vise sig. Denne opgave tømmer konteksten hurtigst, fordi der er mange afhængigheder, og hver enkelt skal kontrolleres i kildekoden.

Med dybde starter hovedchatten en impact-analyzer (niveau 1). Den starter en dependency-tracer for hver berørt fil (niveau 2). Hver tracer starter internt en consumer-finder (niveau 3), som søger i kodebasen med grep efter forbrugere af den afhængighed. Hver returnerer kun hovedpointen: »disse tre steder går i stykker«. Hovedchatten samler en tabel med »berørte filer → påvirkning« uden at kende grep-resultaterne.

Sådan opsætter du indlejrede underagenter på 10 minutter#

Trin 1. Sørg for, at du bruger v2.1.172 eller nyere.

claude --version

Hvis versionen er ældre, skal du opdatere. Udgivelsens vigtigste funktion beskrives med én linje i ændringsloggen: »Underagenter kan nu oprette deres egne underagenter, op til 5 niveauer ned« (hele teksten).

Trin 2. Opret en overordnet agent, der kan starte børn.

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

---
name: research-orchestrator
description: Delegerer research med grundigt faktatjek
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---

Du er en research-orkestrator. Når du får et emne:
1. Læs det leverede materiale, eller hent de leverede offentlige kilde-URL’er.
   Udtræk selv højst 5 konkrete påstande. Registrér for hver påstandstekst,
   kilde-URL eller fil og det præcise understøttende uddrag.
   Bed om kildematerialet før delegering, hvis intet er leveret.
2. Kald fact-verifier for hver påstand — den opretter selv
   sine egne underagenter til websøgning og kontrol.
3. fact-verifier returnerer kun de endelige vurderinger til dig —
   indlæs ikke mellemliggende dumps i din kontekst.

Den endelige rapport må kun være en liste { claim, sources[], confidence }.

Linjen tools giver kun adgang til undertypen fact-verifier. Udtræk af påstande er orkestratorens eget første trin, så der kræves ingen udefineret claim-extractor-fil. En typetilladelsesliste begrænser, hvilken underagent der må kaldes; den begrænser ikke, hvor mange gange typen startes. Hold opskriften afgrænset til højst fem udtrukne påstande.

Trin 3. Opret en underagent, der selv kan starte oldebørn.

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

---
name: fact-verifier
description: Kontrollerer påstande gennem underagenters websøgninger
tools: Agent(web-deep-search), Read
model: sonnet
---

Du er faktatjekker. Når du får en påstand:
1. Formulér 2-3 søgeforespørgsler.
2. Kør web-deep-search for hver — den udfører selv
   WebSearch og WebFetch og returnerer verificerede uddrag.
3. Saml det i én vurdering: { claim, sources[], confidence }.

Kan du se den vigtige del? tools siger igen Agent(web-deep-search). Det betyder, at faktatjekkeren (niveau 2 i vores træ) selv kan starte en anden underagent (niveau 3). Tidligere havde denne linje ingen effekt — dokumentationen indeholder stadig formuleringen:

Med v2.1.172 er den linje forældet. Syntaksen er den samme, men nu fungerer den på alle dybder i træet.

Trin 4. Opret et oldebarn.

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

---
name: web-deep-search
description: Udfører websøgning og returnerer uddrag
tools: WebSearch, WebFetch
model: haiku
---

Du har fået en søgeforespørgsel. Udfør WebSearch, vælg de 3 mest relevante URL'er, og brug WebFetch til at hente ordrette belæg for påstanden. Returnér en liste { url, snippet, supports_claim: yes|no }.

Oldebarnet har ikke Agent i tools, så det starter ikke flere agenter længere nede i træet.

Trin 5. Kør orkestratoren.

claude --agent research-orchestrator

Lever derefter kildeteksten eller offentlige kilde-URL’er i chatten: »Udtræk og verificér højst 5 konkrete påstande fra disse kilder; returnér påstande, kilder og sikkerhedsvurdering.« Med --agent research-orchestrator er selve sessionen orkestratoren; dens faktatjekker- og søgebørn tilføjer to delegerede niveauer under den. Hvis en almindelig hovedsession i stedet delegerer til orkestratoren, er der tre delegerede niveauer under hovedsessionen.

Hvilke 5 anti-mønstre spilder tokens og ødelægger observerbarheden?#

Anti-mønster 1. Opgaven passer i ét vindue.

Hvis én underagent kan klare det uden støj, skal du ikke tilføje niveauer: indlejring tilføjer unødige omkostninger og forsinkelser.

Anti-mønster 2. Du søger hastighed i stedet for isolering.

Hvis du vil have hastighed, har du brug for parallelisering, ikke dybde. Start 5 underagenter side om side på samme niveau i stedet for at bygge en kæde. Dybde er til at flytte støjende forberedende arbejde ind i et børnevindue, ikke til at øge hastigheden.

Anti-mønster 3. Arbejdet er grundlæggende overfladisk.

»Find denne fil, og vis mig den« er en forespørgsel i to trin; den har ikke brug for et hierarki i tre niveauer. Indlejring kan betale sig, når en opgave indeholder en støjende delopgave. Hvis der ikke er støj, skal du ikke tilføje underagenter.

Anti-mønster 4. Vage prompts på første niveau.

Det er det farligste scenarie. Hvis du giver orkestratoren på niveau 1 en vag prompt, bliver vagheden mangedoblet. Én vag prompt på niveau 1 bliver til 4 vage prompts på niveau 2 og 16 på niveau 3. Når oldebørnene begynder at arbejde, ved de ikke engang, hvad de leder efter.

Anti-mønster 5. Geometrisk omkostningsvækst.

Det vigtigste økonomiske argument: indlejring multiplicerer tokenforbruget, og multiplikationen vokser med dybden.

Et groft regnestykke: En kæde med dybde 3 og en forgrening på 3 på hvert niveau giver 27 underagenter. Det er mindst 27 gange flere tokens end en simpel forespørgsel. Med Claude Pro-planen bruger det regnestykke dagsgrænsen på et par timer. Hvis du har en Max-plan, bruger du en uges kvote på én dag.

Bonus-anti-mønster (min erfaring): »50 agenter, der laver meningsløst arbejde«.

Når jeg ser på andres projekter, ser jeg ofte dette: »Jeg har 50 agenter i gang.« Jeg spørger, hvad de laver. Og de 50 agenter laver meningsløst arbejde. De genererer bunker af unødvendigt output, masser af rå resuméer, dubletter og mure af logfiler. Hver især gør noget »nyttigt i almindelighed«, og resultatet er en oversvømmet kontekst og en tokenregning som hos en lille virksomhed. Dybde 5 løser ikke problemet — det gør det værre. Hvis det allerede på niveau 1 er uklart, hvem der gør hvad, betyder dybde 5 fem niveauer af forvirring.

Før du starter en underagent, kan du teste den ved at besvare 4 spørgsmål på et halvt minut:

• Hvad gør den helt præcist (i én sætning)?
• Hvilke filer berører den?
• Hvad returnerer den til sin forælder?
• Hvem kontrollerer den?

Hvis du ikke kan svare på 30 sekunder, bør denne underagent ikke eksistere. Jeg forklarede denne regel separat i min guide om parallelle underagenter.

Hvorfor betyder indlejring uden kontekstteknik 5 niveauer af hallucinationer?#

Det er her, folk ofte spørger: »Jeg opdaterede Claude Code, tilføjede Agent til tools, og træet bliver bygget — men det endelige svar er stadig forkert. Hvorfor?«

Svaret er enkelt. Hver underagent i Claude Code starter helt forfra. Fra den officielle dokumentation:

På niveau 1 er det håndterbart: Orkestratoren giver sit barn en kort opgavebeskrivelse. Men på niveau 3 får oldebarnet en delegeringsbesked fra sin forælder, som også kun havde fået en delegeringsbesked. Hver videregav kun en smule. På niveau 5 har du en underagent, hvis vindue indeholder sætningen »kontrollér påstand X« og intet andet. Den ved ikke, hvilket projekt den arbejder på, hvilken opgave den løser, eller hvad den skal fokusere på.

Uden CLAUDE.md er et oldebarn på niveau fem som en medarbejder, der møder ind på kontoret for første gang i sit liv uden nogen introduktion. Den vil gøre noget, fordi den har fået en opgave. Men det bliver ikke det, projektet har brug for.

Derfor er opsætningen afgørende. Dybde 5 uden en korrekt konfigureret CLAUDE.md, business/ og en færdighedspipeline er et kasino. Med dem er det et værktøj. Denne opsætning beskrives som »De tre søjler«: AI-klon + Anden hjerne + Kontekstteknik. Hver af dem fungerer dårligt alene; tilsammen gør de indlejring til et reelt nyttigt værktøj.

Hvad ændrede sig ellers i v2.1.172 ud over indlejring?#

Åbn hele ændringsloggen for v2.1.172, så kan du se, at hele udgivelsen handler om underagenter.

Rettelse 1. En underagent i baggrunden bliver ikke længere ved med at være »fastlåst« som aktiv i agentpanelet, efter at den indlejrede underagent, den startede, er blevet stoppet. Denne fejl kan kun forekomme ved indlejring.

Rettelse 2. Begrænsningerne for availableModels gælder nu også underagenter. Tidligere kunne underagenter omgå reglen med en tilsidesættelse i deres egen konfiguration, hvis du begrænsede, hvilke modeller teamet måtte bruge (for eksempel ved at forbyde opus for at spare penge). Med v2.1.172 gælder reglen alle steder.

Rettelse 3. Pil op i prompthistorikken viser nu prompts fra underagentens aktuelle fane, ikke hovedagentens. En finpudsning af observerbarheden.

Rettelse 4. CPU-forbruget i tomgang er reduceret: /goal-indikatoren tegner ikke længere terminalen om med 5 Hz i tomgang, og brugerfladen tegnes sjældnere om, mens parallelle underagenter arbejder.

Jeg vil påpege, at alle fire rettelser vedrører underagenter. Det betyder, at Anthropic udgav hele infrastrukturen til indlejring, ikke bare én linje i ændringsloggen. Indlejring havde allerede været brugt internt hos Anthropic i nogen tid før offentliggørelsen.

Tjekliste: hvornår indlejring hjælper, og hvornår det skader#

Brug indlejring, hvis:

• Opgaven indeholder en delopgave med mange webanmodninger, grep-søgninger eller fillæsninger.
• Det er acceptabelt at miste den delopgave (hvis oldebarnet returnerer »fandt intet«, kan orkestratoren fortsætte).
• Du ikke har brug for mellemliggende resultater i hovedvinduet.
• Du har en CLAUDE.md og samlet projektkontekst, som underagenten kan støtte sig til.
• Du tydeligt kan beskrive, hvad hvert niveau returnerer (input, output, format).
• Du har en Max-plan eller plads til ×27 tokens.

Brug ikke indlejring, hvis:

• Én underagent kan løse opgaven uden støj.
• Du har brug for mellemliggende resultater i hovedvinduet (så har du brug for parallelisering).
• Projektet ikke har en CLAUDE.md eller kun har sparsom forretningskontekst.
• Prompts på niveau 1 er vage (vagheden vil mangedobles eksponentielt ned gennem træet).
• Du har brug for hastighed — parallelisering er hurtigere end dybde for et sammenligneligt resultat.
• Du har Pro-planen og arbejder hele dagen — du bruger grænsen op på et par timer.

Komplet kontekstworkflow: AI-klon + Anden hjerne + Kontekstteknik.

Du kan finde mere materiale på Ailoot.