Parked: agent orchestrator, sequences of agent sessions across the fleet

[karngyan]

Status

Parked. Decided 2026-08-21. No AI features in flue for now, and this is the most AI-shaped idea on the board. Kept as a note so the thinking is not lost. Nothing here blocks #112, #132 or #133.

Why

Once the pieces land, flue can start an agent on machine X in directory Y with prompt P (the composer, #112), know when it finishes or blocks (agent hooks, #132), read what it did (the viewer, and the diff view in #130) and show the facts on a card (#134). An orchestrator is the glue: a sequence of runs, each one a real session the user can open, across every machine and every agent.

Nobody in the field does this across machines and across vendors. Each vendor's own orchestration (subagents, cloud tasks) stays inside its own tool.

Rough scope

• Runs are sessions. Every step is a pty with a shell and an agent in it, listed in the sessions screen, attachable, with a transcript. No hidden processes, no second execution model.
• Fan out. The same prompt into N repositories or N machines, one session each, one place to watch them all. The cheapest useful version and the one to start with.
• Chains. When A stops, start B, in the same directory or on another machine, with A's transcript tail or its Session card: what a session did while you were away, from facts flue already has (no model) #134 card as the opening context. Hooks give the stop signal. No model needed for the handoff.
• Templates. A saved recipe: machine, directory, agent, prompt, what to do when it stops. Runnable from the composer or from the phone.

Notes

• Needs the composer (Session composer: start agent sessions from any device #112), the hooks (Agent hooks: let Claude Code, Codex and Pi tell flue when a session needs you, finished, or wants a permission #132) and the chat view (Chat view: read and reply to a live agent session from a phone, no terminal required #133) first, and the design should wait until those exist and have taught us what a run looks like in practice.
• The risk is a workflow engine. Keep to "sequences of sessions": no conditionals, no retries, no DAG editor. If it needs a graph, it is a different product.
• A run that blocks on a prompt is just a session in the needs-you queue (Needs-you queue: fleet-wide list of sessions blocked on a prompt #110). No orchestrator-specific inbox.
• flue never writes the prompts itself. The user writes every prompt in a template; flue only starts sessions and passes text along. That keeps every run interactive use of the user's own tool.