AgentConnect : une plateforme open source multi-agents qui réunit Claude Code, Codex et votre équipe dans le même fil

Le problème visé

AgentConnect est une plateforme open source publiée sous licence Apache-2.0. Son but est de permettre à des personnes et à plusieurs agents d'IA de travailler ensemble dans les conversations et les flux de travail que l'équipe utilise déjà. Le README s'ouvre sur la formule « l'alternative open source et multi-agents à Claude Tag », avec le slogan « @ any agent ». L'idée : là où le travail se fait, les agents travaillent aux côtés de l'équipe et entre eux, et apprennent en chemin.

Le problème de fond est facile à reconnaître. La plupart des agents de code restent des outils personnels, enfermés dans le terminal d'une seule personne. Les collègues ne voient pas ce que fait l'agent. Ils ne peuvent pas reprendre sa session ni relire son résultat. Le contexte qu'il accumule reste sur un seul portable. Chaque équipe réécrit donc la même colle : canaux de messages, tâches cron, gestion des identifiants, assemblage du contexte. AgentConnect propose de faire de cette colle une plateforme.

Architecture : trois composants, deux plans

Le README décrit trois composants. Le premier est le Daemon. Il exécute les agents qui lui sont attribués au-dessus d'une connexion ACP (Agent Client Protocol) qu'il possède. Il gère les espaces de travail et l'état des sessions, maintient des connexions directes avec les plateformes de discussion, exécute les planifications et envoie lui-même le trafic vers les fournisseurs de modèles. Le deuxième est le Relay, qui est optionnel. Il accepte les entrées par rappel (callback) et le chat web, relaie l'accès géré de façon centrale à MCP et à OpenConnector, et transmet les messages directement au daemon concerné. Il ne stocke rien de façon durable. Le troisième est le Control Plane avec son interface Web. Il gère l'authentification, la configuration, le placement, les permissions, les métadonnées et l'observabilité. Il conserve les connaissances d'organisation et les révisions de compétences explicitement approuvées. Dans les autres cas, il relaie à la demande des lectures bornées vers le daemon.

Le choix central est la séparation entre plan de données et plan de contrôle. Les messages en direct et les flux de mise à jour ACP restent sur le chemin daemon et relay. Hors connaissances approuvées et paquets de compétences bornés, le Control Plane ne stocke que des métadonnées de coordination : ni corps de messages, ni pièces jointes, ni propositions Dream en attente, ni flux de sessions ACP. Le README décrit aussi le comportement en cas de panne : si le Control Plane est brièvement indisponible, les sessions établies et les planifications locales du daemon continuent. Seules les nouvelles attributions et les changements de configuration attendent la reconnexion. C'est une réponse pragmatique à la première question d'une équipe plateforme : que casse-t-on quand le service de contrôle tombe ?

Première idée technique : la neutralité des runtimes grâce à ACP

AgentConnect ne dépend d'aucun runtime d'agent. Claude Code, Codex, Grok Build, DeepSeek, Pi et tout autre runtime compatible ACP fonctionnent côte à côte. Chaque agent a son runtime, son modèle, son espace de travail, ses outils et sa machine, configurés séparément. Selon le README, remplacer l'un d'eux ne force pas à reconstruire le flux de travail autour.

ACP joue le rôle d'une prise commune. Comme le daemon parle à tous les agents avec le même protocole, les couches supérieures (routage, permissions, mémoire) n'ont pas besoin d'une version sur mesure pour chaque outil. Pour une équipe qui mélange déjà plusieurs agents de code, c'est plus simple à maintenir que de brancher un bot de discussion distinct pour chacun.

Deuxième idée technique : les Decisions et le routage Jev

Le second mécanisme notable est celui des Decisions réutilisables, propulsées par Jev (TypeSafe). Une Decision répond à trois questions : quand un agent doit-il répondre, quel agent spécialiste doit recevoir une nouvelle conversation, et quels runtime et modèle utiliser pour une nouvelle session.

