Multi-agent-systemer: når flere agenter er bedre end én

Én agent, flere agenter: hvad taler vi om

En autonom AI-agent kører alene, med sine egne værktøjer, sin hukommelse og sit mål. Et multi-agent-system sætter derimod flere agenter i gang med den samme opgave, hver med en præcis rolle. Idéen er ikke ny inden for distribueret databehandling, men den har fået konkret betydning, siden sprogmodeller er blevet i stand til at bruge værktøjer og gennemføre trin uden konstant tilsyn.

Begrebet dækker over forskellige virkeligheder. Der er systemet "orkestrator plus underagenter", hvor en hovedagent deler arbejdet op og delegerer dele til mere specialiserede agenter. Der findes også ligeværdige agenter, der kommunikerer indbyrdes for at dele resultater uden et strengt hierarki. Nuancen at huske er, at "flere agenter" ikke betyder "flere identiske instanser, der gør det samme parallelt": hver agent har et afgrænset omfang. Atakos ordbog uddyber denne skelnen.

Princippet om orkestrering

Det, der adskiller et rigtigt multi-agent-system fra et sæt scripts, der bare kører parallelt, er orkestreringen: logikken, der afgør, hvem der gør hvad, i hvilken rækkefølge, og hvordan resultaterne samles. Anthropic har dokumenteret i detaljer den arkitektur, de bruger til deres funktion til dybdegående research: en "lead"-agent analyserer forespørgslen, definerer en strategi og opretter derefter underagenter, der hver udforsker et spor parallelt, før resultaterne samles (kilde: Anthropic, "How we built our multi-agent research system", https://www.anthropic.com/engineering/multi-agent-research-system, tilgået 2026-09-04).

Denne orkestrator/arbejder-model går igen i næsten alle seriøse implementeringer. Hovedagenten udfører ikke selv arbejdet: den planlægger, fordeler, kontrollerer og samler. Det er det, man kalder agent-orkestrering. Underagenten er til gengæld tænkt som kort og engangsbrug: den eksisterer, så længe delopgaven varer, og forsvinder derefter.

Hvorfor flere agenter nogle gange er bedre end én

Det mest citerede resultat om emnet kommer netop fra Anthropic. I deres interne evaluering slog et system bestående af en Opus-agent som dirigent og Sonnet-underagenter et enkelt Opus-agent med 90,2 % på de samme researchopgaver (samme kilde som ovenfor). Forklaringen ligger i ét ord: parallelisering. En enkelt agent udforsker spor ét ad gangen, i ét kontekstvindue, der før eller siden bliver mættet. Flere agenter kan udforske flere spor samtidig, hver i sin egen kontekst, før de samler det, de har fundet.

Denne fordel er ikke universel. Den viser sig især på opgaver, der er "brede": research, udforskning af flere hypoteser, behandling af store mængder adskilte informationer. LangChain opsummerer betingelsen godt i en referenceartikel om emnet: multi-agent-systemer excellerer på opgaver med høj værdi, der lader sig parallelisere godt, og mister deres relevans, så snart arbejdet er stærkt sekventielt eller afhænger af en delt kontekst (kilde: LangChain, "How and when to build multi-agent systems", https://www.langchain.com/blog/how-and-when-to-build-multi-agent-systems, tilgået 2026-09-04).

Anthropic er endda gået så langt som at bryde statistisk ned, hvad der forklarer forskellene i ydeevne mellem opsætninger. Tre faktorer forklarer alene 95 % af den observerede varians: mængden af brugte tokens, antallet af foretagne værktøjskald og valget af model. Tokenforbrug alene forklarer 80 % af denne varians (samme kilde). Med andre ord, det er ikke "at have flere agenter", der giver bedre ydeevne, det er den evne, det giver til at bruge mere regnekraft parallelt på et problem, der egner sig til det. På et problem, der ikke egner sig til det, gør denne samme evne ingen forskel, den koster bare mere for et resultat, der kan sammenlignes med en enkelt agent.

Prisen for koordinering

Denne performancegevinst har en pris, og den er langtfra ubetydelig. Ifølge Anthropic forbruger en enkelt agent allerede omkring 4 gange flere tokens end en almindelig chat-samtale. Et multi-agent-system forbruger omkring 15 gange mere (samme kilde). Det er ikke en detalje i regnskabet: på det niveau af multiplikation er det kun opgaver med reelt høj forretningsværdi, der retfærdiggør investeringen.

Koordineringsomkostningen stopper ikke ved tokens. LangChain peger på et mere strukturelt problem: samtidige skrivninger skaber langt flere problemer end samtidige læsninger. To agenter, der læser den samme database parallelt, er ikke et problem. To agenter, der ændrer det samme dokument, den samme sag eller den samme kodelinje samtidig, skaber konflikter, der efterfølgende skal forenes, ofte manuelt. Jo flere agenter, jo større bliver fejloverfladen: hver ekstra agent tilføjer et lag delt tilstand, en kommunikationsprotokol og et nyt sted, hvor systemet kan gå ned, uden at nogen straks forstår hvorfor.

Man skal også tælle debug-omkostningen med. At følge ræsonnementet hos en enkelt agent, med dens tidslinje af handlinger, er allerede et stykke arbejde i sig selv. At følge rækkefølgen af beslutninger mellem flere agenter, der deler en opgave, med deres beskedudveksling og eventuelle uenigheder, kræver langt mere avanceret observability. Det er et projekt for sig selv.

Hvornår du ikke skal kaste dig ud i multi-agent

Refleksen "flere agenter, mere kraft" er en af de sikreste måder at sprænge et AI-budget uden proportional gevinst. Gartner har sat tal på det med hård kant: bureauet forudser, at over 40 % af agentiske AI-projekter vil blive opgivet inden udgangen af 2027, blandt andet på grund af omkostninger, der løber løbsk, dårligt defineret forretningsværdi og utilstrækkelig risikostyring (kilde: Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027, tilgået 2026-09-04). En stor del af disse fejlslag skyldes projekter, der lægger orkestreringskompleksitet oveni, uden at opgaven kræver det.

Konkret er det bedre at blive ved en enkelt agent, når opgaven holder sig inden for ét kontekstvindue, når den er stærkt sekventiel (hvert trin afhænger strengt af det forrige), eller når arbejdsmængden ikke retfærdiggør token-regningen. LangChain nævner netop kodning som eksempel: i modsætning til research indeholder en udviklingsopgave sjældent reelt parallelliserbart arbejde, hvilket gør multi-agent mindre relevant, end man skulle tro, til netop denne use case.

Det rigtige spørgsmål at stille sig, før du tilføjer en anden agent, er derfor ikke "kan det hjælpe?", men "har denne opgave en reel, naturlig opdeling?". Hvis en del af arbejdet kræver filadgang, en anden databaseadgang, og en tredje et kald til en ekstern API, er der en reel opdeling at lave. Hvis alt afhænger af den samme ræsonnementstråd, tilføjer flere agenter primært friktion.

En simpel tjekliste, før du kaster dig ud i det: genererer opgaven flere uafhængige spor, der kan udforskes parallelt? Retfærdiggør arbejdsmængden en token-regning, der er flere gange højere? Skriver delopgaverne i forskellige systemer, eller risikerer de at overlappe hinanden på samme data? Hvis svaret er nej til bare ét af disse tre spørgsmål, vil en enkelt, veludstyret agent med gode adgange og klare instrukser sandsynligvis være hurtigere og billigere end en arkitektur med flere agenter.

Det, Atako konkret ændrer

Hos Atako findes denne orkestrator/underagent-logik som en indbygget funktion: en agent kan delegere en kompleks delopgave til en midlertidig underagent, hvis arbejde vises som trin i hovedagentens aktivitetstidslinje, uden at det bruger en ekstra slot. Det undgår den mest almindelige faldgrube: at multiplicere "fulde" agenter (og deres omkostning), hvor en simpel, midlertidig underagent ville være nok. Vil du dykke dybere ned i budgetsiden, beskriver den følgende artikel de reelle omkostningsposter for en AI-agent i en virksomhed, og artiklen om ROI-måling hjælper dig med at tjekke, når det først er sat op, om investeringen var det værd.