Nothing happens silently. A run that finishes, a question that is waiting on you, a specification that needs review: each one arrives as an entry on the bell in the header, so a run never ends without telling you how it went.
The bell
The bell sits in the header, beside the other controls for the view you are in. It carries a count of everything unread, and opening it shows the notifications grouped by where the work came from.
The count is the point. You do not have to open each view to find the run that wants you, and you do not have to watch a run to know it is over. The bell is the one place that states what changed while you were looking at something else.
What lands there
An entry is raised for a finished run, for a question the agent is waiting on, for a specification that is ready to read, and for a failure. Each kind is labelled where it appears, so a project that finished and a project that stopped to ask you something do not read the same at a glance.
Every entry names what it came from: the project and the thread, or the chat, or the assistant and its task. That name is enough to decide whether it is the thing you were waiting for.
Opening an entry returns you to the exact place the work stopped. Not the project, not the top of the thread: the point in the conversation where the run finished, or the question it parked on. Reading a notification is one action, and answering the question it points at is the next one.
Each entry can be dismissed on its own, and the panel can dismiss the whole list at once when you would rather start from empty.
The tabs and what they narrow to
The panel groups everything under four tabs: Projects, Chats, Assistants, and App Errors. Each tab carries its own count, so a finished run is visible without opening the view it came from.
The three work tabs carry narrowings: All, Done, Attention, and Issues, plus Spec on Projects. They are a way to ask a smaller question of the same list. Attention shows only what is waiting on a decision from you, and Spec shows only specifications ready for review.
A narrowing stays on until you clear it, and the active one stays visible in the row. That matters: a remembered filter is how a list starts looking empty for no reason.
Assistants report on their own clock
The Assistants tab is where scheduled work reports. A task that ran while the app was open leaves an unattended run with its outcome beside it: completed, failed, or waiting for you. A task that was due while the app was closed arrives as a missed run, and it offers to run now or to open the task instead.
Missed runs and finished runs fold under the assistant they belong to, so one assistant with a busy schedule reads as one group rather than a dozen separate notices. The tab can also be narrowed to a single assistant or task when you want only that one's history.
App errors
The fourth tab holds errors and warnings from the app itself, apart from the work. An entry states what happened, and where there is more detail you can read it or copy it, which is what you want before asking for help with it.
Keeping these apart from project notifications is deliberate. A failed provider call or a problem with a local server is something to fix, not something waiting on your review, and mixing the two makes both harder to see.
Work that keeps running
Leaving a thread does not stop it. Navigate to another view, open another thread, read a chat: the run continues, and every view keeps its place while you are away, so coming back costs nothing.
That is what makes the bell useful rather than decorative. A long run is something to start and leave, and the entry that arrives when it finishes is the only thing you had to wait for.
The same holds inside a view. A thread that is working shows its own state in the list, so a glance at the sidebar says which runs are live and which have stopped to ask something.
Long jobs and the dock
Work that changes a checkout, such as creating a worktree, adopting one, merging one into the project, or deleting a scope, runs as a job rather than a dialog you have to sit through.
The job opens a panel that lists its steps, and the panel can be minimized to a chip that still names what it is doing. While it runs, the panel says you can keep working and that the run continues in the background. When it finishes, it states the outcome where you can read it: the branch and folder it created, where the commits landed, or the checkout it removed.
A job that fails is not a dead end. The panel names what stopped it and offers the repair or the retry that resolves it, and the chip stays until you dismiss it.
Coming back to long work
There are two ways back in, and both are one action. Open the entry on the bell and you land where the work stopped. Restore the docked job and you see what it is doing or what it did.
Neither asks you to remember where you were. The bell names the thread, the job names itself, and the view you left is still holding your place.