C'est l'un des projets les plus anciens de la vague multi-agents, né dans le laboratoire de recherche d'un grand éditeur de logiciels, et l'un des premiers à mettre sur scène une idée simple : un groupe d'agents qui se parlent jusqu'à ce que le travail soit fini. Son état actuel vient avec une condition à poser avant tout le reste — le projet est en mode maintenance, n'accepte plus de nouvelles fonctions et passe aux mains de la communauté. Cette analyse se coupe donc en deux : ce qu'il est et comment il s'utilise, puis s'il reste le bon choix.

Quatre pièces, séparées par la profondeur

La documentation découpe le projet en quatre parties, chacune avec son entrée. L'interface est une page web où un prototype d'agent se construit sans code : un paquet, une commande, un port et un répertoire de travail. Elle repose sur la couche conversationnelle, sert de premier arrêt aux nouveaux venus, et est signalée comme bonne pour tester une idée plutôt que pour la production. La couche conversationnelle est celle contre laquelle on code : des applications à un ou plusieurs agents organisées autour du dialogue, Python 3.10 ou plus récent requis, avec des exemples d'une douzaine de lignes — créer un agent assistant, lui passer un client de modèle, lancer une tâche, imprimer le retour. Le cœur est plus bas et constitue un framework de programmation événementielle, destiné aux flux déterministes dans les processus métier, à la recherche sur la collaboration multi-agents et aux agents distribués par-delà les langages. Les extensions font entrer le monde extérieur : des composants pour serveurs du protocole de contexte de modèle, des agents pour interfaces d'assistant, un exécuteur qui fait tourner dans un conteneur le code produit par le modèle, et une exécution pour agents distribués.

De la conversation à la discussion de groupe

La colonne vertébrale de la documentation suit modèle, message, agent, équipe, intervention humaine, conditions d'arrêt, gestion d'état — et cet ordre est en soi un parti pris. Il suppose un travail collaboratif qui dure, ce qui explique que l'arrêt et l'état aient leurs propres chapitres plutôt qu'une annexe. Un cran au-dessus, les motifs d'orchestration offrent de vrais choix. Une discussion de groupe à sélecteur confie à un sélecteur central et personnalisable la décision de qui parle ensuite, avec coordination par contexte partagé. Un essaim fait descendre cette décision, via des sélecteurs d'outils locaux, pour que les agents se passent directement le relais. Un flux en graphe organise l'ensemble en graphe orienté, ce qui convient aux cas aux frontières nettes. Autour se tient l'équipement d'ingénierie — mémoire et enrichissement par recherche, journalisation, sérialisation des composants, traçage et observabilité — plus une équipe d'exemple officielle assemblée à partir de la couche conversationnelle et des extensions, pensée pour des tâches combinées comme naviguer, exécuter du code et traiter des fichiers. Pour aller vite, on commence dans l'interface et on esquisse ; pour le détail, on descend au cœur et on écrit soi-même la boucle d'événements.

Le mode maintenance pèse plus que la liste de fonctions

L'avis en haut du dépôt est net : le projet est en mode maintenance, ne reçoit plus de fonctions ni d'améliorations et est animé par la communauté ; les nouveaux venus doivent partir du successeur désigné, et les utilisateurs existants disposent d'un guide de migration. Le même avis précise que ce successeur est le remplacement de niveau entreprise, déjà disponible en version prête pour la production, avec des interfaces stables et un engagement de support à long terme, couvrant de l'assistant unique au groupe d'agents, avec orchestration multi-agents d'entreprise, plusieurs fournisseurs de modèles et interopérabilité entre exécutions via les deux protocoles d'agents émergents. Le guide de contribution s'est resserré en conséquence : seules les corrections de défauts, les correctifs de sécurité et les améliorations de documentation sont acceptés, le travail de fonctionnalité étant renvoyé au successeur.

La structure en trois couches reste claire. Le cœur assure la transmission de messages, les agents événementiels et les exécutions locale et distribuée, en Python comme en C#. La couche conversationnelle offre au-dessus une interface plus simple mais affirmée, couvrant les formes familières du dialogue à deux et de la discussion de groupe. Les extensions fournissent les clients de modèles et l'exécution de code. L'outillage compagnon est l'interface sans code et une suite de référence. La licence suit deux voies : le code en MIT, la documentation sous licence Creative Commons avec attribution. Les chiffres du dépôt donnent environ 61k étoiles, 9,2k forks, 98 publications et 556 contributeurs, utilisé dans 4,3K projets, majoritairement en Python, avec C# et TypeScript à côté.

À qui cela sert encore

Trois groupes restent bien servis. Les équipes avec des projets existants, où le code tourne et les modèles sont réglés : en mode maintenance, les correctifs de défauts et de sécurité continuent, la migration se planifie donc à son propre rythme au lieu d'être imposée par une nouvelle version. Les développeurs qui étudient la structure de la collaboration multi-agents : les trois motifs font chacun un arbitrage clair et, avec la suite de référence à côté, forment un bon matériel de comparaison contrôlée, documentation et exemples restant en place. Et tous ceux qui veulent tester une idée vite, l'interface étant du glisser-déposer après installation, bien moins de travail que de bâtir une orchestration de zéro.

Deux situations devraient aller directement au successeur. Les nouveaux systèmes de production, surtout là où un engagement de support à long terme est exigé — le framework a dit clairement qu'il n'ajouterait plus rien, et une nouvelle architecture posée sur un cadre gelé ne pourra plus compter que sur la communauté. Et les équipes qui ont besoin d'orchestration d'entreprise, de bascule entre fournisseurs de modèles et d'interopérabilité entre exécutions, capacités que l'éditeur a explicitement placées dans le successeur. Autrement dit, ce qui reste ici est un actif existant utilisable et un bon matériel pédagogique, pas un point de départ tourné vers l'avenir.

Choisir un framework : la liste de fonctions n'est que le ticket d'entrée. La vraie ligne de partage est de savoir si l'on sera encore dans sa fenêtre de support dans trois ans.