Lass einen Coding-Agenten die anderen mit Paneflow Conductor steuern

Einen Coding-Agenten zu starten ist einfach. Mehrere parallel zu starten wird zu einem Koordinationsproblem: Welcher Agent arbeitet, welcher wartet, welcher Branch ändert sich, und welches Ergebnis soll den nächsten Schritt auslösen?

Paneflow Conductor kommt mit Paneflow 0.6.0, um diese Koordination explizit zu machen. Ein Agent kann seine Peers finden, ihre Ausgabe lesen, den nächsten Prompt senden und über die öffentliche paneflow CLI warten, bis der Turn fertig ist.

Eine CLI für die ganze Flotte

Alles läuft über den lokalen Socket von Paneflow. Der Conductor kann Claude Code, Codex, OpenCode, Gemini oder ein Script sein, weil die Oberfläche nur aus Shell-Befehlen besteht.

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

Das ist die wichtige Verschiebung. Codex kann prüfen, was Claude Code erzeugt hat. Claude Code kann OpenCode eine Review-Aufgabe geben. Ein Script kann denselben Workflow starten, ohne sich darum zu kümmern, welches Harness in welchem Pane läuft.

Für wiederholbare Arbeit startet paneflow up einen gehookten Workspace aus einer TOML-Datei, und paneflow flow run führt eine Multi-Agent-Pipeline mit Spawn, Wait, Feed und Review aus.

Delegieren, ohne die Terminals zu verstecken

Paneflow Conductor ersetzt die Agenten nicht und macht Paneflow nicht zu einer gehosteten Runtime. Die Panes bleiben echte Terminals. Du kannst sie lesen, übernehmen, einen Befehl stoppen oder die Richtung ändern.

Der Wert liegt darin, dass Agenten keinen kopierten Kontext mehr brauchen. Ein Conductor-Agent kann ein benachbartes Pane lesen, den aktuellen Zustand verstehen, einen gezielten Follow-up senden und dann auf eine Sentinel-Zeile wie REPORT_DONE warten, bevor er weitermacht.

Dieses Muster zählt, wenn du Implementierung, Review, Tests und Dokumentation trennst. Der Leader-Agent muss nicht aus veralteten Notizen raten. Er inspiziert die echte Flotte.

Auf Zustand warten, nicht auf Timer

Paneflow 0.6.0 fügt für gehookte Agenten eine Turn-getrackte Zustandsmaschine hinzu. Ein Pane kann Zustände wie thinking, waiting_for_input und finished melden. paneflow watch streamt Lifecycle-Events als JSONL, und paneflow wait blockiert auf eine Bedingung statt auf eine beliebige Pause.

Das ist der Unterschied zwischen Orchestrierung und Screen Scraping. Ein Conductor sollte ein Terminal nicht alle paar Sekunden pollen und hoffen, dass die Ausgabe stabil ist. Er sollte reagieren, wenn der Agent wirklich stoppt, nach Eingabe fragt oder den vereinbarten Marker druckt.

Die Kontrollgrenze sichtbar halten

Das Sicherheitsmodell ist bewusst gesetzt. Die MCP-Bridge ist read-only. paneflow read behandelt Peer-Ausgabe als nicht vertrauenswürdige Daten. Standardmäßig füllt paneflow send nur einen Prompt vor, und ein Mensch drückt weiterhin Enter.

Auto-submit existiert, ist aber opt-in über das Scripting-Gate oder den AI-free-access-Modus. So bleibt der mächtige Pfad für isolierte Worktrees und vertrauenswürdige Workflows verfügbar, ohne stille Cross-Pane-Schreibzugriffe zum Standard zu machen.

Genau diese Grenze zählt: Agenten genug gemeinsamen Kontext geben, damit sie zusammenarbeiten, während die Terminals sichtbar bleiben und der Mensch jederzeit übernehmen kann.

Mit einer kleinen Flotte starten

Die vollständige Referenz steht in den Conductor-Dokumenten. Starte mit zwei Panes: ein Implementierungsagent, ein Review-Agent und ein Conductor, der beide liest, bevor er den nächsten Prompt sendet.

Wenn du bereits mehrere CLI-Agenten nebeneinander laufen lässt, gibt Paneflow Conductor ihnen eine gemeinsame Oberfläche statt eines weiteren privaten Protokolls.