Claude Code-subagenter: struktur, fem roller og orkestrering

Hvad er en subagent i Claude Code, og hvorfor er den ikke "bare endnu en Skill"?#

Claude Code-dokumentationen definerer det sådan:

Sagt på en måde, som en iværksætter ville forstå: Forestil dig et ejendomsmæglerfirma. Der er en direktør, en marketingmedarbejder, en jurist og salgschefer. En medarbejder, der skifter mellem alle disse roller, er ikke et team; det er en overbelastet person. Et team opstår, når hver person har sin egen kontekst og sit eget ansvarsområde, mens direktøren kun fordeler opgaver og samler resultaterne.

Subagenter i Claude Code fungerer på samme måde. Hovedchatten er direktøren. En subagent er en specialist med en afgrænset opgave, sin egen kontekst og sit eget sæt værktøjer. Når en opgave passer til specialistens beskrivelse, delegerer direktøren den – uden at fortabe sig i detaljerne.

5 formål, som Anthropic skabte subagenter til

Anthropics dokumentation nævner præcis fem grunde til at oprette sin egen subagent:

Det mest praktiske punkt på listen for en ikke-programmør er omkostningsstyring. Du kan sende en omfattende researchopgave til den billige Haiku-model, mens du fortsætter hovedsamtalen på Sonnet eller Opus. Tokenbesparelserne er direkte proportionale.

Kontrollér understøttelse af indlejring for den installerede version

Skabelonerne i guiden bruger én hovedsession, som delegerer direkte til hjælpere. Behandl ikke ældre dokumentation om, at “subagenter ikke kan oprette andre subagenter”, som en tidløs regel: Indlejringsadfærd afhænger af installeret version og tilladte værktøjer. Den separate guide til indlejrede subagenter gennemgår en versionsspecifik opskrift. Verificér understøttelsen i din installation, før du planlægger dybere delegering.

Hvordan adskiller en subagent sig fra en Skill, en slash-kommando og en hook?#

Den tidligere guide om Skills forklarer, at Skills og slash-kommandoer i Claude Code reelt er slået sammen i ét format. Men en subagent er noget andet – ikke bare "en større Skill".

En oversigtstabel over de fire mekanismer:

En god formulering i en engelsksproget guide er: Skills er opskrifter; subagenter er specialiserede kolleger.

Put enkelt: skills er opskrifter; subagenter er specialiserede kolleger.

I praksis fungerer det sådan: Skills aktiveres automatisk, når deres beskrivelse passer til opgaven, mens subagenter kaldes eksplicit – enten beslutter hovedchatten at delegere, eller også kalder du en ved navn.

Beslutningstræ: "Hvilken skal jeg vælge?"

Når du tænker: "Jeg har brug for, at Claude gør X", så stil dig selv disse fire spørgsmål:

1. Er det viden, der altid skal være tilgængelig? For eksempel: "Vi lokaliserer til brugerens foretrukne sprog" eller "Vi bruger ikke em-dash". Skriv det i CLAUDE.md.
2. Er det en metode, der aktiveres af en udløser, og som du udfører manuelt nu? For eksempel: "Jeg skriver en salgsrapport hver mandag." Opret en Skill.
3. Er det en opgave, der vil optage hovedchattens kontekst, eller kan den køres parallelt? For eksempel: "grundig research på tværs af 30 kilder" eller "en sikkerhedsrevision, mens jeg skriver en ny funktion". Opret en subagent.
4. Har du brug for en automatisk reaktion på en hændelse i Claude Code? For eksempel: "kør lint efter hver Edit". Skriv en hook.

90% af en iværksætters opgaver falder i de første to kategorier. Subagenter er et værktøj på næste niveau, når du går fra "én opgave ad gangen" til orkestrering.

Hvor findes subagenter, og hvilken har forrang?#

Subagenthierarkiet har fem niveauer, ordnet fra højeste til laveste prioritet:

Prioritetslogikken er den samme som for Skills og CLAUDE.md: Organisationen tilsidesætter CLI, CLI tilsidesætter projekt, projekt tilsidesætter personlig, og personlig tilsidesætter plugin.

Hvad du skal vide om indlæsning

Subagenter indlæses, når en Claude Code-session starter. Hvis du redigerer en agentfil manuelt på disken, bliver ændringerne først indlæst, når du genstarter sessionen. Ændringer via det interaktive /agents-UI træder i kraft med det samme.

