Quand on pense à des collègues IA, la première intuition de beaucoup de gens est qu'ils devraient fonctionner comme une équipe, avec un agent par rôle. Un pour l'ingénierie, un pour le marketing, un qui ne fait qu'écrire des articles de blog.
Nous l'avions construit ainsi, nous aussi. Okou vous permettait de créer de nombreux agents dans un workspace, chacun avec son propre nom, son avatar, ses Instructions et ses Workflows. En août, nous avons même publié un article sur la manière dont plusieurs agents se répartissent le travail et se le transmettent. Notre propre workspace en comptait beaucoup. Lucas écrivait nos articles de blog, Lisa tenait la comptabilité, Iris s'occupait des relations investisseurs, et j'en avais un, Emily, qui triait mes e-mails.
Mais l'intuition des utilisateurs n'est qu'un point de repère. Avant Notion, on pensait intuitivement qu'un outil de documents devait avoir des en-têtes et des pieds de page.
Le multi-agent n'est pas non plus une capacité fondamentale. Les capacités fondamentales sont celles dont tout produit d'IA finira par avoir besoin : discuter, créer des présentations et des sites web, utiliser un ordinateur. Le multi-agent n'en fait pas partie.
Prenons Lucas, notre ancien agent dédié au blog. Environ un tiers de ses Instructions reprend le même modèle générique que celui de l'Okou par défaut. Le reste se compose de trois procédures précises : comment publier un article de blog dans Strapi, comment rédiger les pages de cas d'usage de notre site, et comment produire le rapport quotidien de conversion des inscriptions. Les 13 Workflows rattachés à Lucas sont tous publics dans le workspace. Aucun n'appartient à Lucas seul.
La différence entre Lucas et l'Okou par défaut se résume donc à un nom, un avatar et trois procédures qui auraient dû être des Workflows. Ces procédures sont enfermées dans Lucas. Demandez à l'Okou par défaut de publier un article de blog, et aucune de ces règles ne sera à sa disposition.
À mesure que le nombre d'agents augmentait, les combinaisons se multipliaient aussi. De nombreux agents, de nombreux Workflows et de nombreuses conversations interagissent, et chaque combinaison est une logique que nous devons maintenir et que les utilisateurs doivent apprendre. Nous nous sommes heurtés à des questions auxquelles nous ne savions pas bien répondre du point de vue de l'utilisateur :
- Pourquoi deux agents ne peuvent-ils pas partager le même Workflow ?
- Pourquoi est-ce que je ne peux parler à Okou que dans Slack, et pas à mon propre agent privé ? Si Lucas est une personne, je devrais pouvoir le joindre partout.
- Pourquoi la mémoire est-elle partagée entre tous les agents ? Si chaque agent est une personne, chacun devrait avoir sa propre mémoire.
Chacune de ces questions peut être résolue, mais chacune demande un vrai travail d'ingénierie. Si on les laisse en suspens, le multi-agent reste une expérience inachevée. Nous avons aussi eu du mal à trouver un problème que seuls plusieurs agents pouvaient résoudre. La plainte que nous entendions le plus souvent, c'était qu'il y avait trop d'agents à gérer.
Nous avons donc décidé que chaque personne aurait un seul Okou. Le modèle est plus simple :
- Chaque personne a un Okou par défaut.
- Votre Okou vous appartient et il est privé.
- Votre Okou et celui d'un collègue ne sont pas le même agent.
- Votre Okou peut utiliser n'importe quel Workflow qu'une personne de votre organisation a rendu Public.
Ce qui était auparavant rattaché à un agent se trouve désormais là où c'est plus logique :
- Les Instructions vous appartiennent. Vous en rédigez un seul ensemble, et Okou les suit sur le web, dans Slack et dans les automatisations.
- Les Workflows appartiennent au workspace. Tout le monde peut utiliser un Workflow Public publié par un collègue, et vous pouvez le copier pour vous l'approprier.
- Les comptes connectés vous appartiennent, vous n'avez donc plus à choisir quel agent y a accès.
- Les conversations sont regroupées dans des Projets, par client, par projet ou par sujet.
Dans ce modèle, un agent n'est guère plus qu'un ensemble d'Instructions. Les trois procédures enfermées dans Lucas devraient devenir des Workflows que tout le monde peut utiliser.
Le multi-agent est en réalité une pratique de management au sein d'une organisation, une façon d'encadrer ce que l'IA peut faire. Chaque organisation a ses propres méthodes de management, et aucune ne convient à tout le monde. Un agent unique se rapproche davantage d'un outil, et les outils sont plus faciles à comprendre et à adopter. Ce dont les utilisateurs ont le plus besoin, c'est que la tâche soit faite. Ensuite, d'un outil pour la faire. Ce dont ils ont le moins besoin, c'est d'une méthode pour la faire.
L'équipe Applied AI d'Anthropic a fait un constat similaire dans un article récent sur les déploiements d'agents en entreprise. Dans leurs comparaisons de plusieurs déploiements, un agent unique doté de Skills surpassait fréquemment en qualité une architecture découpée en sous-agents spécialisés, et souvent pour un coût et une latence par tâche plus faibles. Ils écrivent aussi : « trop souvent, nous voyons des entreprises attribuer à chaque équipe ou à chaque type de problème son propre sous-agent, si bien que l'architecture des agents devient une copie de leur organigramme. » Leur article porte sur l'architecture des agents plutôt que sur la conception produit, mais le raisonnement s'applique tout autant.
En observant les produits d'IA actuels, nous distinguons quatre modèles :
- Plusieurs agents, plusieurs conversations. C'était Okou.
- Un agent, plusieurs conversations. C'est le cas de ChatGPT, Codex et Claude Cowork.
- Un agent, une conversation. C'est le cas de Instinct.
- Plusieurs agents, chacun avec une seule conversation. C'est le cas de Grok bot.
Nous avions la combinaison la plus complexe, et elle ne résolvait pas davantage de problèmes.
Nous savons qu'il s'agit d'un changement qui rompt avec l'existant. Deux choses nous ont empêchés de le faire plus tôt : vous demander d'apprendre une nouvelle façon de travailler, avec un seul Okou et des Workflows, et l'absence de chemin clair pour ce que vous aviez déjà construit. Voici ce chemin :
- Vos conversations sont toujours là. Vous les retrouvez via les Projets, la recherche et leurs liens d'origine.
- Si vous utilisiez différents agents pour classer vos conversations, utilisez plutôt les Projets. Garder les conversations regroupées par catégorie était la principale raison pour laquelle beaucoup de gens créaient des agents supplémentaires. Claude et ChatGPT répondent au même besoin avec les Projets.
- Si vous aviez rédigé des Instructions différentes pour différents agents, gardez ce qu'elles ont en commun dans vos Instructions personnelles et transformez les procédures spécifiques en Workflows.
Plus tôt nous cesserons de construire des abstractions par-dessus plusieurs agents, mieux ce sera. Quand vous ouvrez Okou, vous n'avez plus à choisir à quel agent vous adresser. Dites à Okou ce que vous avez besoin de faire, et Okou s'occupe du reste.
