Assistants live on a rail view of their own, apart from your project threads. Work that runs without you needs its own room, because it should not mix with the work you are doing by hand.
What an assistant is
An assistant takes something off your hands for good and remembers what you tell it. It holds four things: the knowledge it follows on every run, the connections it works through, the models it runs on, and the way it reports back to you.
A task is one piece of work inside an assistant. One assistant can hold several tasks, and each has its own conversation with it. Tasks also exist without an assistant: New task in the header creates one on its own.
The setup conversation
A new assistant opens its first conversation, called Getting started. It asks what it needs one thing at a time: the name you give it, how you want it to behave, the work you want it to take on, whether it should run on a clock and what you call that clock and how often, and everything it needs in order to run.
Each answer comes back in one short line before the next question, so you can see that the two of you agree. The answers become the assistant's knowledge, which is what every run reads. When the setup is finished the assistant presents a recap and writes the knowledge down, and any section of it can be edited later.
If you would rather fill in a form, New assistant asks for a name and a personality, and whether it runs on a schedule, and offers a way to let the assistant ask the questions instead.
Runs on a clock, or on demand
Run on a schedule is a switch, on by default. An assistant with it turned off runs only when you ask, and every surface says so: its row reads Runs on demand in place of a cadence, and the Skip next run items are hidden because there is nothing to skip.
The clock is per task as well. A task row shows its state and reveals a calendar toggle on hover, so one task can fire on the assistant's cadence while another waits for you. A task you create by hand starts on demand.
Run now sits in the assistant panel and dispatches its tasks immediately, whatever the schedule and pause state say. Under it are Last run and Last success, which is how you check an assistant before its next fire.
What a run reports
Every run happens on a fresh thread of its own. A run never lands in the task's conversation, so the transcript you read afterwards holds exactly that execution and nothing else. The sidebar lists each task's runs beneath it.
A run reports in the shape you agreed during setup. An assistant that reports in the app writes the report as its message and leads with what needs attention, and it moves the urgency bracket when what it found turned out to matter more or less than the agreed default. An assistant that reports somewhere else, through a connection you set up, delivers there instead of dropping the report.
Where the report lands
The report is the run thread's own message, and that thread sits in the sidebar under its assistant. The run also raises its own entry on the Assistants tab of the notification panel, named after the task or the assistant rather than the space it lives in, so a finished run reads as what finished and whose it is.
The bell wears the assistant's colour for anything waiting from it, so a glance says which part of the app is asking for you. A failed run reads as an error in the error colour instead.
The transcript is not the only copy. Every task turn that settles with a report leaves a Markdown file under the assistant's workspace, which the Workspace files panel mounts, with the run time, the status, the task, and the agreed urgency above the answer. That copy outlives the thread.
A run that was missed
The schedule only fires while the app is running. A slot that came due while it was closed is not run later on its own; it appears as a missed run instead, on the assistant's Issues tab, on the assistant's row, and in the Missed Runs section of the notification panel, each with Dismiss and Run now.
An entry states why the fire did not run, so it never claims the app was closed when the machine was simply asleep. While you were away lists the recent runs that happened without you, with what came of each and how many questions it settled on your behalf.
Opening a run again
Pick the run under its task in the sidebar and you are back in the transcript, with the report where it landed. A notification entry opens the same place, and so does the Run history list in the assistant's panel. A run whose thread was later deleted still shows in that history as evidence, though there is nothing left to open.
You can write to a run thread like any other thread. It has its own title, model, and history, and it can be renamed or pinned afterwards.
Changing an assistant later
The panel is where an assistant is changed, in tabs. The Assistant tab holds the knowledge, split into sections you edit one at a time. Connections lists what the assistant uses, with Ready or Needs setup on each row, and adding one opens a searchable library. Agents holds the primary model and any fallbacks, in the order a run tries them. Reporting holds where the output goes and how urgent it is, as two brackets: when it matters and who it affects.
Edit assistant changes the name, the personality, the appearance, and whether it runs on a schedule.
Nothing you change applies backwards. The next run reads the knowledge, the connections, and the report agreement as they stand when it starts.