Two tiers
| Tier | Use for | Where to find it |
|---|---|---|
| Project memory (this project) | Errata, design decisions, and quirks specific to this board or codebase. | Platform: Project Settings → Memory CLI: /memory to view, /remember to add |
| Organization memory (whole org) | Team-wide conventions, toolchain preferences, how Seb should behave. | Platform: Profile → Memory CLI: /memory to view |
How facts get saved
- Seb saves project memory automatically as it works — when it learns something durable, it writes it to project memory.
- Organization memory needs your approval. When Seb proposes an org-wide fact, a confirmation chip appears in chat; nothing is saved until you approve it.
- You can add facts yourself — in the CLI with
/remember <fact>(project memory), or by editing organization memory directly in Profile → Memory.
/memory in the CLI (org memory + project memory), or in the Platform — project memory under Project Settings → Memory, organization memory under Profile → Memory.
Isolated projects
Project owners can mark a project memory-isolated in project settings. On an isolated project, Seb’s project memory still works, but nothing is ever promoted to organization memory — use it for NDA-bound, export-controlled (ITAR/EAR), or per-client work where facts must not leak across the org.Guardrails
- Secrets are refused. Writes containing key material, private keys, tokens, or verbatim code/file contents are rejected — keep memory at the level of facts and conventions, not data.
- Size cap. Each store is capped (~32k characters); prune stale entries before adding more.
- Audited. Every write is logged with who wrote it and when, for org oversight.
See also
- Slash commands —
/remember,/memory - Guide → 3. Run agents

