Before submitting
Area
apps/web
Problem or use case
The thread lifecycle assumes a thread is a problem that gets solved and reaches a terminal state: work happens, the agent finishes, the thread is Done, it settles, it leaves the inbox. That fits task threads well.
But a large class of threads are standing sessions tied to an ongoing responsibility rather than a fix — a triage session I return to for days, an ops thread, a release thread, a research log, a recurring report. They are never "done"; they go quiet between bursts by design, and that quiet is their normal resting state, not a completion.
Why this matters
Every signal in the lifecycle misfires on them:
The net effect: the states that carry information on task threads carry none on standing ones, and the signal degrades across the whole sidebar — which is where the product's value is concentrated when you run many threads.
Proposed solution
Model a standing/recurring thread as its own kind (a per-thread mode, not a new object): its resting state is "idle, as expected" rather than "done"; it is exempt from every auto-settle trigger; it does not raise the unread/Done affordance merely because the last turn ended. Ordinary task threads keep today's behavior unchanged.
Smallest useful scope
The durable keep-active pin already requested in #5575, plus suppressing the Done/unread completion signal for pinned threads.
Alternatives considered
Manually un-settling forever (doesn't stick); archiving standing threads between uses (loses them from view, and the context is exactly what makes them valuable); a separate project per standing thread (heavy, and doesn't change the lifecycle).
Risks or tradeoffs
A second thread kind is real product surface, and a thread exempt from settling can accumulate silently if the user forgets it — so the pin should be visible on the row, and removable in one action.
Before submitting
Area
apps/web
Problem or use case
The thread lifecycle assumes a thread is a problem that gets solved and reaches a terminal state: work happens, the agent finishes, the thread is Done, it settles, it leaves the inbox. That fits task threads well.
But a large class of threads are standing sessions tied to an ongoing responsibility rather than a fix — a triage session I return to for days, an ops thread, a release thread, a research log, a recurring report. They are never "done"; they go quiet between bursts by design, and that quiet is their normal resting state, not a completion.
Why this matters
Every signal in the lifecycle misfires on them:
The net effect: the states that carry information on task threads carry none on standing ones, and the signal degrades across the whole sidebar — which is where the product's value is concentrated when you run many threads.
Proposed solution
Model a standing/recurring thread as its own kind (a per-thread mode, not a new object): its resting state is "idle, as expected" rather than "done"; it is exempt from every auto-settle trigger; it does not raise the unread/Done affordance merely because the last turn ended. Ordinary task threads keep today's behavior unchanged.
Smallest useful scope
The durable keep-active pin already requested in #5575, plus suppressing the Done/unread completion signal for pinned threads.
Alternatives considered
Manually un-settling forever (doesn't stick); archiving standing threads between uses (loses them from view, and the context is exactly what makes them valuable); a separate project per standing thread (heavy, and doesn't change the lifecycle).
Risks or tradeoffs
A second thread kind is real product surface, and a thread exempt from settling can accumulate silently if the user forgets it — so the pin should be visible on the row, and removable in one action.