Skip to content

Memory

CoeOS’s memory rests on a clear distinction between what the assistant remembers and what it consults.

  • Write = memory = the Vault (Karpathy wiki) — what the assistant remembers about you, evolving, personal, per user.
  • Read = knowledge = RAG — the reference corpora you query (labour law, case law, a large case file), shared and static.

This split solves the core problem: a personal memory cannot live in a shared RAG without leaking between users. Memory therefore goes to the Vault (isolated per user), knowledge to RAG (a shared reference, read-only).

LevelContentWhereMechanism
Userwhat the assistant remembers about you, compiled from your conversationsVault (Karpathy wiki), per userwrite
Projectdurable notes for a caseVault (coming, via manual injection — to avoid mixing personal notes into a project)write
Company / knowledgereference corpora (labour law, case law, case files)RAG (LightRAG)read

The user level is active; the project write level is deliberately left as manual injection (a product decision) to prevent personal content from ending up in a shared project.

2. The Vault — the Karpathy wiki (write)

Section titled “2. The Vault — the Karpathy wiki (write)”

The Vault is a personal wiki that the system compiles automatically from your conversations.

  • Per user, no leakage: each note is bound to the user; isolation is guaranteed at the data level. No one sees another’s memory.
  • Compiled, not raw: a compiler model distils conversations into durable wiki entries rather than ingesting messages verbatim.
  • Injected into context: on each conversation, the user’s wiki is injected into the system prompt (“what I know about you”), staying consistent across sessions.
  • Sync: automatic twice a day (+ on chat inactivity, + a “Remember now” button on demand). Compilation sweeps all new conversations since the last pass.
  • Compiler model: a cheap, editable cloud model (default z-ai/glm-5.3-flash via OpenRouter), changeable without redeploying the code.
  • Monitored: a health endpoint + an alert flag if compilation stops — so you never end up “memory-less” without knowing.

Technically, the Vault is served by a dedicated sidecar (thecompai-memory, the Karpathy compiler) that shares the app database and reads conversations to distil them — the app sends it only identifiers, never cleartext content over the network.

RAG (LightRAG) serves shared knowledge, read-only.

  • Multi-base: a registry of RAG bases (Settings › RAG databases) — declare as many as you want (labour law, criminal case law, a large file…), each toggle-able, testable (health), with a confidentiality label (open / confidential).
  • Semantic search: an embedder (bge-m3, dimension 1024) turns the question and documents into vectors to find relevant passages. The embedder at query time must be the same as at base construction (otherwise search is incoherent).
  • Attached to a project, read-only: you link a RAG base to a project (the picker on the Project page). That project’s conversations query that base. E.g. attach “criminal case law” to a file, or inject a large shared file and make it read-only for the team’s project.
  • Confidentiality (D25): one base = one label. The Guardian prevents mixing confidential and open in a single search.

Unlike the Vault (which the system writes on its own), a RAG base is populated by ingesting a corpus (via OdyRAG / LightRAG ingestion), then read. CoeOS may also write to a company base later — for now it is a corpus you inject, mostly read.

On each turn, CoeOS assembles context by combining the user’s wiki (Vault, “what I know about you”) and the company RAG / the project-linked base (the relevant reference passages). The chat model receives both alongside the question, then answers. The Vault makes it consistent over time; RAG gives it documentary material.

  • Memory (the Vault) is not in the confidentiality perimeter: it is isolated per user and serves as injected context. Confidentiality filtering applies to inference and user prompts (via the Guardian), not to stored memory. That is what makes it manageable.
  • RAG bases carry a label (open / confidential) and the Guardian guarantees a confidential base is not mixed with an open one.
  • For a demanding firm, the embedder can stay local (same bge-m3 model → portable bases), so no document text leaves at indexing time.

The Vault remembers (per user, a wiki compiled from your conversations, injected across sessions); RAG documents (reference corpora, semantic search, attached to a project, read-only). Two mechanisms, two roles — and a memory that, if it breaks, says so instead of silently vanishing.