Många föreställer sig först att AI-kollegor ska fungera som ett team, med en agent per roll. En för engineering, en för marknadsföring, en som bara skriver blogginlägg.
Vi byggde det också så. I Okou kunde du skapa många agenter i en workspace, var och en med eget namn, egen avatar, egna Instruktioner och Workflows. I augusti publicerade vi till och med ett inlägg om hur flera agenter delar upp arbetet och lämnar över till varandra. Vår egen workspace hade gott om dem. Lucas skrev våra blogginlägg, Lisa skötte bokföringen, Iris hanterade investor relations och jag hade en som hette Emily som sorterade min e-post.
Men användarnas intuition är bara en referenspunkt. Före Notion trodde folk att ett dokumentverktyg behövde sidhuvuden och sidfötter.
Multi-agent är inte heller en grundläggande förmåga. Grundläggande förmågor är de som varje AI-produkt förr eller senare behöver: chatt, att skapa presentationer och webbplatser, att styra en dator. Flera agenter finns inte på den listan.
Ta Lucas, vår tidigare bloggagent. Ungefär en tredjedel av dess Instruktioner är samma generiska mall som standard-Okou använder. Resten är tre specifika rutiner: hur man publicerar ett blogginlägg i Strapi, hur man skriver use case-sidor för vår webbplats och hur man tar fram den dagliga rapporten om registreringskonvertering. Alla 13 Workflows som är kopplade till Lucas är offentliga i workspacen. Inget av dem tillhör bara Lucas.
Skillnaden mellan Lucas och standard-Okou handlar alltså om ett namn, en avatar och tre rutiner som borde ha varit Workflows. De rutinerna är inlåsta i Lucas. Be standard-Okou publicera ett blogginlägg, så känner den inte till någon av de reglerna.
I takt med att antalet agenter växte, växte också antalet kombinationer. Många agenter, många Workflows och många konversationer påverkar varandra, och varje kombination är logik som vi måste underhålla och som användarna måste lära sig. Vi stötte på frågor som vi inte kunde besvara bra ur användarens perspektiv:
- Varför kan inte två agenter dela samma Workflow?
- Varför kan jag bara prata med Okou i Slack och inte med min egen privata agent? Om Lucas är en person borde jag kunna nå den var som helst.
- Varför delar alla agenter samma minne? Om varje agent är en person borde var och en ha sitt eget minne.
Alla dessa går att lösa, men var och en kräver ett rejält utvecklingsarbete. Lämnas de olösta förblir multi-agent en halvfärdig upplevelse. Vi hade också svårt att hitta ett problem som bara flera agenter kunde lösa. Klagomålet vi hörde oftare var att det fanns för många agenter att hålla reda på.
Därför bestämde vi att varje person får en Okou. Modellen är enklare:
- Varje person har en standard-Okou.
- Din Okou tillhör dig och är privat.
- Din Okou och en kollegas Okou är inte samma agent.
- Din Okou kan använda alla Workflows som någon i din organisation har gjort Public.
Det som tidigare hängde på en agent finns nu där det passar bättre:
- Instruktioner tillhör dig. Du skriver en uppsättning, och Okou följer den på webben, i Slack och i automatiseringar.
- Workflows tillhör workspacen. Vem som helst kan använda ett Public Workflow som en kollega publicerar, och du kan kopiera ett och göra det till ditt eget.
- Anslutna konton tillhör dig, så du behöver inte längre välja vilken agent som får åtkomst.
- Konversationer grupperas i Projekt, efter kund, projekt eller ämne.
I den här modellen är en agent inte mycket mer än en uppsättning Instruktioner. De tre rutinerna i Lucas borde bli Workflows som vem som helst kan använda.
Multi-agent är egentligen en ledningspraxis inom en organisation, ett sätt att styra vad AI kan göra. Varje organisation har sina egna ledningsmetoder, och ingen enskild modell passar alla. En enda agent liknar mer ett verktyg, och verktyg är lättare att förstå och börja använda. Det användarna behöver mest är att uppgiften blir gjord. Därefter kommer ett verktyg för att göra den. Det de behöver minst är en metod för att göra den.
Anthropics Applied AI-team såg något liknande i ett nyligen publicerat inlägg om agentdriftsättningar i företag. I sina jämförelser mellan flera driftsättningar presterade en enda agent med Skills ofta bättre på kvalitet än en lösning uppdelad i specialiserade subagenter, och ofta till lägre kostnad och latens per uppgift. De skriver också: ”Alltför ofta ser vi företag ge varje team eller problemtyp en egen subagent, så att agentarkitekturen blir en kopia av organisationsschemat.” Deras inlägg handlar om agentarkitektur snarare än produktdesign, men resonemanget går att föra över.
När vi tittar på dagens AI-produkter ser vi fyra modeller:
- Många agenter, många konversationer. Det var Okou.
- En agent, många konversationer. Så fungerar ChatGPT, Codex och Claude Cowork.
- En agent, en konversation. Så fungerar Instinct.
- Många agenter, var och en med en enda konversation. Så fungerar Grok bot.
Vi hade den mest komplexa kombinationen, och den löste inte fler problem.
Vi vet att det här är en genomgripande förändring. Två saker hindrade oss från att göra den tidigare: att vi ber dig lära dig ett nytt arbetssätt, med en Okou plus Workflows, och att det saknades en tydlig väg för det du redan hade byggt. Här är den vägen:
- Dina konversationer finns kvar. Du hittar dem via Projekt, sökningen och deras ursprungliga länkar.
- Om du använde olika agenter för att sortera konversationer, använd Projekt i stället. Att hålla konversationer grupperade efter kategori var huvudskälet till att många skapade extra agenter. Claude och ChatGPT löser samma behov med Projekt.
- Om du skrev olika Instruktioner för olika agenter, lägg det som är gemensamt i dina personliga Instruktioner och gör om de specifika rutinerna till Workflows.
Ju tidigare vi slutar bygga abstraktioner ovanpå flera agenter, desto bättre. När du öppnar Okou behöver du inte längre bestämma vilken agent du ska fråga. Berätta för Okou vad som ska göras, så sköter Okou resten.
