Mange tenker først at AI-kolleger bør fungere som et team, med én agent per rolle. Én for engineering, én for markedsføring, én som bare skriver blogginnlegg.
Vi bygde det slik også. I Okou kunne du opprette mange agenter i et workspace, hver med eget navn, egen avatar, egne Instruksjoner og Workflows. I august publiserte vi til og med et innlegg om hvordan flere agenter fordeler arbeid og gir det videre til hverandre. Vårt eget workspace hadde mange av dem. Lucas skrev blogginnleggene våre, Lisa tok seg av regnskapet, Iris håndterte investor relations, og jeg hadde en som het Emily, som sorterte e-posten min.
Men brukernes intuisjon er bare et referansepunkt. Før Notion mente folk at et dokumentverktøy trengte topptekst og bunntekst.
Multi-agent er heller ikke en grunnleggende evne. Grunnleggende evner er de som alle AI-produkter før eller siden trenger: chat, å lage presentasjoner og nettsider, å betjene en datamaskin. Flere agenter står ikke på den listen.
Ta Lucas, vår tidligere bloggagent. Omtrent en tredjedel av Instruksjonene dens er den samme generiske malen som standard-Okou bruker. Resten er tre konkrete prosedyrer: hvordan man publiserer et blogginnlegg i Strapi, hvordan man skriver use case-sider til nettstedet vårt, og hvordan man lager den daglige rapporten om registreringskonvertering. Alle 13 Workflows som er knyttet til Lucas, er offentlige i workspacet. Ingen av dem tilhører Lucas alene.
Forskjellen mellom Lucas og standard-Okou koker altså ned til et navn, en avatar og tre prosedyrer som burde ha vært Workflows. Disse prosedyrene er låst inne i Lucas. Ber du standard-Okou om å publisere et blogginnlegg, kjenner den ingen av disse reglene.
Etter hvert som antallet agenter vokste, vokste også antallet kombinasjoner. Mange agenter, mange Workflows og mange samtaler påvirker hverandre, og hver kombinasjon er logikk vi må vedlikeholde og brukerne må lære. Vi støtte på spørsmål vi ikke kunne svare godt på fra brukerens ståsted:
- Hvorfor kan ikke to agenter dele samme Workflow?
- Hvorfor kan jeg bare snakke med Okou i Slack og ikke med min egen private agent? Hvis Lucas er en person, burde jeg kunne nå den hvor som helst.
- Hvorfor deler alle agenter samme minne? Hvis hver agent er en person, burde hver ha sitt eget minne.
Alle disse kan løses, men hver av dem krever reelt utviklingsarbeid. Lar man dem ligge, blir multi-agent en halvferdig opplevelse. Vi slet også med å finne et problem som bare flere agenter kunne løse. Klagen vi hørte oftere, var at det var for mange agenter å holde styr på.
Derfor bestemte vi at hver person får én Okou. Modellen er enklere:
- Hver person har én standard-Okou.
- Din Okou tilhører deg og er privat.
- Din Okou og en kollegas Okou er ikke samme agent.
- Din Okou kan bruke enhver Workflow som noen i organisasjonen din har gjort Public.
Det som før hang på en agent, ligger nå der det passer bedre:
- Instruksjoner tilhører deg. Du skriver ett sett, og Okou følger det på nettet, i Slack og i automatiseringer.
- Workflows tilhører workspacet. Alle kan bruke en Public Workflow som en kollega publiserer, og du kan kopiere en og gjøre den til din egen.
- Tilkoblede kontoer tilhører deg, så du trenger ikke lenger velge hvilken agent som får tilgang.
- Samtaler grupperes i Prosjekter, etter kunde, prosjekt eller tema.
I denne modellen er en agent lite mer enn et sett Instruksjoner. De tre prosedyrene i Lucas bør bli Workflows som alle kan bruke.
Multi-agent er egentlig en ledelsespraksis i en organisasjon, en måte å styre hva AI kan gjøre på. Hver organisasjon har sine egne ledelsesmetoder, og ingen enkelt oppskrift passer for alle. En enkelt agent ligner mer på et verktøy, og verktøy er lettere å forstå og ta i bruk. Det brukerne trenger mest, er å få oppgaven gjort. Deretter kommer et verktøy for å gjøre den. Det de trenger minst, er en metode for å gjøre den.
Anthropics Applied AI-team så noe lignende i et nylig innlegg om agentutrullinger i virksomheter. I sammenligningene sine på tvers av flere utrullinger gjorde en enkelt agent med Skills det ofte bedre på kvalitet enn et oppsett delt inn i spesialiserte subagenter, og ofte med lavere kostnad og latens per oppgave. De skriver også: «Altfor ofte ser vi at virksomheter gir hvert team eller hver problemtype sin egen subagent, slik at agentarkitekturen blir en kopi av organisasjonskartet.» Innlegget deres handler om agentarkitektur heller enn produktdesign, men resonnementet lar seg overføre.
Når vi ser på dagens AI-produkter, ser vi fire modeller:
- Mange agenter, mange samtaler. Det var Okou.
- Én agent, mange samtaler. Slik fungerer ChatGPT, Codex og Claude Cowork.
- Én agent, én samtale. Slik fungerer Instinct.
- Mange agenter, hver med én enkelt samtale. Slik fungerer Grok bot.
Vi hadde den mest komplekse kombinasjonen, og den løste ikke flere problemer.
Vi vet at dette er en gjennomgripende endring. To ting holdt oss tilbake fra å gjøre den tidligere: at vi ber deg lære en ny måte å jobbe på, med én Okou pluss Workflows, og at det manglet en tydelig vei for det du allerede hadde bygget. Her er den veien:
- Samtalene dine er der fortsatt. Du finner dem via Prosjekter, søk og de opprinnelige lenkene.
- Hvis du brukte ulike agenter til å sortere samtaler, bruk Prosjekter i stedet. Å holde samtaler gruppert etter kategori var hovedgrunnen til at mange opprettet ekstra agenter. Claude og ChatGPT løser det samme behovet med Prosjekter.
- Hvis du skrev ulike Instruksjoner for ulike agenter, legg det de har til felles i dine personlige Instruksjoner, og gjør de spesifikke prosedyrene om til Workflows.
Jo før vi slutter å bygge abstraksjoner oppå flere agenter, jo bedre. Når du åpner Okou, trenger du ikke lenger å bestemme hvilken agent du skal spørre. Si til Okou hva du trenger gjort, så tar Okou seg av resten.