Én subagent pr. område betyder én fil. Hvis .claude/agents/ indeholder code-reviewer.md og endnu en code-reviewer.md ved siden af (for eksempel fra en gammel sikkerhedskopi), ignorerer Claude Code den ene uden varsel. Der vises ingen meddelelse.

Subagenter i plugins er en særskilt sag. De har sikkerhedsbegrænsninger: De understøtter ikke felterne hooks, mcpServers og permissionMode. Det forhindrer installation af et tredjepartsplugin i at give det tilladelse til at køre vilkårlig kode på din maskine.

Sådan er en subagentfil opbygget: frontmatter og brødtekst#

Et minimalt eksempel fra den officielle dokumentation – kun 9 linjer:

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

Du er kodegransker. Når du kaldes, analyserer du koden og giver
konkret, handlingsrettet feedback om kvalitet, sikkerhed og bedste praksis.

Det er nok. Hvis en bruger siger "gennemgå min PR" i hovedchatten, matcher Claude "gransker / kode / kvalitet" med beskrivelsen og delegerer til subagenten. Subagenten læser diffen, skriver kommentarer og returnerer en opsummering til hovedchatten. Hovedchatten bliver ikke fyldt med logfiler og mellemliggende analyser.

Fuldt frontmatter-skema

Feltet model: haiku er netop den "omkostningsstyring" fra listen over fem formål. Hvis du har en researchagent, der læser 50 sider dokumentation, kan du køre den på Haiku og spare 5–7 gange sammenlignet med Opus.

Feltet isolation: worktree håndterer et vigtigt problem: En subagent foretager potentielt farlige ændringer (refaktorering, migrering), men du vil ikke have, at den rører din arbejdskopi. Indstil isolation: worktree, så opretter Claude Code en midlertidig git-kopi af projektet; subagenten arbejder dér og returnerer en diff til gennemgang.

Filens brødtekst er systemprompten

Efter frontmatter kommer almindelig Markdown – det er subagentens systemprompt. Der kræves ingen særlig struktur, men dette er et gennemprøvet mønster:

1. Hvem du er – én sætning: "du er kodegransker", "du er sikkerhedsrevisor", "du vedligeholder dokumentation".
2. Hvornår du bliver kaldt, og hvad du gør først – de første 2–3 handlinger, efter du har modtaget opgaven.
3. En tjekliste over kontroller eller trin – 5–10 punkter, som subagenten følger.
4. Hvad du returnerer – formatet for den endelige rapport. Det er afgørende: Hvis du ikke angiver et format, producerer subagenten et "essay" i stedet for en struktureret opsummering.
5. Hvad du IKKE gør – udtrykkelige begrænsninger. Uden dette afsnit begynder subagenten at improvisere.

Hold filens brødtekst på 200–500 linjer. Hvis den bliver længere, så flyt lange referencer til separate nærliggende filer, og link til dem i prompten.

Sådan skriver du en beskrivelse, der får Claude til helt sikkert at kalde din subagent#

Et almindeligt problem er at sætte en subagent op til kodegennemgang, men Claude gør alting selv uden at bruge agenten. Der er som regel én årsag: Beskrivelsen er skrevet som "Hjælper med kodegennemgang". Claude forstår ikke, hvornår den skal aktiveres.

Formel for en effektiv beskrivelse (3 dele)

Del 1 – hvad den gør. Én sætning om resultatet, ikke processen. Ikke "analyserer kode", men "finder sårbarheder i kode og returnerer en liste med alvorlighedsgrad og en løsning".

Del 2 – hvornår den skal aktiveres. 3–5 fraser i anførselstegn, sådan som brugerne rent faktisk formulerer deres ønsker. Gæt ikke – se på din chathistorik og de formuleringer, der faktisk bruges.

Del 3 – hvornår den IKKE skal aktiveres. 1–2 fraser om lignende opgaver, som denne subagent ikke skal reagere på. Uden dette afsnit kommer to lignende agenter konstant i konflikt.

Den magiske frase "Use Proactively"

Anthropics officielle dokumentation kommer med en direkte anbefaling:

Med andre ord er Claude som udgangspunkt tilbøjelig til ikke at kalde en subagent, hvis beskrivelsen ikke indeholder tydelige signaler. Tilføj "use proactively" eller "use immediately after writing code", så stiger aktiveringen markant.

