A developer may ask Genesis Assistant to inspect a failed task, leave to review the changes, and return with a follow-up. That sequence depends on finding the conversation and keeping enough context to continue it. Changes merged into Genesis main on November 10–12, 2026 give Assistant conversations a persistent interactive session during their lifetime and move the conversation list into the dashboard sidebar. Assistant guide
Editorial illustration of resuming an Assistant conversation and reviewing a proposed action.
Return to a waiting conversation
Open Conversations beneath Active Tasks. The list shows the selected node’s live sessions alongside locally cached chats. The status labels distinguish a session waiting for input, one running, and one that has ended. Selecting a conversation opens it at /assistant?session=<agent_id>. Older /help links redirect to /assistant with their query string preserved. Route change
The session can yield after an exchange. While it waits for input, it releases its execution slot and retains its context and worktree. A follow-up resumes the same agent session with the same prompt-cache identity. New chat starts a separate conversation and leaves the previous one in the list. An ended chat can still appear as history. Session implementation
Inspect the task before deciding what to change
Consider a failed test task. Ask the Assistant to read its status, error and result on the node you are viewing. Then open the review page, compare the diff with the failure and return through Conversations with a narrower question. The existing conversation provides the context for that follow-up. On a local instance, download the Genesis source when prompted so the Assistant can consult its checkout.
If the next step is a retry, ask the Assistant to propose starting a new task using the earlier task as context. The inspection uses the read tier, while starting work uses a write call. The write needs a decision about the specific call on the selected node. Task inspection and execution tiers
Review the proposed write without losing your place
A fixed strip between the transcript and composer shows when requests are pending. Review opens a dialog with one request at a time. Check the exact code and execution target, then choose Allow once or Deny. Requests in the sudo tier carry a prominent warning because they run native Elixir under the Genesis server’s identity.
The dialog now reads the target node stamped by the runtime and displays any warning attached to the request. When several requests are queued, the review steps through them. A recovered request can be shown while it remains pending. The transcript and composer keep their positions as the strip changes, so reviewing an action need not displace the conversation you were reading. Approval changes
Follow the result back to the task
After a write is accepted, inspect the resulting task and check its status before treating the work as finished. If the response was interrupted or the write timed out, check current state before asking for a second write. To try the interaction on a build containing these changes, start with a read-only task inspection, switch to another dashboard page, and return through Conversations for the follow-up. The previous Assistant overview describes the operator tools this session flow builds on. Current Assistant guide