Veel mensen denken bij AI-collega's eerst aan een team, met één agent per rol. Eén voor engineering, één voor marketing, één die alleen blogposts schrijft.
Zo hebben wij het ook gebouwd. In Okou kon je in een workspace veel agents aanmaken, elk met een eigen naam, avatar, Instructies en Workflows. In augustus publiceerden we zelfs een post over hoe meerdere agents werk verdelen en aan elkaar overdragen. In onze eigen workspace zaten er genoeg. Lucas schreef onze blogposts, Lisa deed de boekhouding, Iris verzorgde investor relations en ik had er een die Emily heette en mijn e-mail sorteerde.
Maar de intuïtie van gebruikers is alleen een referentiepunt. Vóór Notion dachten mensen dat een documenttool kop- en voetteksten nodig had.
Multi-agent is ook geen fundamentele capaciteit. Fundamentele capaciteiten zijn de dingen die elk AI-product uiteindelijk nodig heeft: chatten, slides en websites maken, een computer bedienen. Meerdere agents staan niet op dat lijstje.
Neem Lucas, onze voormalige blogagent. Ongeveer een derde van zijn Instructies is hetzelfde generieke sjabloon dat de standaard-Okou gebruikt. De rest bestaat uit drie specifieke procedures: hoe je een blogpost publiceert in Strapi, hoe je use-casepagina's voor onze website schrijft en hoe je het dagelijkse rapport over signup-conversie maakt. Alle 13 Workflows die aan Lucas gekoppeld zijn, zijn openbaar in de workspace. Geen enkele daarvan is alleen van Lucas.
Het verschil tussen Lucas en de standaard-Okou komt dus neer op een naam, een avatar en drie procedures die eigenlijk Workflows hadden moeten zijn. Die procedures zitten opgesloten in Lucas. Vraag de standaard-Okou om een blogpost te publiceren, en geen van die regels is er.
Naarmate het aantal agents groeide, groeide ook het aantal combinaties. Veel agents, veel Workflows en veel gesprekken beïnvloeden elkaar, en elke combinatie is logica die wij moeten onderhouden en die gebruikers moeten leren. We liepen tegen vragen aan die we vanuit het perspectief van de gebruiker niet goed konden beantwoorden:
- Waarom kunnen twee agents niet dezelfde Workflow delen?
- Waarom kan ik in Slack alleen met Okou praten en niet met mijn eigen privéagent? Als Lucas een persoon is, zou ik hem overal moeten kunnen bereiken.
- Waarom delen alle agents hetzelfde geheugen? Als elke agent een persoon is, zou elke agent een eigen geheugen moeten hebben.
Elk van deze punten is op te lossen, maar elk kost echt engineeringwerk. Laat je ze liggen, dan blijft multi-agent een half afgemaakte ervaring. We vonden ook maar moeilijk een probleem dat alleen meerdere agents konden oplossen. De klacht die we vaker hoorden, was dat er te veel agents waren om te beheren.
Daarom hebben we besloten dat iedereen één Okou krijgt. Het model is eenvoudiger:
- Iedereen heeft één standaard-Okou.
- Jouw Okou is van jou en is privé.
- Jouw Okou en de Okou van een collega zijn niet dezelfde agent.
- Jouw Okou kan elke Workflow gebruiken die iemand in je organisatie op Public heeft gezet.
Wat vroeger aan een agent hing, staat nu waar het beter past:
- Instructies zijn van jou. Je schrijft één set, en Okou volgt die op het web, in Slack en in automatiseringen.
- Workflows zijn van de workspace. Iedereen kan een Public Workflow gebruiken die een collega publiceert, en je kunt er een kopiëren en er je eigen versie van maken.
- Gekoppelde accounts zijn van jou, dus je hoeft niet meer te kiezen welke agent toegang krijgt.
- Gesprekken worden gegroepeerd in Projecten, per klant, project of onderwerp.
In dit model is een agent weinig meer dan een set Instructies. De drie procedures in Lucas zouden Workflows moeten worden die iedereen kan gebruiken.
Multi-agent is eigenlijk een managementpraktijk binnen een organisatie, een manier om te sturen wat AI kan doen. Elke organisatie heeft haar eigen managementmethoden, en geen enkele aanpak past bij iedereen. Eén agent is meer een tool, en tools zijn makkelijker te begrijpen en in te voeren. Wat gebruikers het meest nodig hebben, is dat de taak gedaan wordt. Daarna komt een tool om het te doen. Het minst hebben ze een methode nodig om het te doen.
Het Applied AI-team van Anthropic zag iets vergelijkbaars in een recente post over agentimplementaties bij grote organisaties. In hun vergelijkingen tussen meerdere implementaties presteerde één agent met Skills qua kwaliteit vaak beter dan een opzet met gespecialiseerde subagents, en dat vaak tegen lagere kosten en latentie per taak. Ze schrijven ook: “Te vaak zien we dat bedrijven elk team of elk type probleem een eigen subagent geven, waardoor de agentarchitectuur een kopie van hun organogram wordt.” Hun post gaat over agentarchitectuur en niet over productontwerp, maar de redenering gaat hier net zo goed op.
Als we naar de huidige AI-producten kijken, zien we vier modellen:
- Veel agents, veel gesprekken. Dat was Okou.
- Eén agent, veel gesprekken. Zo werken ChatGPT, Codex en Claude Cowork.
- Eén agent, één gesprek. Zo werkt Instinct.
- Veel agents, elk met één enkel gesprek. Zo werkt Grok bot.
Wij hadden de meest complexe combinatie, en die loste niet meer problemen op.
We weten dat dit een ingrijpende wijziging is. Twee dingen hielden ons tegen om haar eerder door te voeren: we vragen je een nieuwe manier van werken te leren, met één Okou plus Workflows, en er was geen duidelijk pad voor wat je al had gebouwd. Dit is dat pad:
- Je gesprekken zijn er nog. Je vindt ze via Projecten, zoeken en hun oorspronkelijke links.
- Als je verschillende agents gebruikte om gesprekken te ordenen, gebruik dan Projecten. Gesprekken per categorie gegroepeerd houden was voor veel mensen de belangrijkste reden om extra agents aan te maken. Claude en ChatGPT lossen dezelfde behoefte op met Projecten.
- Als je verschillende Instructies voor verschillende agents schreef, zet dan wat ze gemeen hebben in je persoonlijke Instructies en maak van de specifieke procedures Workflows.
Hoe eerder we stoppen met abstracties bouwen bovenop meerdere agents, hoe beter. Als je Okou opent, hoef je niet meer te beslissen welke agent je iets vraagt. Vertel Okou wat er gedaan moet worden, en Okou regelt de rest.
