Native session notification bridge, direct session→Slack/Telegram without conductor tokens

[johnuopini]

Problem:
When a session goes into waiting or idle state (e.g., asking a permission question or needing user input), the only way to surface this to the user is through the conductor heartbeat. This consumes AI tokens for what is essentially a mechanical task: "session X is waiting, here's what it said, forward the reply back."

Current workaround:
Users have to build a standalone notifier script that polls agent-deck list --json, reads session output, posts to Slack, tracks thread→session mappings, and routes replies back. This duplicates logic the bridge already partially has.

Proposed feature:

Add a native "session notifier" mode to the bridge (or as a new lightweight daemon) that:

1. Polls for waiting/idle sessions — periodically checks non-conductor sessions via agent-deck list --json or even just implement next item leaving polls outside
2. Posts output to Slack/Telegram — reads last output with session output -q and forwards it directly, tagged with session name
3. Routes replies back — when the user replies in a Slack thread (or replies to a Telegram message), maps it back to the originating session and sends via session send
4. Supports numbered choices — detects patterns like 1. Option A / 2. Option B in session output and renders them as interactive buttons (Slack Block Kit / Telegram inline keyboard). Button tap sends the number back to the session.
5. Deduplicates — tracks posted outputs by hash to avoid spamming the same message

Key point: This should work with zero AI token consumption. It's pure CLI polling + messaging API. The conductor remains available for complex decisions and orchestration, but routine "session needs input" cases bypass it entirely.

Why native: The bridge already has Slack/Telegram connections, heartbeat loop, and session CLI wrappers. Adding this as a bridge mode (e.g., notify_idle_sessions = true in config.toml) would be ~100 lines of code in the right place vs. users reinventing it externally.

[asheshgoplani]

Thanks for the report and for helping improve Agent Deck. We have finished this release cycle and are closing this issue for tracker cleanup. If this is still relevant for you, please reopen with latest repro details and we will pick it up again quickly.

[asheshgoplani]

Reopening: this issue is not fully resolved yet and was closed during cleanup by mistake.

[benkauffman]

The polling-for-waiting-state pattern is something I've been thinking about too. In ctrl, the daemon parses the JSONL stream in real time and updates each agent's FSM state (idle/working/waiting/blocked), so you always have a clean state signal without needing to poll the CLI. That state object is what drives the office visualization, but it would also be a natural hook for push notifications. I haven't built the Slack/Telegram bridge yet, but the underlying state detection is there — might be worth looking at the JSONL event types for waiting_for_input vs tool_use as a more reliable trigger than polling intervals.