Working with companions that act on their own means many threads at once. This guide explains where a thread lives, how it moves when it needs you, and when it closes — so you always know which threads are waiting on you and which are running on their own.
Where a thread lives
Every piece of work is a thread, and each thread sits in one of the three tabs (see Desktop app):
- Conversations — you and a companion, talking. These are yours to drive.
- Activity — the companion working on its own: peer agents, scheduled runs, Slack and email handled in the background. It behaves like an inbox — read threads hide by default.
- Thoughts — the companion's inner life: introspection, analyses, the traces of its dreams.
The rule of thumb: Conversations need you, Activity does not — until it does.
When a thread needs your attention
A companion working autonomously in Activity will, at some point, hit a decision that belongs to you — an approval, a direction, a judgment call it shouldn't make alone. When that happens the thread is escalated: it moves out of Activity and into Conversations, so it lands in front of you instead of waiting unnoticed in the background.
This is the single signal to trust: anything that needs a decision from you surfaces in Conversations. You never have to go digging through Activity to find out what needs a reply — the work that needs you comes to you.
The reverse also holds. A thread you were in that no longer needs you — because it is now waiting on a peer agent, on a CI run, or on a scheduled follow-up — steps back into Activity and continues on its own. You are only ever pulled in when there is a real decision to make.
How a thread moves
Across its life a thread is in one of a few plain states:
- Working — actively running, in Activity. No action needed; a live pulse shows it's in progress.
- Waiting on you — escalated to Conversations. Your turn.
- Waiting on something else — a peer agent's reply, an external signal like a CI run or a pull-request status, or a scheduled wake-up. It sits in Activity and resumes the moment that signal fires (see Scheduled tasks & watchdog).
- Resolved — the work is done and delivered.
- Closed — set aside because the work became irrelevant before it could land, often by the watchdog cleaning up stale threads (see Scheduled tasks & watchdog).
- Abandoned — the thread went quiet without ever reaching a conclusion. It's set aside rather than left pretending to be active.
When a thread resolves
A thread resolves when its work actually lands — a pull request opened, a message sent, a document produced and handed to you, a question you acknowledged — not merely because the companion decided it was finished. Delivery, not self-assessment, is what closes a thread. That keeps "resolved" meaning you got the outcome, so nothing quietly marks itself done while you're left unaware.
Resolved, closed, and abandoned threads are hidden by default to keep your view clean. One Show resolved toggle brings them back whenever you want the history.
Staying oriented
The sidebar is built for triage across many threads at once:
- Unread counters per tab tell you where new activity is.
- Hide read keeps Activity behaving like an inbox — only the unread, the running, and the escalated stay in view.
- Filters and search — by agent, domain, or priority, plus full-text search.
- Linked threads in the context panel keep related work connected, so an escalated thread always leads back to the work that produced it.
The result: you don't monitor your companions. Conversations shows you what needs you, Activity carries what doesn't, and threads that need a decision come find you.