Brigade : outils et mémoire synchronisés entre harnesses, un journal de travail unifié en fichiers locaux

À qui cela s'adresse

• Aux développeurs qui utilisent plusieurs agents de codage en même temps : lorsqu'on bascule entre plusieurs harnesses (par exemple en utilisant un agent de codage différent selon les moments), on veut que les outils et la mémoire restent synchronisés et que tout le travail partage un même journal, plutôt que chaque outil tienne le sien avec des états qui ne se parlent pas. La description officielle : exécuter des agents de codage n'importe où et conserver un seul enregistrement du travail.
• Il se présente sous forme de CLI : les agents réclament du travail prêt depuis un journal partagé, et la mémoire et les compétences sont servies aux harnesses via MCP. Convient aux utilisateurs prêts à gérer l'état du travail des agents en ligne de commande et à brancher des capacités à une chaîne d'outils d'agents existante via MCP.
• Le journal de travail est conservé dans des fichiers locaux, sans démon nécessaire — adapté à ceux qui veulent garder leurs données de travail sur leur propre machine et ne souhaitent pas faire tourner un service en arrière-plan supplémentaire. La collaboration multi-utilisateurs ou le déploiement à distance n'est pas mentionnée officiellement.
• Prérequis : la voie d'installation npm exige Node.js 22 ou plus récent ainsi que npm. Si l'environnement ne les remplit pas, la documentation officielle ne propose aucune autre méthode d'installation et ne dit pas s'il existe des différences entre systèmes d'exploitation.
• La documentation officielle ne dresse pas la liste des cas inadaptés et ne donne pas non plus la liste des harnesses pris en charge. Avant de brancher l'outil, vérifiez que votre client d'agent sait ajouter un serveur MCP en mode stdio — la documentation officielle ne le vérifie pas à votre place. Si votre chaîne d'outils ne peut ni exécuter de CLI ni se brancher à MCP, il n'existe pour l'instant aucun chemin d'intégration confirmable.

Première tentative en 3 minutes

• Prérequis : préparez Node.js 22 ou plus récent et npm. La documentation officielle indique que l'utilisation peut envoyer une requête de version passive (passive version request) à titre d'effet secondaire de télémétrie ; c'est l'effet réseau explicitement annoncé par l'éditeur, une condition à accepter avant usage, à garder à l'esprit lors de l'installation. Au-delà, l'existence d'autres accès réseau n'est pas précisée dans les informations disponibles.
• Le chemin principal recommandé est unique : installer globalement le paquet à version figée via npm, puis initialiser selon les étapes officielles :

npm install --global @escoffier-labs/[email protected]
brigade setup

• Déclencher la première tentative : faites exécuter brigade work claim --next --actor codex à l'agent pour qu'il réclame une tâche prête dans le journal partagé — c'est le flux de travail central présenté officiellement. Attention : réclamer, c'est « emporter la tâche prête ». Ce que devient son état dans le journal ensuite et si l'on peut annuler ne sont pas précisés ; traitez cela comme une opération qui modifie le journal.
• Si vous ne voulez pas encore que l'agent réclame du travail, lancez d'abord brigade memory serve-mcp --stdio en local, en mode stdio, branchez-le à votre harness comme serveur MCP et observez si vous pouvez lire la mémoire et les compétences de Brigade via MCP — cette étape ne comporte aucune réclamation.
• Signal de succès : l'agent obtient une tâche prête via la commande de réclamation, ou le harness lit la mémoire et les compétences de Brigade via MCP. Le comportement précis de brigade setup et sa sortie en cas de succès ne sont pas décrits officiellement ; si la commande ne se comporte pas comme prévu, vérifiez d'abord que la version de Node.js satisfait l'exigence, puis confrontez les étapes au dépôt officiel.

Cas d'usage

• Cas 1 : faire partager un même journal de travail à plusieurs agents. Scénario : vous utilisez plus d'un agent de codage et voulez qu'un endroit unique indique qui fait quoi et jusqu'où, au lieu que tout soit dispersé dans des sessions séparées et que l'on perde le contexte à chaque changement d'outil. Lancement : après l'installation et brigade setup, faites exécuter brigade work claim --next --actor codex à l'agent au début d'une tâche. Flux : work claim — l'agent réclame une tâche prête dans le journal partagé. À quoi s'attendre : la tâche est réclamée, le journal est conservé dans des fichiers locaux sans démon. La mise à jour du journal après réclamation et la consultation de tout le travail ne sont pas décrites officiellement ; ce qui est confirmable aujourd'hui s'arrête à l'étape de réclamation.
• Cas 2 : servir la mémoire et les compétences à un harness. Scénario : vous voulez que le harness utilise, en traitant ses tâches, la mémoire et les compétences entretenues par Brigade, plutôt que chaque outil garde les siennes sans rien partager. Lancement : démarrez brigade memory serve-mcp --stdio en mode stdio et branchez-le au harness comme serveur MCP. Flux : memory serve-mcp — Brigade expose via ce serveur la mémoire et les compétences au harness. À quoi s'attendre : le harness peut lire la mémoire et les compétences via MCP. La façon dont votre client enregistre un serveur MCP stdio et les interfaces appelables après branchement ne sont pas décrites officiellement ; branchez selon la méthode habituelle de votre harness, puis vérifiez.

Limites d'usage

• Accès réseau : la documentation officielle indique qu'une requête de version passive peut être envoyée une fois à des fins de télémétrie ; c'est divulgué proactivement par l'éditeur. Au-delà, l'existence d'autres accès réseau n'est pas précisée : ne le considérez donc pas comme un outil local totalement hors ligne.
• Fichiers et effets secondaires : le journal de travail est conservé dans des fichiers locaux, sans démon ; la réclamation emporte une tâche prête du journal partagé, et la possibilité d'annuler n'est pas précisée. Les modifications qu'apportent l'installation et brigade setup au système ne sont pas détaillées point par point.
• Environnement d'exécution et client : la voie npm exige Node.js 22 ou plus récent et npm ; la liste des harnesses pris en charge n'est pas confirmée, et c'est à vous de vérifier que le vôtre fonctionne.
• Version et autres : la commande d'installation est figée à 0.30.0 ; les autres versions et les voies de mise à niveau ne sont pas confirmées. Au-delà de la réclamation, la façon d'ajouter du travail, de consulter tout le travail ou d'écrire dans la mémoire et les compétences n'est pas couverte par les informations officielles disponibles. Avant de l'intégrer à votre flux quotidien, faites un essai à petite échelle, confirmez que le comportement correspond aux attentes, puis élargissez l'usage.