Krisen i koordinering av flere agenter

Krisen i koordinering av flere agenter

Dagens tilnærminger til flere agenter er pinlig primitive. De fleste systemer baserer seg på prompt-basert koordinering: "Agent A, du håndterer frontend. Agent B, jobb med backend. Prøv å ikke ødelegge hverandres kode." Dette fungerer omtrent så godt som du forventer.

Problemene forverres raskt. Agenter mangler ekte isolasjon, så en agents endringer kan korrumpere en annens kontekst. Kommunikasjon skjer gjennom ustrukturert naturlig språk, som skaper telefon-spill-forvrengninger. Det finnes ingen systematisk måte å håndtere konflikter eller sikre integrasjonskvalitet. Resultatet er ofte verre enn enkelt-agent-ytelse, til tross for 3-5x høyere API-kostnader [1].

CMUs forskningsteam, ledet av forskere som studerer automatisering av programvareutvikling, identifiserte kjerneproblemet: systemer med flere agenter trenger de samme koordineringsprimitivene som gjør menneskelige programvareteam funksjonelle. Løsningen er ikke bedre prompts eller smartere ruting—det er git-native orkestrering som speiler beviste utviklingsarbeidsflyter.

CAID: Programvareutviklingsprimitiver for AI-team

CAID fungerer ved å dekomponere komplekse oppgaver til avhengighetsgrafer, deretter delegere isolerte deloppgaver til spesialiserte agenter som jobber i parallelle git-arbeidsområder. Tenk på det som å anvende Scrum-metodikk på AI-agenter, men med disiplinen til versjonskontrollsystemer.

Slik utfolder arbeidsflyten seg:

Oppgavedekomponering: En lederagent analyserer den innkommende forespørselen og bygger en avhengighetsgraf av deloppgaver. I stedet for vage naturlige språkinstruksjoner, skaper dette strukturerte, testbare arbeidsenheter med klare grensesnitt og suksesskriterier.

Isolert delegering: Hver deloppgave blir tildelt en ingeniøragent som jobber i sitt eget git-arbeidsområde. Dette gir ekte isolasjon—agenter kan ikke ved et uhell overskrive hverandres endringer eller korrumpere delt tilstand. Isolasjonen er hard, ikke myk—ingen mengde prompting kan erstatte faktisk filsystemseparasjon [1].

Asynkron utførelse: Agenter jobber parallelt på uavhengige deloppgaver, med avhengighetsgrafen som sikrer riktig sekvensering. Dette speiler hvordan menneskelige team håndterer komplekse funksjoner: frontend- og backend-utviklere jobber samtidig, deretter integrerer ved definerte kontrollpunkter.

Selvverifisering: Hver agent kjører tester og validerer sitt eget arbeid før innsending. Dette fanger opp åpenbare feil tidlig og reduserer integrasjonsbyrden på lederagenten.

Git-native integrasjon: Lederagenten håndterer sammenslåinger ved bruk av standard git-arbeidsflyter, med konfliktløsning og endelig validering. Dette utnytter tiår med verktøy og beste praksis fra menneskelig programvareutvikling.

Tallene: Hvorfor koordinering slår beregningskraft

Ytelsesgevinstene er slående, spesielt for komplekse oppgaver som krever vedvarende resonnering på tvers av flere domener.

På PaperBench (reprodusering av maskinlæringsartikler fra beskrivelser), leverte CAID massive forbedringer på tvers av modellnivåer:

• Claude 4.5: 57,2% → 63,3% (+26,7% relativt)
• MiniMax 2.5: 10,4% → 36,7% (+253% relativt)
• Svakere modeller så de største gevinstene, med 3,5x relativ forbedring i gjennomsnitt [2]

På Commit0-Lite (implementering av funksjoner i Python-biblioteker som tinydb), var gevinstene mer beskjedne men konsistente:

• Claude 4.5: 53,1% → 59,1% (+14,3% relativt)
• Mønsteret holdt seg på tvers av forskjellige modellfamilier og størrelser [1]

Isolasjonsmekanismen viste seg kritisk. Hard git-arbeidsområde-isolasjon oppnådde 63,3% nøyaktighet, mens myk instruksjonsbasert isolasjon klarte bare 55,5%—faktisk verre enn enkelt-agent-baselines. Dette antyder at ekte koordinering krever infrastruktur, ikke bare prompting [1].

Kostnadene økte 3-5x på grunn av parallell agentutførelse, men det er ingen kjøretidshastighetsøkning fordi git-sammenslåinger skjer sekvensielt. Verdipropposisjonen er nøyaktighet og pålitelighet, ikke hastighet.

Byggerens spillebok: Implementering av git-native orkestrering

For team som er klare til å implementere disse mønstrene, fremkommer flere praktiske prinsipper fra forskningen og tidlige produksjonsutplasseringer.

Start med avhengighetskartlegging. Før du spinner opp flere agenter, invester i verktøy for oppgavedekomponering. JSON-strukturerte kommunikasjonsprotokoller fungerer bedre enn naturlig språk for koordinering. CMU-teamet fant at vedlikehold av en AGENTS.md-fil som dokumenterer vanlige mønstre og feilmodi forbedret suksessrater med 4% [3].