En stærk beskrivelse ser sådan ud

description: |
  Expert code review specialist. Proactively reviews code for quality,
  security, and maintainability. Use immediately after writing or
  modifying code. Returns prioritized list of issues with severity
  and fix recommendations.
  Do not invoke for documentation changes, README edits, or commit
  message rewrites - these are handled by doc-maintainer.

Det, der fungerer her:

• Verberne "reviews" + "returns" angiver et konkret resultat, ikke en proces.
• "Proactively" og "immediately after" er eksplicitte udløsere.
• "Do not invoke for..." afgrænser konflikten med en lignende subagent.
• Engelsk i beskrivelsen er standard. Claude matcher bedre på engelsk.

5 subagentroller, der er klar til brug og virker på 10 minutter#

Hver rolle nedenfor er en enkelt fil, .claude/agents/<name>.md. Når du har oprettet filen, skal du genstarte Claude Code, åbne /agents og kontrollere, at den nye agent vises på listen. Derefter kan du kalde den med @agent-name.

1. code-reviewer – gennemgå kode efter hver ændring

Dette er det officielle eksempel fra Anthropics dokumentation, tilpasset en arbejdsproces:

---
name: code-reviewer
description: |
  Expert code review specialist. Proactively reviews code for quality,
  security, and maintainability. Use immediately after writing or
  modifying code.
tools: Read, Grep, Glob
model: inherit
color: blue
---

Du er senior kodegransker og sikrer en høj standard for kodekvalitet.

Når du bliver kaldt:
1. Læs diffen og listen over ændrede filer fra hovedsessionen. Bed hovedsessionen levere dem, hvis de mangler.
2. Brug Read, Grep og Glob til at undersøge de relevante filer.
3. Returnér fund uden at ændre filer eller køre shellkommandoer.

Tjekliste til gennemgang:
- Koden er tydelig og letlæselig
- Funktioner og variabler har gode navne
- Ingen duplikeret kode
- Korrekt fejlhåndtering
- Ingen eksponerede hemmeligheder eller API-nøgler
- Inputvalidering er implementeret
- Testdækningen er tilstrækkelig
- Der er taget højde for ydeevne

Giv feedback opdelt efter prioritet:
- Kritiske problemer (skal løses før merge)
- Advarsler (bør løses)
- Forslag (overvej at forbedre)

Format: for hvert problem – fil:linje + 1 sætning om, hvorfor det er et problem + konkret løsning.

Nøglen er tools: Read, Grep, Glob: Granskeren har fil-læse- og søgeværktøjer uden adgang til Bash, Write eller Edit. Hovedsessionen forbereder diffen og sender den til granskeren. En instruktion om kun at køre git diff begrænser ikke et fuldt tildelt Bash-værktøj.

2. security-auditor – find sårbarheder og læk

Rollen bruger opus til dybere ræsonnement og samme begrænsning til Read, Grep og Glob. Vedvarende hukommelse er udeladt i denne skrivebeskyttede skabelon, fordi agenthukommelse også giver mulighed for at skrive hukommelse:

---
name: security-auditor
description: |
  Security audit specialist. Use proactively to find OWASP Top 10
  vulnerabilities, exposed secrets, injection risks, broken auth.
  Run before any deploy or merge to main.
tools: Read, Grep, Glob
model: opus
color: red
---

Du er sikkerhedsrevisor. Find sårbarheder, der kan udnyttes, ikke stilproblemer.

Tjekliste til revision:
- SQL- / NoSQL-injektion
- XSS (lagret, reflekteret, DOM-baseret)
- CSRF- / SSRF-risici
- Hårdkodede hemmeligheder (API-nøgler, tokens, adgangskoder)
- Defekt godkendelse / sessionsstyring
- Usikker deserialisering
- Manglende inputvalidering
- Path traversal
- Åbne omdirigeringer
- Usikre direkte objektreferencer (IDOR)

For hvert fund:
- Alvorlighedsgrad: Critical / High / Medium / Low
- Fil:linje
- Angrebsscenarie i 1–2 sætninger
- Anbefalet løsning med kodeeksempel

Spring støj fra linter og stil over. Rapportér kun sårbarheder, der kan udnyttes.

