Memory

Sidebar → Memory Profiles (under Tasks), then enable it per-agent in the agent edit page → Memory.

Memory is the agent's automatic long-term memory. After each conversation, a background Selector reviews the full memory catalog for relevant entries, then the MemoryLLM reads those entries' complete bodies and applies final changes. On later turns the agent reads memories back via the search_memory and read_memory tools.

Think of it as the agent learning from every conversation without you having to teach it explicitly — and without bloating the system prompt.

How It Works

1. Select — after a conversation idles, the selector model matches the transcript against self-contained titles from every global + current-workspace entry. It uses one request while the title catalog fits its budget; for oversized catalogs it compresses the transcript once and matches titles in batches. The Selector never reads bodies. If no selector is configured, the writer model performs this step.
2. Extract — the writer model reads the selected entries' complete bodies together with the conversation, then creates, updates, removes, or leaves memories unchanged.
3. Read — on subsequent turns the agent calls:
   • search_memory — BM25 keyword lookup across stored memories
   • read_memory — fetch the full body of a memory by its slug
4. Maintain — background jobs keep the store healthy:
   • Consolidate — merges and de-duplicates related memories
   • Reconcile — re-indexes and prunes stale entries
5. Delete — removed memories are moved to .archive/ and can be recovered.

Global and Workspace Memory

One Memory Profile contains two memory layers:

• Global — user preferences, machine context, and general workflows that apply across projects.
• Workspace — project paths, conventions, module maps, build steps, and architecture decisions isolated by the current workPath.

A channel still selects only one Memory Profile. Each turn reads global memory together with the current workspace memory. Different workPath values use separate databases and search indexes, so they cannot search or write one another's entries. Sessions without a configured workPath, including ordinary Web conversations, share ~/.sbot/workspace as their default memory workspace instead of writing everything into global memory. The Memory Profile viewer can switch between global memory and previously created workspaces.

Configuration

A Memory Profile defines how memories are extracted and read. Sidebar → Memory Profiles → New:

Field	Description
Name	Display name for this profile
Enabled	Pause the profile without deleting it
Writer Model	The authoritative MemoryLLM that reads selected full bodies and applies final changes
Selector Model	Optional cheaper model that screens the complete catalog; defaults to Writer Model
Writer Prompt	Controls what gets extracted
Read Prompt	How retrieved memories are formatted back into the prompt

Then, in an agent → Memory section, toggle Memory on and pick the profile. From the Memory Profiles page you can View Memories, inspect pending/failed background jobs, retry or delete any failed job, queue Clean Up Memories, and use Sync File Index to rescan files and indexes.

Memory vs Notes vs Wiki

	Who writes?	When written?
Memory	Background MemoryLLM	After the conversation idles, automatically
Notes	Humans / operators	Manually, then recalled automatically or via note_search
Wiki	Humans / wiki source plugins	Curated pages, then searched/read by agents

Memory is the most "set and forget" of the three.