Let one coding agent drive the others with Paneflow Conductor

Running one coding agent is easy. Running several at once turns into a coordination problem: which agent is working, which one is waiting, which branch is changing, and which result should feed the next step?

Paneflow Conductor ships in Paneflow 0.6.0 to make that coordination explicit. One agent can discover its peers, read their output, send the next prompt, and wait for the turn to finish through the public paneflow CLI.

One CLI for the whole fleet

Everything goes through Paneflow's local socket. The conductor can be Claude Code, Codex, OpenCode, Gemini, or a script, because the interface is just shell commands.

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

That is the important shift. Codex can inspect what Claude Code produced. Claude Code can hand a review task to OpenCode. A script can start the same workflow without caring which harness each pane runs.

For repeatable work, paneflow up starts a hooked workspace from a TOML file, and paneflow flow run executes a multi-agent pipeline with spawn, wait, feed, and review steps.

Delegate without hiding the terminals

Paneflow Conductor does not replace the agents and does not turn Paneflow into a hosted runtime. The panes remain real terminals. You can read them, take over, stop a command, or change direction.

The value is that agents no longer need copy-pasted context. A conductor agent can read a neighboring pane, understand the current state, send a focused follow-up, then wait for a sentinel like REPORT_DONE before it continues.

That pattern matters when you split work across implementation, review, tests, and docs. The leader agent does not need to guess from stale notes. It can inspect the actual fleet.

Wait on state, not timers

Paneflow 0.6.0 adds a turn-tracked state machine for hooked agents. A pane can report states such as thinking, waiting_for_input, and finished. paneflow watch streams lifecycle events as JSONL, and paneflow wait blocks on a condition instead of sleeping for an arbitrary delay.

This is the difference between orchestration and screen scraping. A conductor should not poll a terminal every few seconds and hope the output has settled. It should react when the agent actually stops, asks for input, or prints the marker it promised.

Keep the control boundary visible

The safety model is deliberate. The MCP bridge is read-only. paneflow read treats peer output as untrusted data. By default, paneflow send pre-fills a prompt and a human still presses Enter.

Auto-submit exists, but it is opt-in through the scripting gate or AI free access mode. That keeps the powerful path available for isolated worktrees and trusted workflows, without making silent cross-pane writes the default.

That boundary is the point: give agents enough shared context to work together, while keeping the terminals visible and the human able to take over.

Start with a small fleet

The full reference is in the Conductor docs. Start with two panes: one implementation agent, one review agent, and a conductor that reads both before sending the next prompt.

If you already run several CLI agents side by side, Paneflow Conductor gives them a common surface instead of another private protocol.