Up North AIUp North
Tilbage til indsigt
5 min læsning

Multi-Agent Koordinationskrisen

Multi-Agent Koordinationskrisen. CAID: Software Engineering Primitiver for AI Teams. Tallene: Hvorfor Koordination Slår Compute.

orchestrationagentsinfrastructure
Share

Multi-Agent Koordinationskrisen

Nuværende multi-agent tilgange er pinligt primitive. De fleste systemer er afhængige af prompt-baseret koordination: "Agent A, du håndterer frontend. Agent B, arbejd på backend. Prøv ikke at ødelægge hinandens kode." Dette virker omtrent så godt som man kunne forvente.

Problemerne forværres hurtigt. Agenter mangler ægte isolation, så en agents ændringer kan korrumpere en andens kontekst. Kommunikation sker gennem ustruktureret naturligt sprog, hvilket skaber telefon-spil forvrængninger. Der er ingen systematisk måde at håndtere konflikter på eller sikre integrationskvalitet. Resultatet er ofte værre end single-agent performance, på trods af 3-5x højere API-omkostninger [1].

CMU's forskningsteam, ledet af forskere der studerer software engineering automatisering, identificerede kerneproblemstillingen: multi-agent systemer har brug for de samme koordinationsprimitiver, der gør menneskelige software teams funktionelle. Løsningen er ikke bedre prompts eller smartere routing—det er git-native orchestration der spejler afprøvede udviklingsworkflows.

CAID: Software Engineering Primitiver for AI Teams

CAID virker ved at dekomponere komplekse opgaver til dependency graphs, og derefter delegere isolerede delopgaver til specialist-agenter, der arbejder i parallelle git worktrees. Tænk på det som at anvende Scrum-metodologi på AI-agenter, men med disciplinen fra versionskontrolsystemer.

Sådan udfolder workflowet sig:

Task Decomposition: En manager-agent analyserer den indkommende forespørgsel og bygger en dependency graph af delopgaver. I stedet for vage naturlige sprog instruktioner, skaber dette strukturerede, testbare arbejdsenheder med klare interfaces og succeskritierier.

Isoleret Delegering: Hver delopgave bliver tildelt til en ingeniør-agent, der arbejder i sit eget git worktree. Dette giver ægte isolation—agenter kan ikke ved et uheld overskrive hinandens ændringer eller korrumpere delt tilstand. Isolationen er hård, ikke blød—ingen mængde prompting kan erstatte faktisk filsystem-separation [1].

Asynkron Udførelse: Agenter arbejder parallelt på uafhængige delopgaver, med dependency graph'en der sikrer korrekt sekvensering. Dette spejler hvordan menneskelige teams håndterer komplekse features: frontend og backend udviklere arbejder samtidigt, og integrerer derefter på definerede checkpoints.

Selv-Verificering: Hver agent kører tests og validerer sit eget arbejde før indsendelse. Dette fanger åbenlyse fejl tidligt og reducerer integrationsbyrden på manager-agenten.

Git-Native Integration: Manager-agenten håndterer merges ved hjælp af standard git workflows, med konfliktløsning og final validering. Dette udnytter årtiers værktøjer og best practices fra menneskelig software udvikling.

Tallene: Hvorfor Koordination Slår Compute

Performance-gevinsterne er slående, især for komplekse opgaver der kræver vedvarende ræsonnement på tværs af flere domæner.

PaperBench (reproduktion af machine learning papers fra beskrivelser), leverede CAID massive forbedringer på tværs af model-tiers:

  • Claude 4.5: 57.2% → 63.3% (+26.7% relativ)
  • MiniMax 2.5: 10.4% → 36.7% (+253% relativ)
  • Svagere modeller så de største gevinster, med 3.5x relativ forbedring i gennemsnit [2]

Commit0-Lite (implementering af features i Python biblioteker som tinydb), var gevinsterne mere beskedne men konsistente:

  • Claude 4.5: 53.1% → 59.1% (+14.3% relativ)
  • Mønsteret holdt på tværs af forskellige model-familier og størrelser [1]

Isolationsmekanismen viste sig kritisk. Hård git worktree isolation opnåede 63.3% nøjagtighed, mens blød instruktions-baseret isolation kun klarede 55.5%—faktisk værre end single-agent baselines. Dette antyder at ægte koordination kræver infrastruktur, ikke bare prompting [1].

Omkostningerne steg 3-5x på grund af parallel agent-udførelse, men der er ingen runtime speedup fordi git merges sker sekventielt. Værdiforslaget er nøjagtighed og pålidelighed, ikke hastighed.

Builder's Playbook: Implementering af Git-Native Orchestration

For teams der er klar til at implementere disse mønstre, fremkommer flere praktiske principper fra forskningen og tidlige produktionsimplementeringer.

