Motivation
agent-deck's headline feature: persistent agent sessions that 'monitor and orchestrate all your other sessions' — auto-respond when confident, escalate when uncertain, optionally pingable via Telegram/Slack. This is the most novel capability and the one that genuinely differentiates a session manager from a session list.
Scope (high-level — needs deeper design before kickoff)
- A 'conductor' is a special session running its own agent (Claude/Codex/etc.) with a system prompt + access to the agent-view DB and tmux.
- Conductors have a heartbeat interval (default ~15 min, configurable) on which they wake, scan session statuses, and decide whether to act.
- Decision policies: auto-respond (low-stakes, configurable per-session), escalate to user (push notification / status flag in TUI), or no-op.
- Conductors persist across agent-view restarts.
Design questions — REQUIRES BRAINSTORM SESSION before kickoff
- Tool surface: what tools does a conductor have? Read pane content, send keys, query DB, mark a session for user attention. Anything else?
- Trigger model: pure heartbeat poll, or event-driven (status-change on any session)? Event-driven is more responsive but harder to reason about.
- Authority model: how do we prevent a conductor from going rogue (e.g., approving destructive actions on a child session)? Allowlist of actions per child session? Required-confirmation modes?
- Conductor prompts/policies: where do they live? Per-conductor config file? Templated in agent-view?
- Output channel: how does a conductor signal back to the user? In-TUI inbox? OS notification? File-based?
- Multi-conductor: can multiple conductors run? Do they coordinate?
Out of scope
- Telegram/Slack remote control (separate, lower priority).
This is the most ambitious item and should be the last one tackled. Better to have runner abstraction, status detection, worktrees, and forking solid first — conductors will lean on all of them.
Motivation
agent-deck's headline feature: persistent agent sessions that 'monitor and orchestrate all your other sessions' — auto-respond when confident, escalate when uncertain, optionally pingable via Telegram/Slack. This is the most novel capability and the one that genuinely differentiates a session manager from a session list.
Scope (high-level — needs deeper design before kickoff)
Design questions — REQUIRES BRAINSTORM SESSION before kickoff
Out of scope
This is the most ambitious item and should be the last one tackled. Better to have runner abstraction, status detection, worktrees, and forking solid first — conductors will lean on all of them.