Memory

Memory 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. Memory 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 Memory 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. When the Notion integration can list workspace users, verified Notion email addresses link those identities to matching Roomote members; users without a visible, verified email remain separate identities rather than being matched by name

Pull-request memories retain the context agents need to answer more than whether a change merged. Pages include the PR description and labels, the files and leading code areas it changed, available line totals, and review outcomes. That lets searches connect a decision to why it was made, which part of the codebase it affected, and who reviewed it. Descriptions are bounded and treated as source evidence rather than agent instructions; large file lists are summarized with a count and truncation marker so the page stays useful without becoming unbounded. Descriptions and labels come from the normal provider sync. File and review details require additional provider requests, so Roomote enriches a bounded set of pull requests during each hourly analytics pass, prioritizing merged work. Older pages gain this context progressively as the sync reaches them. Turning Memory 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 Memory. Notion only returns pages explicitly shared with its integration. Workspace guests and restricted users may omit email addresses, and some integration configurations cannot list users at all. Roomote still keeps stable Notion user references in page snapshots in those cases, but it does not guess a match from the display name. The workspace user directory is refreshed once a day; people removed from the workspace (or hidden when the integration loses its user-listing capability) have their Notion identity cards marked deleted on the next refresh.

​

Turning it on

Memory 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 Memory 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 Memory independently. The explicit R_BRAIN_* name is the opt-in: the general provider keys your deployment uses for tasks never activate Memory on their own, so configuring task models leaves Memory off. The Memory service holds no provider key of its own. It asks Roomote for embeddings and synthesis, and Roomote forwards them under the Memory key. Changing that key later takes effect on Memory’s next request, with no redeploy. OpenRouter and OpenAI both support Memory’s embedding and synthesis calls, but search reranking requires OpenRouter. Without a Memory key, Memory 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/<year>-W<week>. 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 Memory 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.

​

Seeing what it knows

Settings → Memory is the deployment-wide view of the memory, for admins. Memory issues appears first only when completed tasks are missing memories or memory writes exhausted their retries. Its repair actions queue missing memories and retry failed writes without bringing back the removed task-memory stats. Memory Stats breaks the corpus down by what each page came from, such as task memories, pull requests, Slack, meetings, and people, followed by a chart of the pages written over the last 30 days and the memories written most recently. Browser memories embeds the corpus page by page, searchable and filterable by source. Selecting a new memory opens it in the browser and updates the page URL without adding browser history. Status reports whether recall is semantic or keyword-only and which provider is serving its embeddings and synthesis. Memory that is running but has no provider key is called out as needing attention rather than shown as healthy: without one it can only match keywords, so recall would look real while missing everything semantic. Sources shows connected sources with their current collection state, when they were last read, and how far their one-time history sweep has got. Sources without a connected upstream integration are omitted. Configuration appears last and shows the synthesis model (changeable through R_BRAIN_MODEL, applied immediately) and the embedding model, which is fixed when Memory is created because it sizes the vector store.

​

How agents use it

Agents get Memory 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 Memory before consulting overlapping Slack, GitHub, task-history, meeting, or pull-request sources. They check those live sources when Memory 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 Memory’s models: Leave the first two unset and Memory 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.

​

If you turned Memory on later

Memory 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: Memory 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 Memory 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 Memory 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 Memory 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 memory once. The first start of a filesystem-backed image replaces a Postgres-only Memory service instead of trying to merge the old index into an empty checkout. Roomote then repopulates it from its connected sources.
• Memory has no public service 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 Memory service from their compose file or template.