Sluta bygga organisationsscheman för era AI-agenter

Det finns ett mönster som dyker upp överallt just nu. Team sätter upp grupper av AI-agenter som speglar klassiska utvecklingsteam. En produktägare som delegerar till en teamlead, som koordinerar en frontend-utvecklare, en backend-utvecklare och en QA-agent. Ramverk som CrewAI uppmuntrar det explicit. Deras egen beskrivning handlar om att "orkestrera rollspelande, autonoma AI-agenter."

Strukturen ser ut som något vi känner igen. Och det är precis det som är problemet.

Vi projicerar för att det känns tryggt

När ny teknik dyker upp gör vi alltid samma sak: vi sträcker oss efter gamla metaforer. De första bilarna såg ut som hästkärror. De första digitala böckerna hade sidor man bläddrade i. De första webbsidorna såg ut som tryckta broschyrer.

Det är en naturlig reflex. Ställda inför något vi inte riktigt förstår, försöker vi förstå det utifrån det vi redan vet. Och det vi vet inom mjukvaruutveckling är team. Roller. Hierarkier. Standups.

Så när vi får tillgång till ett verktyg som kan köra tio autonoma kodagenter samtidigt, vad gör vi? Vi bygger en liten organisation. Produktägare. Arkitekt. Frontend-lead. Backend-lead. QA.

Vi namnger dem, ger dem systemprompts som beskriver deras "personlighet" och skapar kommunikationskanaler mellan dem. Det känns strukturerat. Det känns hanterbart.

Men det är en skeuomorf. Vi kopierar formen av något utan att fråga oss varför formen såg ut som den gjorde från början.

Varför team ser ut som de gör

Traditionella utvecklingsteam är organiserade kring mänskliga begränsningar. Vi specialiserar oss för att en enskild person inte kan hålla hela systemet i huvudet. Vi har teamleads för att någon behöver översätta mellan de som bygger och de som bestämmer vad som ska byggas. Vi har QA som en separat roll för att den som skrev koden ofta är blind för dess brister.

Det här är lösningar på mänskliga problem. Begränsad uppmärksamhet, begränsat arbetsminne, behov av sömn.

En AI-agent har inte de begränsningarna. En enda instans kan skriva frontend, bygga API:et, sätta upp databasen och skriva testerna. Den behöver ingen manager och tappar inte kontexten vid byte mellan TypeScript och SQL.

När vi delar upp den förmågan i fem separata agenter med strikta rollgränser spelar vi inte med teknikens styrkor. Vi för in begränsningar som inte behöver finnas.

Det kostar på riktigt

Det här är inte bara filosofi. Organisationsmetaforen skapar konkreta problem.

Oavsett hur agenterna kommunicerar, via filer, funktionsanrop eller meddelandeköer, så introducerar varje mellanlager overhead som inte behövde finnas. En enda agent har redan delad kontext i sitt fönster. Att dela upp det i fem agenter som måste koordinera sinsemellan är att ersätta något enkelt med något komplicerat.

När man tillsätter en produktägaragent som delegerar och följer upp, har man skapat ett koordineringslager som bränner tokens på att administrera istället för att bygga. Spillet kommer från organisationsstrukturen, inte från problemet man försöker lösa.

Och när man ger en agent identiteten "arkitekt" ska man inte bli förvånad om den spenderar timmar på analys utan att producera något konkret. Den spelar rollen man gav den.

Där rollmetaforen faktiskt fungerar

Det finns evidens för att specialiserade perspektiv förbättrar resultatet. Benchmarks som SWE-bench visar att multi-agent-system med en planerare, en kodare och en granskare presterar bättre än enskilda agenter på komplexa uppgifter. Runt 7 procentenheter bättre, faktiskt, när man lägger till en granskarroll som utvärderar output innan den skickas in.

Men titta på vad som faktiskt fungerar. Det är inte identiteten. Det är perspektivbytet. Att köra ett granskningssteg, en separat fas där koden granskas med andra ögon och ett annat mål, det är värdefullt.

Det är ett steg i en pipeline, inte en permanent teammedlem.

Det är skillnad på "kör en säkerhetsgenomgång som steg 4" och "anställ en säkerhetsexpert-agent som sitter sysslolös tills någon skickar den något att granska." Det ena är en process. Det andra är ett organisationsschema.

Tänk i uppgifter, inte i titlar

När jag kör flera agenter parallellt är uppdelningen aldrig rollbaserad. Den är uppgiftsbaserad.

Finns det fem API-endpoints att porta? Starta fem agenter som var och en hanterar en endpoint hela vägen. Varje agent gör hela jobbet: läser den gamla implementationen, skriver den nya, lägger till tester, verifierar att det fungerar. Inget koordineringslager behövs. Ingen inbox. Inga statusmöten.

Det fungerar för att det som parallelliseras är arbetsuppgiften, inte jobbtiteln. När uppgiften är klar är agenten klar.

Tvärgående frågor som säkerhet, tillgänglighet och prestanda kör jag som granskningspass efter att arbetet är klart. En dedikerad genomgång, inte en dedikerad person.

Varför multi-agent alls?

Den stora vinsten med flera agenter är parallellism. Fem uppgifter som körs samtidigt istället för efter varandra. Det är en riktig hastighetsförbättring, och det är också därför uppdelning per uppgift fungerar så mycket bättre än per roll. Varje agent får ett avgränsat, fristående arbetspaket och kör det hela vägen.

En annan viktig anledning är kontext. Nuvarande modeller har ändliga kontextfönster och komplexa projekt kan överskrida dem. Att dela upp arbetet på flera agenter är ett praktiskt sätt att hantera det. Men i takt med att kontextfönstren växer minskar det behovet. Parallellism däremot försvinner aldrig som argument.

Ingen av de anledningarna kräver ett organisationsschema.

En bättre fråga

Nästa gång du designar en multi-agent-uppsättning, testa det här: istället för att fråga "vilka roller behöver mitt team?", fråga "vilka uppgifter kan köras oberoende av varandra?"

Den första frågan drar dig mot organisationsscheman, hierarkier och kommunikationsprotokoll. Den andra drar dig mot parallellism, tydliga gränser och minimal koordinering.

Den ena utgår från hur människor alltid har jobbat. Den andra utgår från hur tekniken faktiskt fungerar.

/ Chrille

Den här artikeln finns även på engelska: Stop Building Org Charts for Your AI Agents