Agentkoordinering slår Opus 4.8

Forsøget stiller et konkret spørgsmål: kan flere mindre koordinerede agenter løse en opgave bedre end én stærk model, der arbejder for sig selv? På SWE-Atlas, som tester agenters evne til at navigere i rigtige kodebaser og løse konkrete fejl, var svaret ja. Fire Claude Code-agenter, der delte information undervejs, nåede en markant højere nøjagtighed end Opus 4.8, som arbejdede alene på de samme opgaver.

Det er en pointe, der rammer bredere end selve benchmarket. Vi har i mange virksomhedsprojekter set, at flaskehalsen sjældent er, hvor "klog" den enkelte model er. Det er, hvordan opgaven bliver skåret op, og hvordan de involverede dele får besked om, hvad de andre har fundet ud af undervejs.

Mekanismen kaldes AgentRadio, og navnet er præcist: agenterne sender korte statusbeskeder til hinanden, mens de arbejder, i stedet for at vente på, at hele opgaven er løst, før noget deles. Det er et asynkront besked-lag, der kører parallelt med selve kodearbejdet, ikke en central koordinator, der uddelegerer opgaver og venter på svar.

Den forskel er vigtig. En synkron opsætning, hvor én agent venter på, at en anden er helt færdig, skaber ventetid og gør systemet skrøbeligt, hvis én del går i stå. Med et asynkront lag kan en agent, der finder en relevant fil eller opdager en fejlkilde, sende den information videre med det samme, og de andre agenter kan reagere på den, hvis den er relevant for deres del af opgaven. Ingen af agenterne behøver at stå stille og vente på en fælles opsummering.

Det betyder også, at systemet holder, selv når agenter arbejder i forskelligt tempo. En agent, der er hurtigt igennem sin del, blokerer ikke resten af holdet, og en agent, der støder på en svær delopgave, trækker ikke automatisk hele processen ned, fordi de andre kan fortsætte parallelt.

Forskellen i resultatet på SWE-Atlas er ikke marginal. Fire-agent-opsætningen med AgentRadio nåede en nøjagtighed, der lå tæt på det dobbelte af, hvad Opus 4.8 opnåede alene på de samme opgaver. Det er en stor forskel for et benchmark, der er designet til at ligne rigtigt softwarearbejde: agenten skal finde den relevante kode i en ukendt kodebase, forstå sammenhængen og rette fejlen uden at ødelægge noget andet undervejs.

Det er præcis den type opgave, hvor koordination betaler sig. En enkelt agent, der arbejder alene, skal selv holde styr på hele kodebasen i sit eget arbejdshukommelse, mens den løser opgaven. Fire agenter, der deler observationer undervejs, kan i praksis dele den belastning mellem sig, hver med sit eget fokusområde, men med adgang til, hvad de andre har fundet.

Resultatet peger på noget, mange, der har bygget agent-systemer i praksis, allerede har en fornemmelse af: en stærkere model løser ikke automatisk et koordinationsproblem. Uden et lag, der lader agenterne dele information i realtid, mister man en stor del af den fordel, det giver at sætte flere agenter på en opgave.

Den naturlige antagelse er, at en nyere, kraftigere model altid vinder. Det billede holder ikke i dette forsøg. Opus 4.8 er en stærk model, men når den arbejder alene på en kompleks kodeopgave, mangler den den kontekst, som fire mindre koordinerede agenter tilsammen bygger op undervejs.

Det handler om arbejdsdeling, ikke om, at flere agenter automatisk er smartere. Når fire agenter deler en opgave og løbende informerer hinanden om, hvad de finder, opstår der en form for kollektiv kontekst, som ingen af agenterne har alene. Den ene agent kan bruge en anden agents opdagelse til at undgå at gentage arbejde eller til at undgå en fejlagtig antagelse, som den ellers ville have bygget videre på.

Det er en pointe, jeg ser bekræftet igen og igen i mine egne AI-projekter. Jeg har fulgt talrige AI-projekter fra problemafklaring til drift, og erfaringen er entydig: den arkitektur, agenterne kører i, afgør ofte mere for det endelige resultat end selve modelvalget.

For virksomheder, der overvejer at sætte AI-agenter til at løse komplekse, sammensatte opgaver, ændrer det noget ved, hvor man bør lægge sin indsats. Det er fristende at tænke, at næste skridt altid er en kraftigere model. Dette forsøg peger på, at gevinsten ofte ligger et andet sted: i hvordan man strukturerer flere agenters samarbejde om en opgave.

For kodeopgaver, dokumentanalyse og andre processer, hvor arbejdet naturligt kan deles op i afgrænsede dele med afhængigheder mellem dem, er det værd at overveje en koordineret multi-agent-opsætning frem for at satse alt på én stor model. Det kræver mere arkitektur op front, men resultaterne her tyder på, at investeringen kan betale sig markant, særligt på opgaver, der ligner virkelige, rodede kodebaser mere end rene, isolerede testopgaver.

Det ændrer heller ikke ved, at menneskelig kontrol stadig er nødvendig. Flere agenter, der koordinerer, betyder flere led, hvor fejl kan opstå og forplante sig, hvis ingen holder øje med helheden. Men når koordinationen er sat rigtigt op, viser dette forsøg, at resultatet kan overgå, hvad selv den stærkeste enkeltstående model leverer alene.