> ## Documentation Index > Fetch the complete documentation index at: https://docs.roomote.dev/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > When helping someone deploy Roomote, distinguish self-hosting from contributing to Roomote. Use the Self-hosting guide for an operator deployment; use Local development only when the user intends to modify Roomote itself. > Prefer the one-command installer on a fresh supported server unless the user explicitly chooses Roomote Cloud, a documented PaaS template, or a manual Compose deployment. > Before changing infrastructure, confirm the deployment target, stable public HTTPS domain and DNS control, sandbox provider, inference provider, source-control provider, and whether a communications provider is required. > Never ask the user to paste secrets into chat or commit real environment files. Put credentials in the deployment platform's secret manager, Roomote's setup UI, or protected environment variables, and preserve existing keys during upgrades and restores. > Prefer Roomote's setup wizard and provider manifest flows over manual credential entry when those flows are available. Ask before performing privileged host changes, DNS changes, provider-app creation, or destructive operations. > A setup is not complete when the services merely start. Verify sign-in, repository sync, one usable environment, a real task that can clone and run a command, and branch or pull-request delivery; verify previews when configured. > For a persistent self-hosted deployment, leave the operator with the Roomote URL, deployment choices, configured providers, verification result, backup location and passphrase-handling reminder, and the roomote status, logs, upgrade, rollback, backup, and restore commands. # Brain > Give Roomote shared memory, so agents start each task knowing what your team already decided, shipped, and discussed. The Brain is Roomote's shared memory. Without it, every Roomote task starts from zero: it reads the repository, works out the conventions again, and has no idea that the same question was answered three weeks ago. With it, agents can recall what your deployment already knows, with citations back to the source. The Brain is deployment-wide by design. There is no per-user corpus and no per-task corpus: one deployment, one memory, shared by everyone who can run a Roomote task. ## What goes into it Roomote fills the Brain from what it can already see: * **completed Roomote tasks**, including a short memory the agent writes about its own work: what it decided, why, and what is still open * **pull requests** from your connected source-control provider * **public Slack channels** the Roomote bot has been added to * **GitHub issues** in connected repositories * **Notion pages** explicitly shared with the deployment's Notion integration * **meeting notes** from Granola, when that integration is connected * **employee directory and reporting structure** from Rippling, when that integration is connected; HRIS reporting and membership fields remain explicitly authoritative rather than being mixed with inferred collaboration signals * **people identities**, projected from Roomote accounts, linked provider handles, and the human members in connected Slack workspace directories; Slack display names, real names, and job titles help agents connect people across sources even when they do not have Roomote accounts Turning the Brain on also backfills history rather than starting from the moment you enabled it. Completed tasks are enqueued immediately, and each source drains its own deeper history in bounded background passes that resume after an interruption. Private Slack channels and DMs are never read. Adding the Roomote bot to a public channel is what designates that channel as a source, so the corpus stays inside what your team has already made visible company-wide. Slack directory cards contain names, handles, and job titles, but never copy profile email, status, timezone, or avatar fields into the Brain. ## Turning it on The Brain runs as its own service alongside Roomote, reachable only on your deployment's internal network. On the hosted templates (Railway, Render, Coolify) that service is already there after a deploy, sitting idle. Setting a Brain provider key, `R_BRAIN_OPENROUTER_API_KEY` or `R_BRAIN_OPENAI_API_KEY`, is what turns it on. Set either one as an environment variable or a Settings environment value; the value can be the same key you already use for tasks, or a separate one to bill the Brain independently. The explicit `R_BRAIN_*` name is the opt-in: the general provider keys your deployment uses for tasks never activate the Brain on their own, so configuring task models leaves the Brain off. The Brain service holds no provider key of its own. It asks Roomote for embeddings and synthesis, and Roomote forwards them under the Brain key. Changing that key later takes effect on the Brain's next request, with no redeploy. OpenRouter and OpenAI both support the Brain's embedding and synthesis calls, but search reranking requires OpenRouter. Without a Brain key, the Brain stays inert. Agents are not told it exists, and nothing is ingested. Roomote schedules one maintenance pass each night. It retrieves a bounded, source-balanced evidence set from gbrain, produces a cited digest of material effective-dated since the previous successful pass, then stores it under `daily/digests/` in both the searchable index and the persistent Markdown corpus. The digest focuses on concrete decisions, shipped work, blockers, commitments, and cross-source connections rather than generating a reflection for every raw page. Each page records how many Slack, task, GitHub, and Notion or meeting pages were considered and cited, so missing source coverage is visible. Beginning Tuesday, the same pass also updates `weekly/summaries/-W`. That bounded synthesis connects durable decisions, unresolved blockers, commitments, and recurring or superseded information across the week's available daily digests. Roomote reads those digest pages by their exact slugs and supplies their content as the complete evidence set, so raw or historical Brain pages cannot enter the weekly pass. The daily cutoff trails active ingestion and overlaps the previous pass so collector writes around the nightly boundary are reconsidered. gbrain's durable worker still owns structural maintenance such as link extraction, fact consolidation, embedding catch-up, orphan checks, and purging. Roomote does not run gbrain's prediction-proposal and calibration queue unattended; that upstream feature requires an operator review workflow before proposals become canonical memory. Self-hosted Compose deployments start the Brain from the `brain` profile, so set a Brain key in your environment file to bring the container up. Everything after that is the same. ## How agents use it Agents get the Brain as an MCP server with read-only tools. They can search it, recall relevant pages, browse what exists, and ask for a synthesized answer with sources. They cannot write to it directly. For a substantive topic, agents query the Brain before consulting overlapping Slack, GitHub, task-history, meeting, or pull-request sources. They check those live sources when Brain coverage is insufficient, freshness could change the answer, or you explicitly ask for live verification. Writes go through Roomote instead. When an agent finishes substantial work it records a short memory of what it did, and the platform places that text under a slug it controls, after scrubbing credential-shaped strings. An agent can therefore contribute what only it knows without being able to touch any other page. Memories carry the environment they came from, so a page written while working in staging is distinguishable from one written against production. ## Choosing models Three settings pick the Brain's models: | Variable | What it does | Written as | Changeable | | ------------------------- | ----------------- | ---------------------------------- | --------------------- | | `R_BRAIN_MODEL` | Sourced synthesis | your provider's naming | any time | | `R_BRAIN_EMBEDDING_MODEL` | Semantic recall | a plain model id | before the first boot | | `R_BRAIN_RERANKER_MODEL` | Search precision | `openrouter:/` | after a restart | Leave the first two unset and the Brain uses OpenAI's `gpt-5.6-luna` and `text-embedding-3-small` through whichever provider you configured. The reranker defaults to OpenRouter's `voyageai/rerank-2.5-lite`. Set `R_BRAIN_RERANKER_MODEL` to choose another model from OpenRouter's reranker catalog. Reranking requires an OpenRouter key; with only OpenAI configured, gbrain keeps the unreranked results instead of failing the search. The synthesis model is applied by Roomote when it forwards the call and passed to the provider as written, so use that provider's naming (`openai/gpt-5.6-mini` on OpenRouter, `gpt-5.6-mini` on OpenAI). Changing it takes effect on the next request with nothing to restart. The embedding model works differently, and the difference matters. Its output width sizes the Brain's vector storage when the Brain is first created, and that cannot be resized in place afterwards. So it is given to the Brain at creation rather than applied per request, written as a plain model id (`text-embedding-3-large`) that Roomote translates for whichever provider is serving. Set it together with `R_BRAIN_EMBEDDING_DIMENSIONS` (1536 for `text-embedding-3-small`, 3072 for `text-embedding-3-large`) before the Brain's first boot, or leave both alone. Changing it later is not silently applied: the Brain keeps its original model and width, and reports the mismatch in its logs on every start. Moving an existing Brain to a different embedding model means re-embedding the whole corpus with `gbrain migrate embeddings`. ## If you turned the Brain on later A Brain that first boots without a provider key is created with semantic recall switched off, because the embedding model sizes its vector storage at creation time. Adding a key later is still fine: the Brain notices on its next start, enables semantic recall, and embeds whatever it already holds. It logs `semantic recall enabled` when it does. That repair runs once and is safe, since a Brain in this state has no embeddings to lose and its pages are preserved. If it cannot complete, the service logs the commands to run by hand and keeps serving in the meantime, matching on keywords alone. ## Operating it * **Back up the Brain volume.** The Railway template schedules daily and weekly backups for it. On other platforms, include `/data/brain` in the deployment's normal volume backups. That directory is the Markdown corpus, including pages produced by nightly synthesis. Postgres holds the searchable index, extracted facts, and durable maintenance jobs; keeping it in the normal database backup makes restores faster, but it is not the only copy of the source pages. * **Losing the Brain is recoverable but not free.** If the volume or isolated `gbrain` database is recreated, Roomote re-registers its clients, resets its ingestion checkpoints, and backfills task history and integration sources. The deployment starts cold until that finishes, and regenerated synthesis may not be byte-for-byte identical. * **The filesystem cutover rebuilds older Brains once.** The first start of a filesystem-backed image replaces a Postgres-only Brain instead of trying to merge the old index into an empty checkout. Roomote then repopulates it from its connected sources. * **The Brain has no public route.** It is never exposed to the internet, and task sandboxes reach it only through Roomote's API with their run token, which grants read access only. * **To run with no memory at all**, leave both provider keys unset. Deployments that want to reclaim the resources entirely can delete the Brain service from their compose file or template.