Mission Control : ne perdez plus la trace de quel agent a besoin de vous

Deux agents sur un canevas, c'est facile à surveiller. Six, c'est un autre problème. Le canevas est une disposition spatiale — des tiles éparpillés là où vous les avez déposés — mais la question à laquelle vous avez réellement besoin d'une réponse n'est pas « où est tout le monde », c'est « qui est bloqué sur moi maintenant ». La disposition spatiale ne répond pas à une question d'état. Vous finissez par scanner tile par tile, et le scan ne passe pas à l'échelle.

C'est le problème de gestion de l'attention qui apparaît dès que vous passez de l'exécution d'un agent à l'orchestration d'une flotte. Un prompt de permission resté sans réponse trois écrans à gauche ne vous coûte rien tant que vous êtes concentré sur le tile quatre — jusqu'à ce que vous remarquiez, dix minutes plus tard, qu'un agent est resté inactif tout ce temps à attendre un oui/non que vous n'avez jamais vu.

La réponse de MadoHub est Mission Control, le panneau Fleet. Ça vaut la peine de parcourir comment ça fonctionne réellement, parce que les choix de design correspondent directement au problème.

Comment MadoHub gère ça

Grouper par état, pas par position

Le mouvement central de Mission Control est d'arrêter d'organiser les agents spatialement et de commencer à les organiser par état. Chaque tile d'agent atterrit dans exactement un des six groupes, toujours rendus dans le même ordre fixe :

Les groupes vides ne rendent pas de titre du tout — vous ne voyez jamais « Failed (0) » prendre de la place pour rien. L'ordre lui-même encode la priorité de tri : l'agent resté sur un prompt de permission pendant dix minutes apparaît au-dessus de l'agent qui travaille joyeusement, qui apparaît au-dessus de l'agent déjà terminé qui n'attend que vous le regardiez. Vous lisez la liste dans l'ordre où vous devriez réellement agir.

Le badge replié n'est délibérément pas « le nombre total d'agents ». Si un tile attend une entrée, il affiche ce compte sur un badge ambre — le nombre pour lequel ça vaut la peine d'interrompre. Sinon, il affiche le compte de tous les tiles en cours, en texte atténué. Tout ce que vous exécutez ne mérite pas une attention égale : un tile qui travaille tranquillement n'en a pas besoin, un tile bloqué sur un prompt en a besoin entièrement, immédiatement.

Afficher la question réelle, pas seulement le fait qu'il y en a une

Le groupement par état vous dit *qu'*un agent a besoin d'une entrée. Il ne vous dit pas *ce qu'*il demande — et cet écart est là où les gens finissent par basculer vers le tile quand même, juste pour lire la question, anéantissant l'intérêt d'un panneau de tri.

Mission Control comble cet écart. Pour chaque ligne du groupe Needs Input, il affiche les deux dernières lignes de la sortie du terminal de ce tile. En pratique, c'est presque toujours la question en attente réelle — un (y/n), un choix « Allow once / Allow always / Deny », ou similaire — rendu dans un petit bloc à bordure ambre juste sous la ligne. C'est la différence entre « l'Agent 3 a besoin d'une entrée » et « l'Agent 3 demande s'il peut rm -rf node_modules — oui, évidemment, vas-y ». L'une se décide sans quitter le panneau ; l'autre force un changement de contexte dont vous n'aviez pas besoin.

Sauter vers le tile en un clic

Une fois qu'une ligne mérite action, cliquer dessus panoramique et zoome le viewport du canevas directement vers ce tile — de « l'agent X a besoin de moi » dans le panneau au fait de regarder le terminal de l'agent X en un clic, sans fouiller à travers un canevas avec une douzaine de tiles. Le groupement par état vous dit ce qui mérite attention et dans quel ordre, la queue de question en attente vous dit la question réelle, et le clic fly-to-tile vous y emmène.

Progression en direct des Dynamic Workflows, sans inondation de badges

La propre fonctionnalité Dynamic Workflows de Claude Code peut déployer une session Claude unique en plusieurs sous-agents concurrents. MadoHub ne les crée ni ne les exécute — c'est une fonctionnalité de Claude Code, pas de MadoHub — mais il détecte l'activité des sous-agents et la regroupe en une seule ligne de progression par tile au lieu de déclencher une notification normale par sous-agent, afin qu'une exécution avec une douzaine de sous-agents n'inonde pas le canevas de badges.

Mission Control expose cette progression par ligne, sous la ligne d'activité, chaque fois qu'un tile a une exécution active :

workflow · 3/5 agents

Les deux nombres sont les sous-agents ayant atteint un état terminal sur les threads de sous-agents distincts vus jusqu'ici sur ce tile. La ligne n'apparaît que pendant que l'exécution est active et disparaît d'elle-même une fois elle se termine. Démarrer un nouveau workflow sur le même tile réinitialise les deux compteurs à zéro plutôt que d'accumuler.

Conseils pratiques

• Lisez la liste dans l'ordre. L'ordre des groupes est l'ordre de tri — needs input d'abord, puis working, puis done. Ne sautez pas aux lignes « done » tant que les « needs input » ne sont pas traitées.
• Décidez depuis la queue quand vous le pouvez. Si la question en attente est une permission routinière que vous accorderiez de toute façon, vous pouvez souvent y répondre mentalement et voler jusqu'au tile juste pour confirmer — ou sauter complètement le détour par le panneau pour les tiles que vous alliez visiter de toute façon.
• Utilisez le badge replié comme signal d'interruption. Traitez le nombre ambre comme « arrête ce que je fais et vérifie ». Un zéro signifie que vous pouvez rester concentré.
• N'attendez pas de shells simples. Un tile de terminal simple n'apparaît jamais dans Mission Control — seuls les tiles reconnus comme CLIs d'agents y figurent, donc le panneau n'est pas encombré de vos terminaux de brouillon.

Rien de tout ça n'est individuellement compliqué — grouper par état, afficher les deux dernières lignes de sortie, sauter vers le tile au clic. La valeur est dans ce que ça retire : garder en tête l'état de six tiles, scanner un canevas pour trouver celui qui est bloqué, ouvrir un tile juste pour lire une question que vous auriez pu lire dans une barre latérale.

L'état déplié/replié de Mission Control n'est volontairement pas persisté — chaque lancement frais démarre replié, n'affichant que le badge. C'est le bon défaut pour un panneau dont tout le travail est de répondre à une seule question vite puis de se faire oublier.

Documentation associée

• Mission Control
• Le tiroir droit
• Dynamic Workflows