Laissez un agent de code piloter les autres avec Paneflow Conductor

Lancer un agent de code est simple. En lancer plusieurs en parallèle devient un problème de coordination : lequel travaille, lequel attend, quelle branche change, et quel résultat doit alimenter l'étape suivante ?

Paneflow Conductor arrive avec Paneflow 0.6.0 pour rendre cette coordination explicite. Un agent peut découvrir ses pairs, lire leur sortie, envoyer le prompt suivant et attendre la fin du tour via la CLI publique paneflow.

Une seule CLI pour toute la flotte

Tout passe par le socket local de Paneflow. Le conductor peut être Claude Code, Codex, OpenCode, Gemini ou un script, parce que l'interface reste une suite de commandes shell.

paneflow ps
paneflow status claude-impl
paneflow read claude-impl --lines 120
paneflow send claude-impl "Keep going and finish with REPORT_DONE"
paneflow wait --match claude-impl --pattern '^REPORT_DONE'
paneflow watch

C'est le changement important. Codex peut inspecter ce que Claude Code a produit. Claude Code peut confier une revue à OpenCode. Un script peut lancer le même workflow sans dépendre du harness utilisé dans chaque panneau.

Pour les travaux répétables, paneflow up lance un espace de travail hooké depuis un fichier TOML, et paneflow flow run exécute un pipeline multi-agent avec spawn, attente, transmission de contexte et revue.

Déléguer sans masquer les terminaux

Paneflow Conductor ne remplace pas les agents et ne transforme pas Paneflow en runtime hébergé. Les panneaux restent de vrais terminaux. Vous pouvez les lire, reprendre la main, arrêter une commande ou changer de direction.

L'intérêt est que les agents n'ont plus besoin de contexte copié-collé. Un agent conductor peut lire un panneau voisin, comprendre l'état courant, envoyer un follow-up précis, puis attendre une sentinelle comme REPORT_DONE avant de continuer.

Ce pattern devient utile quand vous séparez implémentation, revue, tests et documentation. L'agent leader n'a pas besoin de deviner depuis des notes périmées. Il inspecte la flotte réelle.

Attendre l'état, pas un timer

Paneflow 0.6.0 ajoute une machine d'état suivie tour par tour pour les agents hookés. Un panneau peut remonter des états comme thinking, waiting_for_input ou finished. paneflow watch diffuse les événements de cycle de vie en JSONL, et paneflow wait bloque sur une condition au lieu de dormir pendant un délai arbitraire.

C'est la différence entre orchestration et screen scraping. Un conductor ne devrait pas poller un terminal toutes les quelques secondes en espérant que la sortie soit stabilisée. Il doit réagir quand l'agent s'arrête vraiment, demande une entrée ou imprime le marqueur promis.

Garder la frontière de contrôle visible

Le modèle de sécurité est volontaire. Le bridge MCP est en lecture seule. paneflow read traite la sortie des pairs comme une donnée non fiable. Par défaut, paneflow send pré-remplit un prompt et un humain appuie encore sur Entrée.

L'auto-submit existe, mais il reste opt-in via la gate de scripting ou le mode AI free access. Cela garde le chemin puissant disponible pour les worktrees isolés et les workflows de confiance, sans faire des écritures silencieuses entre panneaux le comportement par défaut.

Cette frontière est le point central : donner assez de contexte partagé aux agents pour travailler ensemble, tout en gardant les terminaux visibles et la reprise humaine possible.

Commencer avec une petite flotte

La référence complète est dans la documentation Conductor. Commencez avec deux panneaux : un agent d'implémentation, un agent de revue, et un conductor qui lit les deux avant d'envoyer le prompt suivant.

Si vous faites déjà tourner plusieurs agents CLI côte à côte, Paneflow Conductor leur donne une surface commune au lieu d'un protocole privé de plus.