Skrivebeskyttet med hensyn til værktøjer og med model: opus til komplekse kontroller som sårbarhedskæder.

3. research-agent – grundig research i 8+ kilder

Anthropic beskriver selv dette mønster i sin artikel om deres multi-agent-researchsystem. Nøglen er et eksplicit outputformat og et forbud mod at dumpe råresultater:

---
name: research-agent
description: |
  Deep web research specialist. Use proactively for fact-finding,
  competitive analysis, gathering external documentation, comparing
  approaches across multiple sources.
tools: WebFetch, WebSearch, Read, Write
model: sonnet
maxTurns: 30
color: purple
---

Du er researchanalytiker. Målet er en sammenfattet briefing, ikke rå søgedumps.

Proces:
1. Del spørgsmålet op i 3–5 underspørgsmål
2. WebSearch for hvert underspørgsmål, hent de øverste 3–5 kilder for hvert spørgsmål
3. Krydstjek påstande mod mindst 2 uafhængige kilder
4. Afvis SEO-farme og aggregatorindhold; foretræk primære kilder
5. Citér ordret med URL-tilskrivning for konkrete påstande
6. Returnér: TL;DR (3 punkter) + fund + kilder (mindst 8 domæner)

Antimønstre, der skal undgås:
- Henvis ikke til en oplysning fra kun én kilde
- Omskriv ikke citater, som om de var ordrette
- Returnér ikke rå søgeresultater til den overordnede agent
- Medtag ikke fyld i indledning eller afslutning ("Hope this helps")

maxTurns: 30 er en sikkerhedsforanstaltning mod, at researchen fortsætter i uendelige iterationer. Anthropic angiver dette tal i sit multi-agent-system:

Halvfems procent henviser til researchopgaver i benchmarks. I praksis er gevinsten mindre ved virksomhedsopgaver, men størrelsesordenen er omtrent den samme.

4. doc-maintainer – hold dokumentationen synkroniseret med koden

Denne rolle bruger model: haiku – et typisk eksempel på "omkostningsstyring". Dokumentation kræver ikke Opus; Haiku klarer opgaven til en tredjedel af prisen:

---
name: doc-maintainer
description: |
  Documentation sync specialist. Use after merging features to update
  README, API docs, CHANGELOG. Reads recent commits, identifies
  undocumented changes, updates docs proactively.
tools: Read, Write, Edit, Glob, Grep, Bash
model: haiku
memory: project
color: green
---

Du holder dokumentationen synkroniseret med koden.

Når du bliver kaldt:
1. Kør `git log --since="last release"` for at se de seneste ændringer
2. Læs README.md, docs/, CHANGELOG.md
3. Find mangler: nye funktioner uden dokumentation, fjernede API'er, der stadig er dokumenteret, versionsforskelle

Output:
- Opdaterede filer (brug Edit, ikke Write – bevar den eksisterende struktur)
- CHANGELOG.md-post i Keep-A-Changelog-format
- Liste over ændringer, du har foretaget (faktisk diff-opsummering, ikke omskrivning)

Stilregler:
- Aktivt sprog, nutid
- Kodeeksempler skal kunne kopieres og indsættes
- Intet marketingsprog ("powerful", "robust", "seamless")
- Intet fyld ("This guide will help you...")

5. refactor-agent – sikker refaktorering gennem et worktree

Denne rolle bruger isolation: worktree – subagenten arbejder i en separat kopi af repository'et, og du merger kun ændringerne, hvis de ser gode ud:

---
name: refactor-agent
description: |
  Safe refactor specialist. Use for renames, extracts, inlines that
  shouldn't touch your working copy until reviewed. Runs in a
  temporary git worktree.
tools: Read, Edit, Write, Bash, Grep, Glob
model: sonnet
isolation: worktree
permissionMode: acceptEdits
color: yellow
---

Du refaktorerer kode uden at ændre adfærd.

Strenge regler:
1. Test skal bestå FØR og EFTER refaktoreringen.
   Hvis testene fejler før refaktoreringen: STOP og rapportér.
2. Én atomar refaktorering pr. commit (udtræk, omdøb, inline).
3. Ændr aldrig offentlige API'er uden udtrykkelig instruktion.
4. Ændr aldrig tests, medmindre de direkte tester den refaktorerede implementering.

