Derfor er multi-agent AI overdesignet (hvad data viser)

De fleste multi-agent-systemer bygges af de forkerte grunde. Gartner forudser, at over 40 % af alle agentiske AI-projekter bliver skrottet inden udgangen af 2027 på grund af eskalerende omkostninger, uklar forretningsværdi eller utilstrækkelig risikostyring (Gartner, 2025). Et studie fra 2026 viser, at enkelt-agent LLM'er matcher eller overgår multi-agent-systemer på multi-hop-ræsonnering, når tokenbudgettet holdes lige. Konklusionen: de rapporterede multi-agent-fordele skyldes "uregistreret beregning og konteksteffekter snarere end iboende arkitektoniske fordele" (arxiv 2604.02460, 2026).

Fejlen handler ikke om værktøjer. Den handler om at gribe efter kompleksitet, før problemet kræver det. Som en praktiker formulerede det: "De fleste griber til multi-agent-systemer i det øjeblik, en opgave føles kompleks. Det er næsten altid den forkerte impuls." Det rigtige spørgsmål er ikke "skal jeg bruge flere agenter?", men "hvilken slags koordination kræver denne opgave faktisk?"

Denne artikel bygger et samlet beslutningsframework ud fra tre komplementære kilder, der dækker arkitektur, identitet og governance. Når du er færdig med at læse, har du en diagnostik, du kan bruge, før du træffer din næste arkitekturbeslutning.

Når man er i tvivl, tilføjer man flere agenter: Den gængse visdom

Multi-agent AI er ikke længere et nicheeksperiment. Gartner forudser, at 40 % af alle virksomhedsapplikationer vil have opgavespecifikke AI-agenter i 2026, og analytikerdata viser, at mere end halvdelen af store virksomheder er i aktiv evaluering eller tidlig deployment-fase (Gartner/IDC via Joget, 2026). Tempoet accelererer hurtigere, end de fleste organisationer kan nå at vurdere, om arkitekturen overhovedet passer til opgaven.

Den dominerende mentalmodel er lånt fra, hvordan menneskelige organisationer skalerer: mere kompleksitet kræver flere specialister. Når en opgave føles svær, er instinktet at dele den op mellem en planlægger, en udfører og en tester. Det føles organiseret. Det spejler velkendte ledelsesstrukturer. Og for en bestemt type problemer virker det rent faktisk.

Den model har seriøst momentum. Paperclip, et open source-værktøj der organiserer AI-agenter i virksomhedslignende strukturer med org charts, budgetter og jobtitler, ramte 1,6 millioner GitHub-visninger i sin første uge. Visionen om "AI-virksomheden" resonerer, fordi den afspejler noget, ingeniører allerede forstår: afdelinger, rapporteringslinjer, delegation. Men er det instinkt pålideligt? Ikke så ofte, som man skulle tro.

Hvorfor det instinkt koster tid og penge

Multi-agent tokenforbrug ligger 3-5x højere end single-agent i typiske workflows, og dokumenteret orkestreringsforstærkning rammer 4,6x i benchmarks (Iterathon, 2026). Under kontrollerede forhold matcher eller overgår enkelt-agent-systemer multi-agent-performance, når tokenbudgettet holdes lige (arxiv 2604.02460, 2026). Koordinationsomkostningerne overstiger næsten altid forventningerne.

Tre konkrete problemer dukker op igen og igen.

Problem 1: Rollebaseret opdeling skaber en informations-telefonleg. Instinktet om at dele op efter rolle — planlægger, så udfører, så tester — føles organiseret. Men udføreren har ikke, hvad planlæggeren vidste. Testeren har ikke, hvad udføreren besluttede. Kvaliteten falder ved hvert handoff. Da vi testede parallelle agenter, der skrev kode, lavede de inkompatible antagelser, som var brutale at debugge bagefter.

Problem 2: Agenter uden identitetsdefinitioner glider ind i hinandens arbejde. Uden eksplicitte grænser "udfylder agenter udefinerede huller med det, der føles naturligt," som Priyanka Vergadia dokumenterede efter at have debugget multi-agent-kaos i produktion. Din analyseagent begynder at skrive rapporter. Din skribent-agent begynder at trække data. Alt fungerer teknisk set, og alligevel er alt forkert. Én gigantisk systemprompt, der prøver at svare på fire forskellige spørgsmål samtidig, producerer inkoherens.

Problem 3: Tokenomkostninger vokser hurtigere end værdien. Multi-agent orkestrering tilfører 3-5x token-overhead, og det betyder, at ROI-tærsklen sjældent nås for rutineopgaver. De dokumenterede 4,6x gælder veldesignede pipelines — dårligt designede kører højere (Iterathon, 2026). Den afvejning er det værd for kompleks research. For de fleste produktionsworkloads er den det ikke.

Det er ikke separate problemer. Det er forskellige fejllag af den samme grundlæggende fejl: at behandle agentarkitektur som et org chart i stedet for en designbeslutning.