Start med dependency mapping. Før du spinner flere agenter op, invester i task decomposition værktøjer. JSON-strukturerede kommunikationsprotokoller virker bedre end naturligt sprog til koordination. CMU-teamet fandt at vedligeholdelse af en AGENTS.md fil, der dokumenterer almindelige mønstre og fejlmodes, forbedrede succesrater med 4% [3].

Optimer for 3-5 agenter maksimalt. Flere agenter forbedrer ikke lineært performance—koordinations-overhead vokser kvadratisk. Redis forskning bekræfter at koordinationsomkostninger negerer parallelisme-fordele medmindre de håndteres omhyggeligt [5].

Design for verificering, ikke perfektion. Hver agent bør validere sit eget arbejde med tests og checks før indsendelse. Manager-agenten kan fokusere på integration frem for debugging af individuelle komponenter.

Brug afprøvede værktøjer hvor muligt. Git worktrees giver kampafprøvet isolation. Eksisterende CI/CD pipelines kan håndtere validering og testing. Værktøjer som Conductor og Claude Code Web er ved at opstå for at håndtere orchestration logistik [3].

Tune manager-ingeniør balancen. Nogle teams drager fordel af ingeniør-agenter der laver selv-verificering; andre har brug for manager-agenter til at gennemgå alt arbejde. Dette afhænger af opgavekompleksitet og model-kapaciteter.

Case Study: Fra Paper til Produktion

PaperBench resultaterne illustrerer hvorfor koordination betyder mere end rå model-intelligens. Reproduktion af ML papers kræver vedvarende ræsonnement på tværs af flere domæner: forståelse af matematiske koncepter, implementering af algoritmer, debugging af kode, og validering af resultater.

Ingeniør skitserer software blueprints i nordisk værksted mens team bygger produktionsstruktur udenfor

Single agenter, selv kraftfulde som Claude 4.5, kæmper med denne kompleksitet. De rammer måske algoritme-implementeringen men misser subtile preprocessing trin. Eller de får matematikken rigtigt men introducerer bugs under kode-oversættelse.

CAID's dependency graph tilgang opdeler paper-reproduktion i naturlige delopgaver: litteraturgennemgang, matematisk analyse, implementering, testing, og validering. Hver agent kan fokusere på sin specialitet mens manageren sikrer korrekt integration.

Den 26.7% forbedring på Claude 4.5 repræsenterer forskellen mellem "virker nogle gange" og "virker pålideligt" for komplekse software engineering opgaver. Det er tærsklen hvor AI kode-assistance bliver genuint nyttig for produktionsteams.

Orchestration Stack: Hvad Er Det Næste

CAID forskningen peger mod et bredere skift i AI udviklings-infrastruktur. Ligesom menneskelige software teams udviklede sig fra cowboy coding til moderne DevOps praksisser, har AI agent teams brug for systematiske koordinationsprimitiver.

AgentOrchestra og lignende frameworks er ved at opstå for at give hierarkisk task execution og adaptiv planlægning [6]. Disse værktøjer behandler orchestration som en førsteklasses engineering disciplin, ikke en eftertanke.

Den næste bølge vil sandsynligvis inkludere:

  • Standardiserede agent kommunikationsprotokoller (ud over JSON)
  • Dependency-aware task scheduling med automatisk parallelisering
  • Integration testing frameworks designet til multi-agent workflows
  • Observability værktøjer til debugging af koordinationsfejl

Nordiske virksomheder, med deres stærke software engineering kultur, er godt positioneret til at lede denne overgang. Vægtlægningen af systematiske processer og kvalitets-engineering stemmer naturligt overens med git-native orchestration principper.

Når AI Bygger Softwaren: Koordinationsrevolutionen

Den dybere indsigt fra CAID forskning handler ikke bare om bedre multi-agent systemer—det handler om hvad der ændrer sig når AI bliver den primære software builder frem for en kode-assistent.

Menneskelige udviklingsteams udviklede sofistikerede koordinationsmekanismer fordi software kompleksitet kræver det. Efterhånden som AI agenter overtager større dele af udviklingslivscyklussen, vil de have brug for lige så sofistikeret koordination. Kodegenerering bliver commoditized; orchestration er den nye differentiator.

Dette skift har dybe implikationer for hvordan vi tænker på AI udviklingsværktøjer. I stedet for at optimere for single-agent performance på isolerede opgaver, har vi brug for infrastruktur der muliggør pålideligt samarbejde mellem specialiserede AI systemer.

De teams der mestrer dette koordinationslag først vil bygge AI produkter der er kvalitativt forskellige—ikke bare hurtigere eller billigere, men i stand til vedvarende ræsonnement på tværs af komplekse domæner som single agenter ikke kan håndtere.

CAID beviser at vejen fremad ikke er mere kraftfulde modeller eller kloge prompts. Det er at anvende afprøvet engineering disciplin på AI systemer. Kode er gratis. Koordination 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

Vil du gå dybere?

Vi udforsker fronten af AI-bygget software ved faktisk at bygge den. Se hvad vi arbejder på.