Swarm vs Graph orkestrering - Strands Agents

Et konkret eksempel er værktøjet fra Thrad.ai, bygget på Strands Agents og Amazon Bedrock AgentCore. Systemet tager en strøm af rå emner, typisk fra sociale medier eller nyhedskilder, og forvandler dem til personaliserede e-mails uden menneskelig indblanding undervejs. Det kræver flere trin: emnerne skal findes, vurderes, prioriteres og til sidst omsættes til tekst, der giver mening for modtageren.

Det er netop denne kæde af trin, der gør orkestreringsvalget vigtigt. Jo flere agenter der skal koordinere, jo mere betyder det, om de arbejder parallelt eller i en fast rækkefølge. Vi har set samme mønster hos vores egne kunder: et system, der virker fint med tre agenter, kan blive langsomt og dyrt, når det skalerer til ti.

Thrad.ai har testet begge arkitekturer direkte mod hinanden, og forskellen er ikke marginal. Swarm-modellen, hvor agenterne selv forhandler opgavefordelingen indbyrdes, giver mere fleksibilitet, men den koster i latens. Hver runde af intern koordinering lægger tid oveni, fordi agenterne skal blive enige, før arbejdet kan fortsætte.

Graph-modellen, hvor flowet er defineret som en fast sekvens af trin, er hurtigere og mere forudsigelig, fordi der ikke er nogen forhandling at vente på. Til gengæld er den mindre modstandsdygtig over for uventede input. Hvis en opgave falder uden for den forudbestemte struktur, har grafen sværere ved at improvisere sig ud af det end sværmen.

Den praktiske konklusion er ikke, at den ene arkitektur vinder over den anden. Det er, at valget bør følge opgavens natur. Faste, gentagne arbejdsgange med forudsigelige input passer til Graph. Opgaver med stor variation i input, hvor systemet skal kunne tilpasse sig undervejs, passer bedre til Swarm, selv om det koster ekstra i tid og beregningskraft.

En stor del af værdien i et system som dette ligger ikke i selve orkestreringen, men i hvordan det udvælger, hvad der er værd at skrive om. Thrad.ais system scorer indkommende emner på flere parametre samtidig: hvor relevant emnet er for modtagerens interesser, hvilken hensigt der ligger bag (er det nyt, er det handlingsorienteret, er det blot baggrund), og hvor gammelt emnet er.

Det sidste punkt, tidsmæssigt henfald, er ofte overset i simplere systemer. Et emne, der var relevant for tre dage siden, mister værdi, selv hvis indholdet i sig selv stadig er korrekt. Ved at lade scoringen falde over tid undgår systemet at sende forældet indhold ud, som om det var frisk. Det er en detalje, men den afgør, om modtageren oplever værktøjet som opdateret eller som et automatiseret nyhedsbrev, der ikke har opdaget, at ugen er gået.

At lade AI-agenter arbejde autonomt over tid kræver mere end en god arkitektur. Det kræver styring, der forhindrer systemet i at løbe løbsk, både fagligt og økonomisk. Governance-lag i systemer som dette dækker typisk ting som grænser for, hvor mange agent-kald en opgave må bruge, kontrol af, at output faktisk matcher det forventede format, og logning, der gør det muligt at spore, hvorfor systemet traf en bestemt beslutning.

Det er her, mange multi-agent projekter falder fra hinanden i praksis. Det er relativt let at bygge en demo, hvor agenterne samarbejder pænt på et lille datasæt. Det er en anden opgave at holde systemet stabilt, når det kører kontinuerligt, mod skiftende input, i produktion. Som principal konsulent hos AI Enterprise har jeg set gentagne gange, at netop governance-laget, ikke selve AI-modellen, er det, der afgør, om et multi-agent projekt overlever sin første måned i drift.

For en dansk virksomhed, der overvejer at bygge egne AI-agent-løsninger, er pointen fra Thrad.ais benchmarks ikke, at Strands Agents eller Bedrock AgentCore er de eneste rigtige værktøjer. Pointen er, at arkitekturvalget skal træffes bevidst, med opgavens karakter som udgangspunkt, ikke som en teknisk detalje, der klares senere.

En fast Graph-struktur er ofte det rigtige valg til processer, I allerede kender godt: rapportering, klassificering, faste arbejdsgange med begrænset variation. En Swarm-struktur giver mening, hvor opgaverne varierer meget, og hvor systemet skal kunne håndtere det uventede uden at gå i stå. Begge dele kræver samme fundament: klare grænser for, hvad agenterne må gøre, og løbende overvågning af, hvad de rent faktisk gør, når ingen ser med.