Hvad viser forskningen faktisk om agentperformance?

Enkelt-agent LLM'er matcher eller overgår multi-agent-systemer på multi-hop-ræsonnering, når tokenbudgettet holdes lige. Studiets centrale fund er, at multi-agent-fordele skyldes "uregistreret beregning og konteksteffekter snarere end iboende arkitektoniske fordele" (arxiv 2604.02460, 2026). Det er det vigtigste datapunkt, branchen endnu ikke har taget til sig.

Hvornår tjener multi-agent egentlig sine omkostninger hjem? Anthropics officielle vejledning peger på orchestrator-subagent som det mønster, der "håndterer den bredeste vifte af problemer med mindst koordinations-overhead" (Anthropic, 2026). De fem mønstre, Anthropic dokumenterer, er generator-verifier, orchestrator-subagent, agent teams, message bus og shared-state. Men spørgsmålet er ikke, hvilket mønster man skal vælge. Spørgsmålet er, om man overhovedet har brug for et.

Ud fra forskning og praktisk test bliver multi-agent-kompleksitet berettiget ved specifikke, målbare tærskler. Tool overload er et dokumenteret fejlmønster: efterhånden som agenter akkumulerer værktøjer, begynder de at fejlhåndtere tool-svar og overser, når eksterne systemer returnerer fejl (MindStudio, 2026). At holde en enkelt agents værktøjsantal under 15 er en fornuftig tommelfingerregel, før man overvejer specialisering.

Her er den 3-spørgsmåls-diagnostik, der erstatter mavefornemmelsen:

1. Kræver denne delopgave isoleret kontekst? Hvis en delopgave genererer information, der er irrelevant for hovedopgaven, forhindrer en subagent kontekstforurening. Brug subagents.
2. Skal delopgaver forhandle undervejs? Hvis én agents opdagelse ændrer, hvad en anden agent bør gøre, har de brug for direkte kommunikation. Brug agent teams.
3. Kan én velprompted agent klare det inden for sit context window? Hvis ja, og værktøjsantallet holder sig under 15-20, brug én enkelt agent.

Den diagnostik erstatter den gængse "rolle-org chart"-mentalmodel med kontekstcentreret dekomposition. Opdel efter informationsgrænser, ikke jobtitler.

Hvad er den bedre tilgang? Fire filer og ét diagnostisk spørgsmål

Alternativet er ikke et værktøj. Det er et framework, der virker, før man tager nogen arkitekturbeslutning. agentskills.dk hoster over 16.000 publicerede AI-agentskills pr. april 2026 (agentskills.dk, 2026), og mønsteret på tværs af de mest vellykkede implementeringer er konsistent: identitet før arkitektur, arkitektur før governance.

Frameworket kombinerer kontekstcentreret dekomposition med et 4-fil identitetssystem:

• Start med én enkelt agent. Pres den, til den bevisligt bryder sammen. Det brudpunkt fortæller dig præcis, hvad du skal tilføje.
• Opdel efter kontekstgrænser, ikke efter roller. Hvis to delopgaver har brug for overlappende information, hører de til den samme agent. Adskil kun, når kontekst reelt kan isoleres.
• Hver agent skal have en "Hvad jeg IKKE gør"-sektion. En Agent.md-fil definerer identitet og hårde grænser. Uden den vil din analyseagent på et tidspunkt skrive CEO-memoer, fordi det virkede som et naturligt næste skridt.
• Giv hver agent en mental model af hele systemet. En AGENTS.md i projektets rod fungerer som org chartet. Nye udviklere bør forstå hele systemet på fem minutter. Dine agenter har brug for den samme klarhed.
• Tilføj governance, når skalaen kræver det. Heartbeats, budgetkontrol og audit trails er værdifulde, men de er et tredje lag. Få arkitektur og identitet på plads først.

Den mentalmodel, der hænger fast: "AGENTS.md er bykortet. Agent.md er din adresse. INSTRUCTIONS.md er din daglige rutine. SKILL.md er dit fagbrev." Du har brug for alle fire. De fleste teams springer Agent.md og AGENTS.md over, fordi de føles administrative. Det er den fatale fejl.

Hvordan kan du bruge det her fra i dag?

Gennemgå din nuværende agents værktøjsantal i dag. Hvis nogen enkelt agent har adgang til mere end 15 værktøjer, vurdér, om en opdeling efter værktøjsdomæne ville forbedre præcisionen. Tool overload er et dokumenteret fejlmønster: agenter fejlhåndterer tool-svar og overser fejl fra eksterne systemer, efterhånden som værktøjsantallet vokser (MindStudio, 2026).

Her er fem trin, sorteret efter indsats:

1. Skriv en AGENTS.md til dit projekt (i dag, 1 time). Også selvom du kun har én agent. Dokumentér, hvem der eksisterer, og hvordan opgaver flyder. Filen bør være læsbar for en ny udvikler på fem minutter.
2. Tilføj en "Hvad jeg IKKE gør"-sektion til hver agentdefinition (denne uge, 30 minutter per agent). Dén ene tilføjelse forebygger den hyppigste fejl: at agenter udfylder udefinerede huller.
3. Kør din mest komplekse opgave på en enkelt agent med en fokuseret prompt (inden næste sprint). Modstå trangen til at tilføje agenter. Se, hvor den faktisk bryder sammen.
4. Når den bryder sammen, brug 3-spørgsmåls-diagnostikken før du tilføjer agenter. Match fejltypen med arkitekturen: kontekstforurening kalder på subagents, forhandling undervejs kalder på teams.
5. Tilføj governance først, når identiteten er på plads. Budgetkontrol og heartbeats er det tredje lag, ikke det første.

Da vi omstrukturerede vores egen pipeline efter de her principper, var den første målbare forbedring ikke hastighed eller omkostning. Det var, at agenter holdt op med at lave arbejde uden for deres definerede scope. Dét er diagnostikken, der fortæller dig, at identitetsfilerne virker: scopeovertrædelser falder til næsten nul.

Følg tre nøgletal: opgavegennemførelsesrate, tokenomkostning per fuldført opgave og hyppigheden af agenter, der opererer uden for deres definerede scope. Identitetsfiler tager 1-2 timer at sætte op. Gevinsten er målbar inden den første produktionshændelse, de forebygger.

Hvornår er den gængse tilgang faktisk korrekt?

For store, genuint parallelle workloads er multi-agent-systemer det rigtige valg. Hvis du kører 10+ agentterminaler samtidig på uafhængige research-strømme, eksisterer orkestrerings-infrastruktur som Paperclips governance-lag netop til den situation.

Multi-agent tjener sine omkostninger hjem i tre specifikke situationer. Kontekstbeskyttelse er vigtig, når en delopgave genererer information, der er irrelevant for hovedopgaven. Ægte parallelisme hjælper, når uafhængige research- eller søgeopgaver drager fordel af samtidig dækning. Og modstridende systemprompter er en reel begrænsning, når specialistkrav ville kollidere i en enkelt prompt.

Den svageste del af denne artikels argument: den tærskelbaserede vejledning (15-20 værktøjer, 60-70 % kontekstudnyttelse) bygger på forskningsbenchmarks, ikke universelle empiriske regler. Din specifikke opgave kan retfærdiggøre kompleksitet tidligere. Diagnostikken er ikke en formel. Den er en bedre default end mavefornemmelsen.

Ofte stillede spørgsmål

Hvad er forskellen på en subagent og et agent team i Claude?

Subagents er fire-and-forget: de får et isoleret context window, udfører en opgave og returnerer et komprimeret resultat til forælderen. Ingen peer-kommunikation. Agent teams er vedvarende og samarbejdende: teammedlemmer kommunikerer direkte, deler en opgaveliste med afhængighedssporing og akkumulerer kontekst over tid. Anthropic anbefaler orchestrator-subagent til "den bredeste vifte af problemer med mindst koordinations-overhead" (Anthropic, 2026).

Hvornår er én enkelt agent bedre end flere agenter?

Oftere, end de fleste teams forventer. Forskning viser, at enkelt-agent-systemer matcher multi-agent-performance, når tokenbudgettet holdes lige (arxiv 2604.02460, 2026). En enkelt agent er bedre, når opgaven passer inden for ét context window, når delopgaver er sekventielle frem for genuint parallelle, og når koordinations-overhead ville overstige værdien af udførelsen. Prøv den enkle agent først.

Hvad får de fleste multi-agent-systemer til at fejle?

Tre fejllag: forkert arkitekturmønster (opdeling efter rolle i stedet for kontekst), manglende identitetsdefinitioner (agenter udfylder udefinerede huller med det, der føles naturligt) og fraværende governance (ingen budgetkontrol, ingen audit trail, ingen heartbeat-planlægning). Gartner forudser, at over 40 % af alle agentiske AI-projekter bliver skrottet inden 2027, med utilstrækkelig risikostyring som en primær årsag (Gartner, 2025).

Branchen har brug for en design-først-norm

Standardtilgangen "komplekst problem, tilføj flere agenter" er det forkerte første træk i langt de fleste tilfælde. Den rigtige default er: start enkelt, diagnosticér ud fra kontekst, tilføj identitetsfiler før du tilføjer agenter, tilføj governance kun når skalaen kræver det.

Normen bør skifte fra "hvordan koordinerer jeg flere agenter?" til "har denne opgave faktisk brug for flere agenter?" — med målbare tærskler, før svaret automatisk bliver ja. Forestil dig en verden, hvor hvert multi-agent-projekt starter med en udfyldt AGENTS.md og en gennemført 3-spørgsmåls-diagnostik. De fleste af de projekter ville shippe simplere, billigere og mere pålideligt.

Hvad var det første, der gik i stykker i dit multi-agent-setup? Den fejl fortæller dig næsten med sikkerhed, hvor identitet eller governance manglede.