Optimaliser for maksimalt 3-5 agenter. Flere agenter forbedrer ikke ytelsen lineært—koordineringsoverhead vokser kvadratisk. Redis-forskning bekrefter at koordineringskostnader negerer parallelismefordeler med mindre de håndteres nøye [5].

Design for verifisering, ikke perfeksjon. Hver agent bør validere sitt eget arbeid med tester og kontroller før innsending. Lederagenten kan fokusere på integrasjon i stedet for feilsøking av individuelle komponenter.

Bruk beviste verktøy der det er mulig. Git-arbeidsområder gir kampprøvd isolasjon. Eksisterende CI/CD-pipelines kan håndtere validering og testing. Verktøy som Conductor og Claude Code Web dukker opp for å håndtere orkestreringslogistikk [3].

Juster leder-ingeniør-balansen. Noen team drar nytte av at ingeniøragenter gjør selvverifisering; andre trenger lederagenter til å gjennomgå alt arbeid. Dette avhenger av oppgavekompleksitet og modellkapasiteter.

Casestudie: Fra artikkel til produksjon

PaperBench-resultatene illustrerer hvorfor koordinering betyr mer enn rå modellintelligens. Reprodusering av ML-artikler krever vedvarende resonnering på tvers av flere domener: forståelse av matematiske konsepter, implementering av algoritmer, feilsøking av kode og validering av resultater.

Enkle agenter, selv kraftige som Claude 4.5, sliter med denne kompleksiteten. De kan kanskje mestre algoritmeimplementeringen, men gå glipp av subtile forbehandlingstrinn. Eller de får matematikken riktig, men introduserer feil under kodeoversettelse.

CAIDs avhengighetsgraf-tilnærming bryter artikkelreproduksjon ned i naturlige deloppgaver: litteraturgjennomgang, matematisk analyse, implementering, testing og validering. Hver agent kan fokusere på sin spesialitet mens lederen sikrer riktig integrasjon.

Den 26,7% forbedringen på Claude 4.5 representerer forskjellen mellom "fungerer noen ganger" og "fungerer pålitelig" for komplekse programvareutviklingsoppgaver. Det er terskelen hvor AI-kodingsassistanse blir genuint nyttig for produksjonsteam.

Orkestreringsstack: Hva kommer nå

CAID-forskningen peker mot et bredere skifte i AI-utviklingsinfrastruktur. Akkurat som menneskelige programvareteam utviklet seg fra cowboy-koding til moderne DevOps-praksis, trenger AI-agentteam systematiske koordineringsprimitiver.

AgentOrchestra og lignende rammeverk dukker opp for å gi hierarkisk oppgaveutførelse og adaptiv planlegging [6]. Disse verktøyene behandler orkestrering som en førsteklasses ingeniørdisiplin, ikke en ettertanke.

Den neste bølgen vil sannsynligvis inkludere:

• Standardiserte agentkommunikasjonsprotokoller (utover JSON)
• Avhengighetsbevisst oppgaveplanlegging med automatisk parallelisering
• Integrasjonstestingrammeverk designet for arbeidsflyter med flere agenter
• Observabilitetsverktøy for feilsøking av koordineringsfeil

Nordiske selskaper, med sin sterke programvareutviklingskultur, er godt posisjonert til å lede denne overgangen. Vektleggingen av systematiske prosesser og kvalitetsteknikk stemmer naturlig overens med git-native orkestreringsrprinsipper.

Når AI bygger programvaren: Koordineringsrevolusjonen

Den dypere innsikten fra CAID-forskningen handler ikke bare om bedre systemer med flere agenter—det handler om hva som endres når AI blir den primære programvarebyggeren i stedet for en kodingsassistent.

Menneskelige utviklingsteam utviklet sofistikerte koordineringsmekanismer fordi programvarekompleksitet krever det. Ettersom AI-agenter tar på seg større deler av utviklingslivssyklusen, vil de trenge like sofistikert koordinering. Kodegenerering blir kommodifisert; orkestrering er den nye differensiatoren.

Dette skiftet har dype implikasjoner for hvordan vi tenker på AI-utviklingsverktøy. I stedet for å optimalisere for enkelt-agent-ytelse på isolerte oppgaver, trenger vi infrastruktur som muliggjør pålitelig samarbeid mellom spesialiserte AI-systemer.

Teamene som mestrer dette koordineringslaget først vil bygge AI-produkter som er kvalitativt forskjellige—ikke bare raskere eller billigere, men i stand til vedvarende resonnering på tvers av komplekse domener som enkle agenter ikke kan håndtere.

CAID beviser at veien fremover ikke er kraftigere modeller eller smarte prompts. Det er å anvende bevist ingeniørdisiplin på AI-systemer. Kode er gratis. Koordinering er det ikke.

Kilder

1. https://arxiv.org/abs/2603.21489
2. https://bemiagent.com/agents/caid-what-cmu-learned-about-making-multiple-agents-code-together-without-breaking-everything
3. https://addyosmani.com/blog/code-agent-orchestra
4. https://www.linkedin.com/posts/omarsar_new-research-from-cmu-bookmark-this-one-activity-7444393288272379905-enu3
5. https://redis.io/blog/multi-agent-systems-coordinated-ai
6. https://arxiv.org/abs/2506.12508
7. https://medium.com/design-bootcamp/running-multiple-ai-agents-at-once-using-git-worktrees-57759e001d7a