What to check first
Before you dive into details, check the basics:- what Roomote was asked to do
- which environment or repository context it used
- whether the task is still running, needs input, or has finished
- whether Roomote used the expected model, source-control context, and compute environment when those details matter
- whether the end state matches the kind of outcome you wanted: answer, plan, patch, branch, or PR
Sessions and task status
Use the sessions page to scan shared work and filter it by lifecycle. Roomote places sessions in Active, Needs input, Blocked, or Ready from their current task, goal, and run state, so your team does not need to maintain a separate status field. Each session card shows its owner and participants, recent activity, delegated execution count, workspace or pull-request context, aggregate cost, and unread state. Use the Tasks scope when you only want sessions containing execution work.Attention notifications
When a manually started web session has a new response or its task needs input while the initiator is away, Roomote sends a personal notification. Automation and scheduled results do not send these attention notifications. The first notification quotes the initial request, includes Roomote’s response, and uses the standard session footer. When it needs a new provider thread, Roomote first tries the Slack, Teams, Telegram, or Discord platform the user most recently chose to start a task or session, then falls back through Slack, Teams, Telegram, Discord, and the user’s account email without retrying the preferred platform. Email verification is required for inbound requests and replies, not for receiving these notifications — and replying to one of these emails verifies the account address implicitly. Later notifications reuse that session’s successful provider thread when it remains available, and the standard footer moves to the latest supported message. Roomote skips the notification while the initiator is present in the session or has an active voice call there. When enabled by an administrator, Roomote first offers a desktop browser notification if the relevant session or task page is still open in a background or unfocused tab. Permission is requested contextually after the first eligible attention event and only after you select Enable notifications; Roomote does not ask during setup or first run. If the browser does not accept the notification within ten seconds, permission is denied or unsupported, or the page is closed, Roomote continues through the configured personal-provider waterfall. Browser delivery only replaces that extra attention copy: normal replies continue in the session or existing communication thread. Closed-page browser push is not supported. If you continue the conversation on the web and then leave again, the next notification in that same provider thread marks the messages that were not shown there. For gaps of up to four conversation messages, it also quotes the latest web request. Longer gaps link to the session instead of generating a summary or copying the omitted conversation. Presence changes alone do not add this marker, and a notification that starts a new provider thread still uses the original request quote. Reply directly to a notification in Slack, Teams, Telegram, Discord, or email to continue the same session. Use the provider’s reply action so Roomote can match the message to the session; a separate top-level message starts or continues that provider’s ordinary conversation instead. Direct task replies return to the notified task, while replies to session notifications keep the session’s existing context. If a Teams personal chat does not attach reply metadata, start the message withcontinue: to continue the most recent
attention notification from the past seven days.
Failed and canceled tasks retain a terminal notification fallback. Roomote
deduplicates delivery across task completion, retries, and parent-session reports.
Recover from a failed start
When a task cannot start, select Try in a new task to open an editable task launcher prefilled with the original text prompt, selected model, and linked environment. Review or change those values before starting it. This creates a new task instead of retrying the failed task, and attachments are not copied, so reattach any files the new task needs.Task view
The task view gives you the working context for a run:- a header breadcrumb linking back to the owning session (when you opened the workspace from a filtered sessions view, browser Back returns to that view)
- conversation history and Roomote updates
- inline widgets for structured tables, status cards, plans, and other presentational results an agent chooses to show
- terminal and runtime logs, including individual environment setup-command logs when setup is still running or needs troubleshooting
- generated artifacts
- code diffs
- Live Previews for running apps
- task metadata and links back to the surface that started the task
Native widget styling
Roomote widgets inherit the task view’s selected light or dark theme. Agents can use the built-inrw-card, rw-stack, rw-row, rw-grid, rw-stat,
rw-badge, rw-callout, and rw-muted classes for common layouts without
supplying custom CSS.
When a widget needs a custom layout, its CSS can use Roomote’s --rw-* theme
variables. The main variables are --rw-background, --rw-surface,
--rw-surface-muted, --rw-text, --rw-text-muted, --rw-border,
--rw-primary, --rw-accent, --rw-success, --rw-warning, and
--rw-danger. This keeps the result visually consistent with Roomote and lets
the same widget adapt when the viewer changes themes.
Widgets work best as compact visual summaries. Agents should keep labels and
datasets concise, choose a height that fits the expected content without
scrolling, and use normal task narration or an artifact for longer material.
Review the evidence
Roomote is most useful when it can show its work. For implementation tasks, look for:- commands, tests, or checks it ran
- logs or errors it used to make decisions
- screenshots, recordings, or live previews for UI changes
- a diff or pull request for code changes
- a clear explanation when something could not be verified
When an environment setup command fails, open the task Logs panel and
select its
Setup: <command> entry. The command’s output is available there
without needing to enter the sandbox workspace.
Continuing work
You can send follow-up instructions while a task is active. If a task has completed and Roomote has a restorable snapshot, a follow-up can resume from that prior workspace instead of starting over. Snapshot retention depends on the sandbox provider: Modal-backed snapshots do not have Roomote’s seven-day application expiry, while other providers may use a bounded window. When a task delegated from a session asks for input, reply naturally in the originating session. If one input request is pending, Roomote applies a matching reply to that request instead of treating it as a separate task instruction. For an objective that may need several agent turns, use Goal Mode. It keeps the complete outcome in context and can continue the task automatically within a bounded continuation budget. Good follow-ups are specific:- “Apply the second option and add a regression test.”
- “Use the existing settings card pattern instead of adding a new component.”
- “Open a PR with the fix.”
- “Explain the tradeoff before changing code.”
When to resume versus start a new task
- Resume the same task when the follow-up depends on the existing workspace, context, or unfinished implementation.
- Start a new task when the work is a separate objective, should use a different environment, or would make the current task thread too broad.