Proces:
- Kør testpakken -> baseline
- Foretag en atomar refaktorering
- Kør testpakken -> verificér
- Commit med en konventionel meddelelse: refactor(scope): what

Returnér: opsummering af ændringer + worktree-sti, så brugeren kan sammenligne og merge.

Med denne rolle forsvinder det mest smertefulde refaktoreringsproblem – "Jeg ødelagde det og ved ikke, hvordan jeg ruller tilbage": Den oprindelige kopi forbliver uberørt, og subagenten arbejder i et isoleret worktree.

Vil du ikke bare kopiere færdige subagenter, men sammensætte en kombination, der gør Claude til et stabilt værktøj? Subagenter er en del af din AI-klon: en måde at give Claude et specialiseret team, der arbejder efter din logik. Metodens tre søjler er: AI-klon (Skills + Subagenter) + Second Brain + kontekstarbejde. Denne kombination forvandler Claude fra en assistent, der gætter, til et værktøj, der tænker efter din logik.

Sådan starter du 5 subagenter parallelt: orkestrator + arbejdere#

Parallel orkestrering er en opsætning med "dirigent + orkester". Dirigenten holder planen, skriver ikke noderne og kontrollerer, hvad musikerne spiller. Hvis nogen spiller en forkert tone, beder dirigenten dem spille den igen i stedet for at forsøge at gøre arbejdet færdigt for dem.

For en iværksætter er en mere nærliggende sammenligning et marketingbureau, der udarbejder en strategi for en ny kunde. Én analytiker laver en SWOT, en anden analyserer konkurrenter, en tredje udarbejder en målgruppeprofil, en senioranalytiker sorterer hypoteser fra, der ikke passer til budgettet, og projektlederen samler den endelige præsentation. I Claude Code begynder denne proces med én sætning – og kritikeren er indbygget i processen i stedet for at komme til efterfølgende.

Minimal orkestreringsprompt

Én sætning i hovedchatten er nok:

Start fem subagenter parallelt: tre research-agents på forskellige kilder
(Anthropic-dokumentation, GitHub-repositorier, AI-bloggere), én critic-agent til at sortere
svage konklusioner fra og én summary-agent til det endelige dokument.

Kontekst: Jeg skriver en guide om X. Mållængde: 2,000 ord med kilder.
Før arbejdet begynder, læser hver agent CLAUDE.md.

Claude delegerer derefter til de fem agenter. Hver arbejder i sin egen kontekst: Research-agenterne bruger deres respektive kilder, kritikeren sorterer, og summary-agenten samler resultatet. Kun endelige opsummeringer vender tilbage til hovedchatten.

Hvornår kan parallelisering betale sig?

Ikke altid. Parallel eksekvering giver kun mening, når:

1. Opgaverne er uafhængige. Hvis research-agent #2 venter på resultatet fra research-agent #1, er der ingen parallelisering – de arbejder reelt sekventielt.
2. Opgaverne tager lang tid. Det er meningsløst at parallelisere "fjern efterfølgende blanktegn"; omkostningen ved at starte subagenter vil æde gevinsten.
3. Du har tilstrækkelige begrænsninger. Mere om dette i et særskilt afsnit nedenfor – parallelle subagenter bruger hurtigt mange tokens.

Anthropics multi-agent v2: et skridt videre

I maj 2026 udgav Anthropic Multi-Agent Orchestration v2 med tre vigtige forskelle fra den klassiske tilgang med at starte parallelle subagenter. Mere om det i næste afsnit.

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

Multi-Agent Orchestration: fælles filsystem + check-ins midt i arbejdsforløbet

Anthropic beskriver funktionen sådan:

Den vigtigste forskel fra klassiske subagenter er et fælles filsystem. Før arbejdede hver subagent helt isoleret, og udvekslingen skete kun gennem den returnerede opsummering. Nu kan specialister skrive til en fælles mappe, og lead-agenten læser resultaterne, efterhånden som arbejdet skrider frem, ikke kun til sidst. Det løser problemet med, at "alle arbejdede hele dagen, og til sidst viste det sig, at to personer havde uforenelige tilgange".

Dernæst kommer check-ins midt i arbejdsforløbet. Lead-agenten kan holde pause og spørge enhver specialist "hvordan går det?" og derefter justere den overordnede plan. Det minder om den måde, en rigtig teamleder arbejder på.

