Multi-agent systems: Orchestration, delegation och konfliktlösning

Multi-agent-system är ett av de mest hypade begreppen i AI-världen just nu, och samtidigt ett av de mest missförstådda. Idén är förförisk: istället för en enda agent som ska kunna allt sätter du flera specialiserade agenter som samarbetar, ungefär som ett team. Ibland är det precis rätt. Lika ofta lägger man till komplexitet, latens och kostnad för ett problem som en enda välskriven agent löst enklare. Jag börjar därför alltid med frågan om uppdelningen faktiskt behövs.

Nedan går jag igenom när flera agenter lönar sig, hur jag strukturerar orkestreringen, och de fallgropar som gör att system spårar ur. En viktig utgångspunkt: varje agent du lägger till är inte bara en ny förmåga, utan också en ny felkälla, en ny latensbidragsgivare och en ny kostnadspost. Den kalkylen glöms ofta bort i entusiasmen över ett elegant teamdiagram.

När en agent räcker - och när den inte gör det

En enda agent med tillgång till rätt verktyg klarar förvånansvärt mycket. Innan jag delar upp ett problem frågar jag: finns det verkligen distinkta roller med olika kompetens, eller försöker jag bara strukturera ett komplext flöde? I det senare fallet är en tydlig stegmodell ofta bättre än flera agenter. Multi-agent blir intressant när delproblemen är genuint olika - en som söker, en som skriver, en som granskar - och gärna kan arbeta parallellt.

Orkestreringsmönster

Det finns några återkommande sätt att låta agenter samverka, och valet påverkar både robusthet och felsökbarhet:

• Dirigent och utförare: en orkestrerande agent delegerar till specialister och väger ihop resultaten. Tydligt ansvar, lätt att felsöka.
• Sekventiell kedja: agenter i en pipeline där varje förädlar föregående output. Förutsägbart men känsligt för fel tidigt i kedjan.
• Fri samverkan: agenter pratar relativt fritt med varandra. Flexibelt men svårt att förutse och dyrt - jag undviker det i produktion.

I de flesta produktionsfall landar jag i dirigent-och-utförare, eftersom det ger ett tydligt ställe att placera kontroll, loggning och felhantering. Det här är också där ett ramverk som LangGraph kan göra nytta, vilket jag jämför i artikeln om LangChain, LangGraph och LlamaIndex.

Delegation och tydliga gränssnitt

Nyckeln till ett fungerande multi-agent-system är att varje agent har ett snävt, väldefinierat ansvar och ett tydligt gränssnitt - vad den tar emot och vad den lovar att returnera. Suddiga ansvar leder till att agenter trampar varandra på tårna eller gör samma sak dubbelt. Jag definierar dessa kontrakt strikt, gärna med strukturerade in- och utdata, vilket hänger ihop med det jag skriver om structured outputs.

Ett vanligt misstag är att ge en agent för mycket att göra för att slippa skapa ytterligare en. Då får man tillbaka samma röra som en enda gigantisk prompt, fast utspridd. Min tumregel är att en agent ska kunna beskrivas i en mening utan ordet "och". Klarar du inte det är ansvaret för brett, och agenten bör antingen delas eller så är hela uppdelningen fel ansats. Snäva agenter är dessutom lättare att testa var för sig, vilket gör hela systemet möjligt att utvärdera bit för bit.

Konfliktlösning när agenter är oense

Förr eller senare ger två agenter motstridiga svar. Ett system utan plan för det fastnar eller väljer godtyckligt. Jag bygger in en uttalad mekanism: antingen en överordnad agent som dömer av, en omröstning, eller en regel om att en viss roll har sista ordet inom sitt område. Det viktiga är att konfliktlösningen är explicit och loggad, inte en slump beroende på vilken agent som råkade svara sist.

Loopar, kostnad och att veta när det är klart

Den farligaste felmoden i multi-agent-system är agenter som skickar arbete fram och tillbaka utan att konvergera. Varje varv kostar tokens och tid. Jag sätter alltid hårda tak: maximalt antal steg, en budget per uppgift, och ett tydligt avslutskriterium. Utan det kan en enda förfrågan dra iväg i kostnad - något jag återkommer till i artikeln om kostnadsoptimering.

Att avgöra om ett problem verkligen tjänar på flera agenter, och i så fall strukturera dem så att de blir robusta snarare än bräckliga, är just den sortens arbete jag gör inom AI Engineering.

Delat minne och hur kontext förs vidare

En underskattad svårighet är hur agenter delar information. Ger du varje agent hela historiken växer kontexten - och därmed kostnaden och risken för förvirring - för varje steg. Ger du dem för lite tappar de tråden. Jag försöker därför vara medveten om exakt vad varje agent behöver veta och skicka just det, inte allt. Ofta innebär det att dirigenten håller helhetsbilden och förser varje specialist med ett destillat snarare än hela konversationen. Det håller nere kostnaden och gör dessutom varje agents uppgift tydligare, eftersom den inte distraheras av irrelevant kontext.

Observerbarhet är inte valfritt

Med flera agenter blir det snabbt oklart varför systemet gjorde som det gjorde. Jag loggar varje delegering, varje verktygsanrop och varje beslut, så att ett konstigt slutresultat går att spåra till rätt agent. Utan den spårbarheten blir felsökning gissningslek, och utvärdering enligt mina evals-principer blir omöjlig.

Relaterat

• LangChain vs LangGraph vs LlamaIndex: Vilken passar ert use case?
• Evals för LLM-appar: Bygga test-suiter som faktiskt fångar regressioner
• Voice AI för kundtjänst: OpenAI Realtime + Twilio i svensk produktion

Ett exempel på var jag valde bort multi-agent till förmån för en enklare lösning finns bland mina kundcase.

Vill du ta det vidare?

Funderar ni på ett multi-agent-upplägg och vill veta om det är rätt väg eller överkonstruktion? Boka ett förutsättningslöst samtal så går vi igenom ert problem innan ni bygger.