The use case
I run several recurring agent automations with schedule_task. Each one is bound to its own thread (bindToCurrentThread: true), so every run of an automation adds to the same thread. They all follow the same pattern: check something often, act only when there is something to do.
- Hourly issue watcher: reads new issue comments and picks up requests aimed at the agent, such as "write a plan for this" or "implement the approved plan".
- Hourly PR review check: looks for PRs that are waiting on a review and reviews them.
- Auto-labeler and tidier: triages new issues, adds labels, links duplicates and flags stale branches.
- Daily digest: a short report on what changed in open issues and PRs since yesterday.
- Daily error triage: reviews new production errors and opens or updates an issue only when the evidence is strong.
Most runs find nothing and post one line. A few find real work.
What goes wrong
Every run starts a turn, so each automation thread keeps coming back to the top of the active list. They end up mixed in with the threads I actually work in. Snooze doesn't stick (#14625), and an agent can't settle its own thread while its run is active (#13630). I end up settling quiet runs by hand, which defeats the point of an automation that should only get my attention when something matters.
Proposal: treat these as persistent automation threads
- A collapsed "Automations" section in the sidebar holds every thread bound to a scheduled task. Each row shows the task name, last and next run, and an unread dot. Quiet runs stay there.
- A run surfaces only when it asks to. The agent marks the thread unread, or the run fails. Everything else stays in the section.
- Larger work moves to a fresh thread. When a run finds a real task (a plan to write, a PR to implement, a review to do), it starts a new top-level thread for it with
t3_thread_launch and leaves one line plus a link in the automation thread. The automation thread stays a clean, readable log of runs, and the actual work gets its own normal thread with its own worktree, PRs and notifications.
- Lineage: threads started this way show which automation started them, and the automation thread lists the threads it has launched.
Related
The use case
I run several recurring agent automations with
schedule_task. Each one is bound to its own thread (bindToCurrentThread: true), so every run of an automation adds to the same thread. They all follow the same pattern: check something often, act only when there is something to do.Most runs find nothing and post one line. A few find real work.
What goes wrong
Every run starts a turn, so each automation thread keeps coming back to the top of the active list. They end up mixed in with the threads I actually work in. Snooze doesn't stick (#14625), and an agent can't settle its own thread while its run is active (#13630). I end up settling quiet runs by hand, which defeats the point of an automation that should only get my attention when something matters.
Proposal: treat these as persistent automation threads
t3_thread_launchand leaves one line plus a link in the automation thread. The automation thread stays a clean, readable log of runs, and the actual work gets its own normal thread with its own worktree, PRs and notifications.Related