Outcomes: en vurderingsrubrik i stedet for trin-for-trin-instruktioner

Med Outcomes skriver du succeskriterier, og agenten finder en måde at opfylde dem på. En separat grader kontrollerer resultatet i sin egen kontekst, så det ikke "forurenes" af hovedagentens ræsonnering.

Ti procent på udfordrende opgaver er en betydelig gevinst. Især når en opgave formuleres som "sammensæt en lang artikel, der opfylder disse kvalitetskriterier" i stedet for "følg trin 1–7".

Dreaming: Agenter opbygger erfaring mellem sessioner

Dette er den mest konceptuelt nye funktion. En agent gennemgår tidligere sessioner, finder mønstre i succeser og fejl og opdaterer hukommelseslageret. Du kan indstille manuel gennemgang, før ændringerne anvendes, eller lade agenten redigere hukommelsen selv.

Anthropic rapporterer, at Harvey (en juridisk teknologivirksomhed) oplevede omtrent en seksdobling af succesraten på juridiske skriveopgaver efter at have implementeret Dreaming. Det fungerer allerede i produktion, det er ikke kun en demo.

Hvad betyder det for iværksættere, der ikke programmerer?

Multi-Agent Orchestration er i øjeblikket tilgængeligt via Claude Agent SDK, ikke direkte i Claude Code CLI. Men retningen er klar: Orkestrering bevæger sig fra "du starter N subagenter manuelt" til "du beskriver opgaven, og lead-agenten beslutter, hvem den skal delegere til, og hvordan". Hvis du lige er begyndt med subagenter, behøver du ikke bekymre dig om v2 endnu. Lær det klassiske mønster "1 hovedchat + 3–5 subagenter med forskellige roller", så kan du naturligt gå videre til Managed Agents om 3–6 måneder.

7 fejl, der får subagenter til at gå i stå#

Fejl 1. Beskrivelser som "Hjælper med X" udløser ikke noget

Symptom: Du har skrevet en subagent, kontrolleret strukturen, og alt er gyldigt, men Claude kalder den ikke på brugerens anmodninger. Årsagen er næsten altid den samme: Beskrivelsen er abstrakt, for eksempel "Hjælper med kodegennemgang". Løsningen: Skriv 3–5 reelle brugerfraser i anførselstegn direkte i beskrivelsen plus "use proactively" / "use immediately after".

Fejl 2. Oprette en subagent, når der er brug for en Skill

En subagent koster mere end en Skill – den skaber sin egen kontekst, indlæser sin egen systemprompt og bruger flere tokens. Hvis en opgave er kort, ikke optager hovedkonteksten og kan løses i ét forsøg, bør det være en Skill, ikke en subagent. Et eksempel på et antimønster: En format-validator-subagent, der kontrollerer et JSON-skema mod 20 regler. Det bør være en Skill: én model, ingen isolation nødvendig, ingen ekstra kontekst indlæses.

Fejl 3. Starte "60 parallelle agenter" fra begyndelsen

Dette er den mest udbredte illusion. Du ser et tweet, hvor der står: "Jeg har 1,500 agenter i gang", og tænker: "Det burde jeg også gøre." I praksis bruger 60 agenter en Pro-plans grænser op på en time, genererer en bunke modstridende resultater, og når dagen er omme, er intet færdigt.

En praktiker på Medium siger det sådan:

Løsningen: Start med én subagent til én opgave. Når du har styr på det, tilføjer du en anden med en anden rolle. Når du har styr på at orkestrere to, går du videre til et team på 3–5. At gå fra "installerede Claude Code i går" til "20 parallelt i dag" ødelægger garanteret kode og bruger dine grænser op.

Fejl 4. Give alle agenter alle værktøjer

Hvis din kodegransker har adgang til Bash, Write og WebFetch, er det et stort hul i sikkerheden og omkostningsstyringen. En gransker bør ikke have tilladelse til at skrive filer, og slet ikke adgang til internettet.

Løsningen: Begræns tools strengt. En kodegransker får kun Read, Grep, Glob. En sikkerhedsrevisor får samme læse- og søgeværktøjer og en diff leveret af hovedsessionen. Tilføjelse af Bash giver shellkapacitet; det begrænser ikke automatisk agenten til git diff. En researchagent får WebFetch, WebSearch, Read, Write. Giv ikke en subagent flere tilladelser, end den har brug for til en bestemt opgave.

