Varför vi föredrar få stora agenter framför många små

Det finns en strömning i AI-byggande just nu som lånat tankegods från mikroservicearkitektur. Bryt ner allt i små specialiserade agenter, låt dem prata med varandra via meddelandebussar, orchestrera allt med en konduktör. Det låter rent och modulärt. I praktiken är det oftast fel val.

Vi har byggt åt båda hållen och landat i en stark preferens för få stora agenter med bra verktygslåda framför många små specialister som måste koordineras. Skälen är konkreta.

Koordinationskostnaden är högre än man tror

När agent A ska be agent B att göra något måste A formulera en uppgift som B kan tolka. När B svarar måste A tolka svaret. Varje steg är en plats där missförstånd uppstår. När du har fem agenter som jobbar tillsammans har du tjugo gränssnitt där tolkningar kan gå snett.

Stora moderna modeller är duktiga på att hålla många saker i huvudet samtidigt. Det är ofta enklare att ge en agent tillgång till alla verktyg den behöver och låta den planera själv än att försöka koreografera en symfoni av specialister.

Debugging blir dramatiskt enklare

När något går fel i en monolitisk agent kan du läsa hela traceloggen och se vad som hände. När något går fel i ett system av fem agenter måste du först hitta vilken agent som börjat felet, sedan följa kedjan, sedan förstå vilket meddelande som blev fel, sedan analysera om det var sändarens eller mottagarens fel.

Vi har debuggat båda. Skillnaden i tidsåtgång är inte marginell. Den är ofta tiofaldig.

Kostnaden räknas bättre

Många små agenter innebär att samma kontext skickas runt flera gånger, ofta med viss överlappning. Du betalar tokens flera gånger för samma information. En stor agent som behåller kontexten genom hela arbetsflödet betalar en gång.

I våra mätningar landar mikroagentsarkitektur ofta på två till fyra gånger högre token-kostnad för samma slutresultat. Det är inte marginellt på årsbasis.

När många små agenter ändå är rätt

Det finns lägen där modulärt vinner. Om olika delar av flödet behöver olika säkerhetsnivåer. Om en del måste köras i en specifik geografi för dataregler. Om agenter byggs av olika team som inte kan koordinera ofta. Om det finns specialiserade modeller som vinner stort på en deluppgift, exempelvis en finjusterad modell för svenska medicinska termer kombinerat med en allmän modell för dialog.

Men i normala företagsapplikationer är det få av de villkoren som gäller. Då är monoliten oftast det enklare, billigare och mer pålitliga valet.

Konsekvensen för hur ni borde tänka

När någon erbjuder er en lösning baserad på multi-agent orchestration, fråga varför just det. Om svaret är att det är moderna arkitekturen, var skeptisk. Om svaret är konkreta krav som kräver separation, lyssna noga. Den första kategorin tjänar leverantören. Den andra tjänar er.