Jeg har brugt AI-agenter til at skrive kode i et par år nu. Først som en slags turbo-autocomplete, så som en assistent der kunne tage en opgave og løse den, og til sidst som noget der begyndte at ligne en kollega. Men der var altid et problem: de kunne ikke tale sammen.
Det lyder som en lille ting. Det er det ikke.
Siloer er dyrt — også for maskiner
Subagents i Claude Code var allerede stærke. Du kunne spawne en agent til at skrive backend, en anden til frontend, en tredje til tests. Men de arbejdede i siloer. Hver agent fik sin opgave, leverede sit resultat tilbage til hovedsessionen, og vidste intet om hvad de andre lavede. Hvis backend-agenten tog en beslutning om dataformatet, fandt frontend-agenten først ud af det når koden fejlede.
Det minder om noget. Det minder om rigtige teams der sidder i hvert sit hjørne og smider ting over hegnet. Vi ved det ikke virker for mennesker. Hvorfor skulle det virke for maskiner?
Agent Teams i Claude Code løser præcis det problem. Og forskellen er ikke kvantitativ — det er ikke bare hurtigere eller mere effektivt. Den er kvalitativ. Det er en anden måde at arbejde på.
Hvad Agent Teams faktisk er
Agent Teams er Anthropics svar på multi-agent orkestrering i en udviklerkontekst. Én Claude Code-session fungerer som team lead. Den spawner teammates — hver med sin egen kontekstvindue, sin egen adgang til filsystemet, sine egne værktøjer. De kommunikerer direkte med hinanden via et besked-system, og de deler en fælles task-liste med afhængigheder.
Det vigtige her er ikke at de kan arbejde parallelt. Det kunne subagents også. Det vigtige er at de kan koordinere. En backend-agent kan sende en besked til frontend-agenten: “Jeg har ændret response-formatet, her er den nye struktur.” Frontend-agenten tilpasser sig uden at hovedsessionen behøver at spille mellemmand. Det er ikke bare delegation — det er samarbejde.
Og det er præcis derfor det virker bedre end subagents til alt der involverer mere end én kontekst.
Koordinationsproblemer kræver kommunikation
De fleste interessante softwareproblemer er ikke dekomponerbare i isolerede dele. Implementering af en feature kræver at frontend, backend og tests holder sig i sync. Et databaseskema-ændring påvirker API-kontrakter der påvirker UI-komponenter der påvirker testsuiten. Det hele hænger sammen.
Subagents behandlede det som om det ikke gjorde. De løste deres del i vakuum og håbede at stykkerne passede sammen. Nogle gange gjorde de. Ofte gjorde de ikke.
Agent Teams behandler det som det det er: et koordinationsproblem. Og koordination kræver kommunikation mellem arbejdere — ikke bare rapportering til en leder.
Jeg har brugt det til en del forskellige ting nu, og den kvalitative forskel er mærkbar. Når agenter kan tale sammen på tværs — udfordre hinandens antagelser, dele opdagelser midt i processen, selv-koordinere via en fælles task-liste — så sker der noget andet. De finder fejl hurtigere fordi de ikke venter med at integrere. De laver færre antagelser fordi de kan spørge hinanden. De producerer kode der hænger sammen fordi de ved hvad de andre laver.
Den egentlige arkitektur
Lad mig være lidt mere konkret. Når du starter et agent team, sker der følgende:
Team-lederen opretter en fælles task-liste. Hver task har en titel, en beskrivelse, en status og eventuelle afhængigheder til andre tasks. Lederen spawner teammates — typisk 3-5 for de fleste workflows — og tildeler dem opgaver via task-listen.
Teammates arbejder selvstændigt i deres egen kontekstvindue. De kan læse filer, skrive kode, køre commands. Men de kan også sende beskeder direkte til andre teammates. Og de kan kigge på task-listen for at se hvad der mangler, hvad der er blokeret, og hvad de selv kan tage fat på.
Når en teammate er færdig med sin opgave, markerer den tasken som completed og kigger efter næste ledige opgave. Hvis den er blokeret, sender den en besked til den teammate der blokerer den. Det hele kører asynkront, og lederen kan til enhver tid se status, sende beskeder til individuelle teammates, eller omfordele opgaver.
Det er i bund og grund en asynkron, besked-baseret arkitektur med en central task-kø. Hvis det lyder bekendt, er det fordi det er det samme mønster der driver de bedste software-teams. Ikke fordi det er kopieret fra menneskelig organisation — men fordi det er den mest effektive måde at koordinere parallelt arbejde på.
Hvornår det giver mening — og hvornår det ikke gør
Agent Teams er ikke altid det rigtige værktøj. Hvis du skal rette en bug i én fil, er det overkill. Hvis du skal implementere en isoleret funktion, er en subagent finere og billigere. Agent Teams bruger markant flere tokens — hver teammate har sin egen kontekstvindue, og kommunikation koster.
Men der er scenarier hvor det ikke bare er bedre — det er en helt anden liga.
Cross-layer features. Når en feature spænder over frontend, backend, database og tests, og de fire lag skal holdes i sync. Giv hver teammate et lag og lad dem koordinere direkte.
Fejlfinding med konkurrerende hypoteser. Spawn fire agenter der hver undersøger en forskellig teori om hvad der er galt. Lad dem udfordre hinandens fund. Den der overlever peer review er sandsynligvis tættere på sandheden.
Code review med multiple perspektiver. En agent fokuserer på sikkerhed, en anden på performance, en tredje på testdækning. De finder ting som en enkelt gennemgang overser fordi de kigger med forskellige briller.
Store migreringer. Jeg har tidligere brugt Claude Code til at migrere 11 servere fra Digital Ocean til Hetzner på en weekend. Med agent teams ville den slags opgave være endnu mere naturlig — en agent per service, med kommunikation om delte afhængigheder som DNS, netværk og databaser.
Det handler ikke om at smide flere agenter efter et problem. Det handler om at give dem mulighed for at samarbejde om det.
Hvad det betyder for virksomheder
Her er det interessante for dem der betaler for det: Agent Teams er ikke bare et udviklerværktøj. Det er en organisatorisk model.
De fleste virksomheder kæmper ikke med at AI kan skrive kode. Det kan den. De kæmper med at AI-genereret kode sjældent hænger sammen i en større kontekst. Frontend og backend matcher ikke. Datamodeller er inkonsistente. Tests dækker ikke de rigtige ting. Det er integrationsproblemerne — ikke produktionsproblemerne — der spiser tiden.
Agent Teams adresserer præcis det. Ikke ved at være bedre til at skrive kode, men ved at være bedre til at koordinere kode. Og det er den del de fleste organisationer mangler.
Ni ud af ti IT-chefer i Danmark siger at AI-agenter risikerer at skabe mere forvirring end værdi. Det er ikke fordi agenterne er dårlige. Det er fordi de kører i siloer. Hver agent løser sin opgave i vakuum, og ingen sikrer at stykkerne passer sammen. Agent Teams er et konkret bud på hvordan man løser det — i hvert fald i en softwareudviklingskontekst.
Og konteksten er vigtig. For Agent Teams er ikke en generel løsning på alle organisationens AI-problemer. Det er et specifikt værktøj til et specifikt problem: koordineret softwareudvikling med multiple AI-agenter. Men det problem er reelt, og løsningen virker.
Token-prisen og hvornår det betaler sig
Lad os være ærlige om omkostningerne. Et agent team med tre teammates bruger groft sagt 3-4 gange så mange tokens som en enkelt session der løser den samme opgave sekventielt. Det er ikke gratis.
Men regnestykket er ikke tokens per opgave. Regnestykket er tokens per velintegreret løsning. Hvis tre subagents producerer kode der kræver to timer at integrere manuelt, og et agent team producerer kode der virker fra starten, er det ikke svært at se hvad der er billigst.
Det er det samme argument som for pair programming. Ja, det koster to udviklere i stedet for én. Men det producerer bedre kode, færre bugs, og sparer tid downstream. Agent Teams er pair programming for AI — bare med flere parter og lavere timelønninger.
MCP som fundamentet
En ting der gør Agent Teams særligt interessant er kombinationen med MCP — Model Context Protocol. MCP er efterhånden blevet de facto standard for hvordan AI interagerer med eksterne systemer. Der findes over 1.000 community-byggede MCP-servere, og selv OpenAI har adopteret protokollen.
Hos Brokk & Sindre har jeg bygget MCP-servere til danske offentlige data — Danmarks Statistik, CVR-registret — og en agent-first API til en af Danmarks største ejendomsdatabaser. Når du kombinerer Agent Teams med MCP, får du agenter der ikke bare kan koordinere med hinanden, men også trække på eksterne datakilder undervejs. En agent kan slå op i en database mens en anden skriver kode der bruger resultaterne. Det er integration i realtid, ikke i rækkefølge.
Hvad der mangler
Agent Teams er stadig eksperimentelt. Du skal aktivt slå det til i dine settings. Og der er begrænsninger.
Koordinationsoverhead vokser med antallet af agenter. Mere end fem teammates, og du bruger en uforholdsmæssig mængde tokens på kommunikation i stedet for arbejde. Det er det samme fænomen som i menneskelige teams — Brooks’ lov gælder tilsyneladende også for maskiner.
Konfliktløsning er primitivt. Hvis to agenter redigerer den samme fil, er det ikke altid lederen der fanger det i tide. Worktrees hjælper — hver agent kan arbejde i sin egen isolerede kopi af kodebasen — men det kræver at du tænker over det på forhånd.
Og debugging er svært. Når noget går galt i et agent team, er det ikke altid tydeligt hvilken agent der tog den forkerte beslutning, og hvornår den beslutning forplantede sig til de andre. Det er distribueret systems-debugging, og det er hårdt uanset om agenterne er mennesker eller maskiner.
Men det er alt sammen løsbare problemer. Og det de allerede kan i dag — koordineret, parallel softwareudvikling med direkte inter-agent kommunikation — er nok til at ændre hvordan jeg arbejder.
Den rigtige måde at tænke på det
Agent Teams er ikke en erstatning for subagents. Det er et nyt værktøj i værktøjskassen. Subagents er stadig bedre til hurtige, fokuserede opgaver. Agent Teams er bedre til alt der kræver at multiple kontekster holdes i sync.
Den rigtige analogi er ikke “mere AI.” Det er bedre organiseret AI. Det er forskellen mellem at hyre fem freelancere der aldrig taler sammen, og at sætte et team der kommunikerer og koordinerer. Koden de producerer er den samme slags. Men måden den hænger sammen på er fundamentalt anderledes.
Og det er det der tæller i produktion. Ikke om hver enkelt fil er elegant, men om helheden virker.
Jeg tror vi er ved begyndelsen af noget. Ikke i den hypede “AI ændrer alt”-forstand. Men i den praktiske forstand at multi-agent koordination er det næste lag af produktivitet, ligesom AI-assisteret kodning var det forrige. Det er ikke magi. Det er bare bedre værktøj til et reelt problem.
Og det problem — koordination — er og bliver det sværeste i softwareudvikling. Uanset om det er mennesker eller maskiner der skriver koden.
