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](https://github.com/ArthurDEV44/paneflow/releases/tag/v0.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 [#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.

```bash
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 [#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 [#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 [#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 [#start-with-a-small-fleet]

The full reference is in the [Conductor docs](/docs/conductor). 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.