Pourquoi Muse Code garde ses agents en vie toute la session
La décision d'architecture discrète derrière la vitesse de Muse Code : des agents d'arrière-plan qui persistent pendant toute la session, au lieu d'être créés puis jetés à chaque tâche.
Le problème du « créer puis jeter »
La plupart des outils de code multi-agents suivent la même recette : une tâche arrive, on lance un agent assistant, on lui confie une tranche de travail, on récupère le résultat, on le détruit. C’est une abstraction propre, avec un coût moche. Chaque agent fraîchement lancé part de zéro — il doit relire la structure du dépôt, redécouvrir le système de build, réapprendre les conventions de ta codebase. Sur une session de dix tâches, cette taxe de collecte de contexte est payée dix fois.
Et la taxe ne se limite pas aux tokens. C’est de la latence — chaque démarrage à froid retarde le vrai travail — et c’est de l’effort de pilotage, parce qu’un agent qui a oublié ce qu’il a appris il y a une heure te pose deux fois les mêmes questions.
La réponse de Muse Code : la persistance
Muse Code est construit comme une boucle d’agent principal toute simple, plus un ensemble d’agents d’arrière-plan asynchrones — et ces agents d’arrière-plan restent actifs pendant toute la session. Ils ne sont pas créés pour des tâches individuelles. Chacun est spécialisé, accumule du contexte au fil de la session, et décide lui-même quand quelque chose mérite d’être remonté à l’agent principal.
Ce dernier détail compte plus qu’il n’y paraît. Les agents d’arrière-plan ne bloquent pas la boucle principale en attendant des instructions, et ils ne l’inondent pas non plus de mises à jour de statut. Ils enchaînent les étapes suivantes de façon autonome et communiquent quand ça compte. La justification affichée de Meta, c’est exactement les deux coûts ci-dessus : la persistance réduit la latence, et elle réduit le besoin de pilotage humain sur les tâches difficiles à étapes multiples.
Des workers en parallèle, des reviewers en arrière-plan
En pratique, tu vis ça comme une équipe avec des rôles permanents plutôt qu’une file d’intérimaires. Les workers exécutent les changements en parallèle ; les reviewers critiquent la production en continu, en arrière-plan, avant qu’elle n’arrive jusqu’à toi. La formule du lancement — « multi-agent par défaut » — est précise : la coordination n’est pas un mode que tu actives, c’est la façon dont chaque tâche s’exécute. Tu livres plus vite non pas parce qu’un agent isolé est plus rapide, mais parce que le contrôle qualité se fait en parallèle au lieu d’arriver après coup.
Entraîné dans le modèle, pas boulonné dessus
Il y a une raison pour laquelle ce design de harnais fonctionne mieux avec Muse Spark 1.2 qu’un wrapper générique de modèle. Le modèle a été co-entraîné avec le harnais Muse Code — sa recette d’entraînement optimisait explicitement le comportement des subagents, aux côtés des objectifs et de la compaction de contexte. La division du travail entre une boucle principale et des spécialistes persistants n’est pas une astuce de prompt engineering posée par-dessus ; le modèle l’a vue pendant l’entraînement. C’est de là que viennent les promesses « moins de retries, meilleur usage des outils », et on en parle en détail dans notre article sur l’entraînement de Muse Spark 1.2.
Ce que la persistance ne résout pas
Des agents à longue durée de vie qui modifient le même dépôt en même temps, ce serait la recette parfaite du désastre de merge — s’ils partageaient une copie de travail. Ce n’est pas le cas. Quand le travail part en fan-out, chaque agent enfant capable d’écrire reçoit son propre worktree git isolé, si bien que le travail parallèle n’entre jamais en collision sur les fichiers. Ce mécanisme d’isolation mérite sa propre explication : fan-out d’agents et worktrees git. Et quand tu veux savoir ce que l’un de ces agents a réellement fait pendant que tu ne regardais pas, l’event log en append-only détient la réponse complète.