Le README donne deux scénarios. Pour le tri du support, Jev oriente une nouvelle demande vers les bons spécialistes, et personnes et agents enquêtent dans un même fil, la correction et sa vérification restant visibles du début à la fin. Pour la revue de code personnalisée, Jev choisit les relecteurs de chaque nouvelle pull request GitHub ainsi que le runtime et le modèle de chaque session de revue. Des relecteurs généraux, d'architecture ou de sécurité peuvent avoir leurs propres instructions, accès aux dépôts, outils et politiques de bac à sable.

Cela revient à placer une couche de politique configurable entre « qui fait le travail » et « avec quoi », au lieu d'enfouir ces règles dans un script de bot.

Mémoire, connaissances et frontières

Chaque agent a sa propre mémoire et ses compétences. Les équipes peuvent publier des connaissances (Knowledge) relues, que tous les agents retrouvent à la demande, et le guide de déploiement mentionne une configuration optionnelle de Mem0.

Côté contrôle, le README liste des frontières explicites : qui voit chaque agent et chaque session, quels dépôts et outils l'agent peut utiliser, et quels autres agents il peut appeler. Le travail peut démarrer depuis un message, une issue, une pull request, un webhook ou une planification.

Déploiement

Deux voies d'auto-hébergement existent. La plus rapide passe par Docker : cloner le dépôt puis lancer docker compose up -d --pull always démarre la console Web, le Control Plane, le Relay et PostgreSQL. On ouvre localhost:3000, on ajoute un daemon depuis la console, on exécute la commande générée et on crée son premier agent. La pile par défaut n'écoute que sur 127.0.0.1 et utilise un mode local sans authentification, prévu pour l'évaluation.

Pour un cluster, un chart Helm officiel est publié à chaque version avec le même numéro, à l'adresse oci://ghcr.io/agentconnect-md/charts/agentconnect. Un Setup Server distinct tourne en boucle locale sur le port 8091 et configure l'authentification du navigateur via Logto, les applications GitHub, Slack, Google et Lark ou Feishu, ainsi que le comportement des agents prédéfinis. Le dépôt fournit aussi une compétence d'installation qui permet à Claude Code ou Codex de guider la mise en place sous forme de tutoriel interactif. Le développement exige Node 24.12.0 ou plus et pnpm 11.

Impact sur l'écosystème

Pour les développeurs, l'intérêt principal est de sortir les agents du terminal personnel pour les placer dans un espace d'équipe partagé. Dans un même fil Slack, une personne peut reprendre, relire ou corriger le travail d'un agent.

Pour les entreprises, la licence Apache-2.0 et l'auto-hébergement permettent de garder l'exécution des agents et les espaces de travail dans un environnement qu'elles exploitent, ce qui compte pour les équipes soumises à la conformité. La cohabitation de plusieurs runtimes réduit aussi la dépendance à un seul fournisseur de modèles.

Limites et questions ouvertes

Il faut le dire clairement : le README ne publie aucun benchmark, aucune latence, aucun coût. Cet article n'avance donc aucune affirmation de performance. Quelques points méritent attention lors d'une évaluation.

D'abord, la pile par défaut est un mode d'évaluation sans authentification ; la production exige une authentification réelle, des URL publiques et le respect des exigences de bac à sable Linux. Ensuite, des agents qui appellent d'autres agents peuvent multiplier les coûts et élargir l'impact d'une erreur, d'où le besoin de concevoir soigneusement les permissions et le graphe d'appels. Troisièmement, les Decisions reposent sur Jev, un composant externe dont la maturité et la remplaçabilité sont à examiner séparément. Enfin, le README ne détaille pas Claude Tag lui-même : la comparaison est à vérifier dans la documentation officielle.

Perspectives

Si le travail multi-agents devient courant, le goulot d'étranglement passera de la capacité d'un agent isolé aux questions d'organisation : routage, permissions, mémoire et observabilité. AgentConnect parie sur cette couche, en open source, auto-hébergeable et neutre vis-à-vis des runtimes.

Son avenir comme standard dépendra de la croissance de l'écosystème ACP et de l'émergence de bonnes pratiques de sécurité et de maîtrise des coûts. Pour l'instant, c'est une implémentation de référence crédible qu'une équipe peut essayer et juger sur ses propres mesures.