Skip to main content
Roomote agents are the product’s core abstraction. A teammate gives an agent an outcome, the agent answers directly or delegates execution, and Roomote keeps the conversation, evidence, and follow-up connected. The same agent can help with a question in one turn, a plan in the next, and an implementation task after that. Roomote does not split these capabilities into selectable agent identities. Planning, coding, explanation, review, and conflict resolution are workflows or behavior modes that an agent can use for the current request.

​
The product model

Keep four parts of a request distinct when you decide how to use Roomote: The surface is the interaction channel, not a different product. The workflow is the work being requested, not a permanent agent type. An environment controls repositories, services, variables, and sandbox setup; it does not decide what the agent should do.

​
Where Roomote fits

Use a session when the work benefits from conversation, clarification, or a shared trail of decisions. A session may answer directly or delegate one or more tasks. Use a task when you need an independently controllable execution with a terminal, logs, diff, preview, or artifacts. The task reports back to its owning session when one exists. Use automations when the same prompt or event should create repeatable work without a teammate starting each run. Automations still create ordinary sessions and tasks, so the review path stays the same.

​
Good asks

Start with work that is scoped, visible, and easy to verify:
  • explain how a part of the codebase works
  • investigate a failing test, flaky preview, or confusing error
  • make a small UI or API change
  • draft a plan for a larger feature
  • review a pull request for regressions
  • apply feedback from a source-control or Linear thread
  • clean up a small maintenance item that keeps falling off the backlog
A good Roomote prompt includes the desired outcome, links to the relevant issue or pull request, and any constraints Roomote should respect.

​
What to include in the ask

The strongest prompts usually include:
  • the outcome you want and the first milestone that would prove progress
  • the repository, environment, file path, issue, or PR Roomote should use
  • any constraints that matter, such as “do not change the API contract”
  • whether you want an explanation, a plan, implementation work, or review
  • the evidence or delivery path you expect, such as a test result, diff, preview, or pull request

​
Ask patterns that work well

​
Who uses it

Roomote is meant for the whole team, not just engineers sitting in an IDE.

​
What makes a task reviewable

Roomote should leave you with enough evidence to decide what happens next:
  • the transcript of what it did and why
  • commands, tests, or checks it ran
  • logs and terminal output when relevant
  • screenshots or live previews for UI work
  • code diffs and artifacts
  • a pull request or clear next step when code changed

​
When to keep the task smaller

Break work down when the ask spans many systems, has unclear product requirements, or needs human judgment before implementation. Roomote is useful for getting complex work started, but the best handoffs still give it a clear first milestone.