Fejl 5. En subagent dumper råresultater ind i hovedkonteksten

Hvis en researchagent returnerer "her er alle 30 sider, jeg fandt; find selv ud af det" til hovedchatten, har du mistet subagenternes største fordel: isolering af støj. Løsningen: Kræv eksplicit et outputformat i subagentens systemprompt. "Returnér KUN: TL;DR i 3 punkter + liste med 5 kilder. INGEN kodedumps, INGEN rå søgeresultater." Formatet skal være strengt – subagenten skal ikke have frihed til at "lave det om til et essay".

Fejl 6. Vage kald: uklare delegeringsanmodninger

En subagent kan ikke se hoveddialogens historik. Den starter med en ren kontekst + CLAUDE.md + det, du udtrykkeligt skrev til den. Hvis du skriver "ret godkendelsen", finder subagenten på ting. Skriv i stedet: "Ret OAuth-redirect-loopet, hvor brugeren efter et vellykket login bliver omdirigeret til /login i stedet for /dashboard. Fil: src/lib/auth.ts."

En klar regel: Når du delegerer, skal du give subagenten lige så meget kontekst, som du ville give en nyansat konsulent, der netop er startet på projektet.

Fejl 7. Rolleb​​aserede agenter i stedet for opgavebaserede agenter

Et fristende mønster er: "Lad os oprette en frontend-developer, backend-developer og qa-engineer og få dem til at arbejde som et team." Det fungerer ikke. Hver "rolle" mister konteksten om hele projektet, og de kan ikke blive enige om detaljer, fordi de ikke kan se hinanden.

Løsningen: En subagent skal håndtere en tilbagevendende opgave med et tydeligt resultat, ikke en rolle. Ikke "frontend-developer", men "explore-ui-tree", "refactor-component", "audit-accessibility". Hver opgavebaseret subagent udfører ét bestemt job og returnerer ét bestemt resultat.

Hvad koster parallelle subagenter, og hvornår kan de betale sig?#

En Pro-plan er brugt op inden for en time, hvis du starter 5 parallelle subagenter på komplekse opgaver. Max 5x ($100) er et realistisk minimum for regelmæssigt parallelt arbejde. For teams og Enterprise er spørgsmålet om penge allerede håndteret på niveauet for værktøjsbudgettet.

Læs den separate guide til grænser for mere om at spare tokens i Claude Code. For subagenter er hovedreglen, at en subagent kan betale sig på en opgave, der kræver mindst 10 minutter fokuseret arbejde. Hvis opgaven er kortere, skal du ikke oprette en subagent; udfør den i hovedchatten eller med en Skill.

Hvordan integrerer du subagenter i din AI-klon og Second Brain?#

En subagent afhænger af tre ting, der bør være på plads i dit projekt, før du opretter din første specialist:

1. Den rigtige CLAUDE.md. En subagent læser CLAUDE.md, før den begynder – det er dens "ansættelseskontrakt". Uden den kender subagenten ikke projektets kontekst, begrænsninger eller tone. Den vil finde på ting.

2. Grundlæggende Skills. En Skill er en pakket metode. En subagent indlæser kun de Skills, den har brug for, ikke alt på én gang. Uden Skills gentager en subagent det samme arbejde fra bunden hver gang.

3. Second Brain: en vidensstruktur. Mappen business/ (eller tilsvarende inden for dit fagområde) er et bibliotek, som alle subagenter konsulterer. Uden den giver en subagent et gennemsnitligt ChatGPT-svar, der ikke kan skelnes fra andres.

Hvis du vender rækkefølgen om, får du hype uden resultater. "Jeg har 60 parallelle subagenter" med en tom business/-mappe betyder 60 gennemsnitlige ChatGPT-sessioner med den samme tilgang.

Den komplette kombination – AI-klon + Second Brain + kontekstteknik – er de tre søjler, der gør Claude konsekvent. Subagenter er en del af AI-klonen: en måde at give Claude et specialiseret team, der arbejder efter din logik.

Den hurtigste måde at komme i gang på er at kopiere code-reviewer fra det første eksempel ovenfor til .claude/agents/code-reviewer.md, genstarte Claude Code og kalde @agent-code-reviewer ved din næste commit. På 5 minutter ved du, om du har brug for subagenter, eller om hovedchatten er nok.