Én agent per avdeling
Når en større virksomhet begynner å bygge AI-agenter, er det et mønster som går igjen. HR får sin agent. Økonomi får sin. Kundeservice får sin. Og på toppen kommer en agent som skal fordele oppgavene mellom dem.
Det ser ryddig ut. Det ligner på hvordan virksomheten allerede er organisert.
Ifølge en ny artikkel fra Anthropic er det ofte nettopp problemet.
Dette er femte innlegg i en serie. Vi har skrevet om loopen, om stoppbetingelsen, om nattvakten og om hva som skjer når produksjonen blir tolv ganger større. Dette innlegget handler om hvordan selve agenten bør være bygget.
Agenten blir en kopi av organisasjonskartet
Det finnes en gammel regel i systemutvikling, kalt Conways lov: systemer ender opp med å speile organisasjonen som bygger dem.
Anthropic ser det samme med AI-agenter. Virksomheter bygger ofte underagenter langs teamgrensene, slik at arkitekturen blir en kopi av organisasjonskartet. Det er lett å forstå hvorfor. Det er slik ansvaret allerede er fordelt, og da er det naturlig å bygge på samme måte.
Problemet er at kunden, den ansatte eller saken ikke bryr seg om organisasjonskartet. En henvendelse kan gjelde både en faktura, en avtale og en tilgang. Da må den gjennom tre agenter som hver bare ser sin del.
Hva det koster
Artikkelen beskriver kostnadene ganske konkret.
Detaljer forsvinner underveis. Hver underagent sender tilbake et sammendrag til den som spurte. Det er som hviskeleken: for hver overlevering blir bildet litt mindre presist.
Instruksene sprikker. Når mange spesialister skrives av forskjellige team, får man regler som motsier hverandre og ingen felles stemme. Ett selskap med et dusin spesialiserte underagenter slet med å holde dem konsistente.
Hvert team måler bare sin egen del. Hver avdeling optimaliserer sin agent, og ledelsen får et samlet bilde som ser bedre ut enn helheten faktisk fungerer.
Det tar tid og koster penger. Hver underagent er en egen loop med egne kall til modellen. Én kunde fikk det omtrent dobbelt så raskt ved å gå over til én samlet loop.
Hva de anbefaler i stedet
Alternativet er én agent som henter inn det den trenger, når den trenger det.
Artikkelen skiller mellom to ting. Ferdigheter beskriver hvordan en jobb gjøres, altså fagkunnskapen og rutinene. Verktøy gjør handlinger, henter levende data og håndhever harde grenser, som validering og godkjenning. Agenten laster bare inn det som er relevant for oppgaven den står i.
Verktøyene bør dessuten grupperes etter hva brukeren prøver å få gjort, ikke ett per system. Artikkelen viser til erfaringer med at agenten blir dårligere til å velge riktig verktøy når den har mer enn rundt 30 til 50.
Resultatet de beskriver, er at én slik agent ofte slo både én stor instruks og et oppsett med mange underagenter, på kvalitet, tid og pris.
Når flere agenter faktisk er riktig
Dette betyr ikke at underagenter er feil. Artikkelen sier at de fortsatt hører hjemme, blant annet i disse tilfellene:
Når én loop blir målbart dårligere fordi den har for mye i hodet på en gang.
Når arbeid kan gjøres parallelt og hver del trenger blanke ark, som uavhengige undersøkelser.
Når noe skal kontrolleres av en som ikke gjorde jobben, det artikkelen kaller verifisering som en svart boks.
Det siste er verdt å stoppe ved, fordi det er akkurat slik vi beskrev nattvaktplanene. Der gjør én agent jobben, og en annen kontrollerer den uten å ha sett resonnementet. Det er ikke en avdeling per agent. Det er to roller som må holdes adskilt. Artikkelen og nattvakten sier altså det samme: bruk flere agenter når rollene må være uavhengige, ikke fordi organisasjonen har flere avdelinger.
Regler hører hjemme i verktøyet
Et poeng i artikkelen fortjener å løftes fram. Harde grenser, som godkjenning og validering, skal ligge i verktøy og ikke i teksten agenten får som instruks.
Det er det samme vi gjorde i CRM-et vi bygget i SharePoint. Kravet i markedsføringsloven står ikke i en rutinebeskrivelse. Det er en sperre i tavla. En instruks kan agenten misforstå eller glemme. En sperre i verktøyet kan den ikke gå rundt.
Ansvaret kan ligge per avdeling. Agenten bør ikke det.
Her er det lett å blande sammen to ting.
Vi har tidligere anbefalt en AI-komité med én ansvarlig per avdeling. Det står vi fortsatt for. Komiteen handler om ansvar: hvem som vet hvordan avdelingen jobber, hvor grensene skal gå, og hvem som skal si nei.
Hvordan agenten er bygget, er noe annet. Der anbefaler Anthropic at et lite, sentralt team eier hele agenten fra start til slutt.
Det er ikke en motsetning. Avdelingene eier kunnskapen og reglene. Det sentrale teamet eier loopen som bruker dem. Fagkunnskapen fra hver avdeling blir ferdigheter og verktøy i én agent, i stedet for at hver avdeling får sin egen agent som ingen har oversikt over.
Slik går dere fram
Artikkelen gir en enkel framgangsmåte for dem som allerede har mange underagenter:
Lag en liten test først. Rundt ti eksempler der dere vet hva riktig svar er, kjørt fra start til slutt.
Slå sammen én underagent om gangen, og begynn med den som brukes mest.
Behold den bare hvis resultatet blir dårligere uten den. Ellers kan den slås sammen.
Kjør hver test mer enn én gang. I ett av eksemplene deres dukket en forverring bare opp i én av to kjøringer.
Og vi vil legge til ett spørsmål før dere i det hele tatt deler opp en agent: hva er det brukeren faktisk prøver å få gjort? Start der, ikke med hvilken avdeling som eier oppgaven.
Et forbehold
Artikkelen er skrevet av Anthropic, og den avsluttes med en henvisning til et verktøy de selv tilbyr for å gjøre om agenter på denne måten. Tallene den bruker, er også få: «én kunde», «ett selskap». Les dem som erfaringer, ikke som målte sannheter.
Men hovedpoenget gjelder uansett leverandør. Strukturen kommer først, og strukturen som betyr noe, er oppgavens. Ikke organisasjonskartets.