När behöver man egentligen flera AI-agenter?

Multi-agent låter avancerat och därför attraktivt. Jag har själv byggt en contentfabrik med separata roller för research, evidence audit, struktur, skrivande, faktakontroll, redigering, SEO, internlänkar och publisher gate. Men den viktigaste lärdomen är inte att nio agenter är bättre än en. Det är att flera agenter bara är motiverade när uppgiften faktiskt tjänar på separerade ansvar och separerad kontext.

Den bredare frågan om vad ett multiagentsystem är och vilka ramverk som finns täcker jag i en genomgång av AI-svärmar och multiagentsystem. Här går jag rakt på beslutet: när räcker en agent, och när måste roller faktiskt separeras?

Jag börjar därför inte med frågan "hur många agenter ska vi ha?". Jag börjar med: var finns konflikter mellan mål, verktyg, evidens och behörighet?

En agent räcker när uppgiften är sammanhängande

Om uppgiften är liten, kontexten är gemensam och samma kvalitetskriterier gäller genom hela jobbet kan en agent vara bäst.

Exempel: läsa ett kort dokument och sammanfatta det, föreslå tre rubriker eller göra en avgränsad kodändring med tydliga tester. Att dela upp sådant i fem roller ger ofta bara mer latency, fler handoffs och fler ställen där kontext kan tappas.

Anthropic rekommenderar uttryckligen att börja med den enklaste lösningen som fungerar och bara öka agentisk komplexitet när den ger mätbar förbättring. De skiljer också mellan workflows, där kodvägen är fördefinierad, och agentsystem där modellen dynamiskt styr processen. Anthropic: Building Effective Agents

Jag lägger till en agent när ansvaren verkligen bör separeras

Det tydligaste fallet är när samma kontext skapar en intressekonflikt.

I contentproduktion vill jag inte att Writer själv ska bestämma om dess källor är tillräckliga. Jag vill inte heller att Fact Checker ska optimera för snygg prosa. De rollerna har olika mål.

Det ger en praktisk regel:

Det betyder inte att två LLM:er automatiskt blir oberoende i statistisk mening. Men det gör instruktioner, artefakter och ansvar granskningsbara.

Verktygsbehörighet är ett ännu starkare skäl

En annan anledning är permissions.

Researcher kan behöva webbsökning och read access. Writer behöver skriva draftfiler men behöver inte publiceringsbehörighet. Publisher Gate behöver kunna ändra workflow-state, men ska inte få skapa ny evidens.

Om en enda agent får alla verktyg ökar blast radius. Jag föredrar därför ibland flera specialister inte för att de "tänker bättre", utan för att de får mindre handlingsyta.

Kontextisolering kan förbättra fokus

Stora agentflöden drabbas lätt av context pollution. Researchanteckningar, gamla utkast, reviewkommentarer och implementationdetaljer ligger i samma kontext och modellen börjar optimera mot sådant som inte längre är relevant.

Separata agenter kan få olika views av samma projekt:

• Researcher ser brief och source policy.
• Writer ser godkänd evidence och outline.
• SEO Reviewer ser final draft, intent och keyword hypothesis.
• Publisher Gate ser QA-resultat och releasekontrakt.

Det är ofta mer värdefullt än att ge alla allt.

Flera agenter är inte samma sak som parallellisering

Ibland behöver man inte specialistroller utan flera oberoende försök.

Tre reviewers som granskar samma kod för olika risker är ett parallelization-mönster. En Researcher som lämnar över till en Writer är en sekvens. En orchestrator som skapar deluppgifter dynamiskt är något annat igen.

Jag försöker namnge mönstret innan jag implementerar det. Annars blir "multi-agent" en låda där alla former av flera modellcalls hamnar.

Handoffs är den verkliga kostnaden

Varje agentgräns kräver ett kontrakt. Vad måste finnas in? Vad får agenten ändra? Vad lämnar den ut? Hur ser ett fail ut?

Om jag inte kan beskriva handoffen tydligt är det ofta ett tecken på att rollseparationen är för tidig.

I min contentpipeline får exempelvis Writer bara skriva från approved claims. Om evidence audit saknas ska den inte "göra sitt bästa". Den ska stoppa.

Det är handoffkontraktet, inte agentnamnen, som gör arkitekturen robust.

Handoffs behöver typade fält, inte fri prosa

Ett handoffkontrakt blir starkare när det är typat snarare än en fri sammanfattning. Researcher ska lämna en source ledger och claim status, inte "några anteckningar" — ju tydligare interface, desto mindre värde försvinner mellan specialister. Det är samma princip som gör isolerad kontext till en fördel: en writer som bara ser godkänd evidence, inte halvfärdiga researchhypoteser, börjar inte av misstag behandla en hypotes som fakta.

Skicka beslut mellan agenter, inte hela tankeflödet

Nästa agent behöver normalt godkända claims, källor, constraints och öppna blockers — inte hela den upstream-konversation som ledde fram till dem. Jag använder strukturerade fält: inputs used, outputs produced, unresolved issues, prohibited assumptions och next-state eligibility. Provenance måste följa med: när en claim flyttas mellan researcher, writer och fact checker följer källa och verdict med, och prosa utan provenance får inte bli starkare bara för att den passerar fler agenter. Att en tidigare agent nämnde något betyder inte heller att det är godkänt — bara explicita states och artefakter får bära auktoritet i nästa steg. Ju mer moget handoff-kontraktet är, desto mindre behöver skickas: agenten kan läsa exakt rätt artefakt i stället för att tolka en lång historik.

När flera agenter gör systemet sämre

Jag ser fyra tydliga varningssignaler:

1. Samma information kopieras mellan alla roller.
2. Varje agent sammanfattar föregående agents sammanfattning.
3. Det finns ingen oberoende kvalitetskontroll mellan stegen.
4. Ingen kan förklara varför ett steg behöver en separat permission eller kontext.

Då har man ofta byggt organisatorisk teater runt ett problem som kunde lösas med ett workflow och två modellcalls.

Min beslutsregel

Jag lägger till en separat agent när minst ett av följande är sant:

• rollen behöver andra verktyg eller permissions,
• rollen behöver en mindre/differentierad kontext,
• rollen ska kritisera ett tidigare steg mot ett separat kontrakt,
• uppgiften kan delegeras självständigt,
• fel behöver kunna härledas till ett specifikt ansvar.

Annars börjar jag hellre enklare.

Det gör multi-agent till ett arkitekturval snarare än en ambitionsnivå. Fler agenter betyder inte mer AI. Det betyder fler gränser att motivera, testa och drifta.

• Claude Code: dokumentation om subagents

Relaterade artiklar

• Jag slutade skriva prompts — och började skriva specifikationer
• Min Research → SEO → Compliance → Brand → Writer-pipeline
• Hur jag avgör vad modellen ska läsa varje gång och vad som bara ska hämtas vid behov
• Så bygger jag specialiserade agentfiler för Claude, Gemini och ChatGPT
• Hur jag bygger en AI-agent på 20 källor utan att skapa ett hallucinationsmonster