Memory

A naive bot would dump every past message into the next prompt. That burns through the model's context window in minutes and makes answers worse, not better. GolemCore avoids this by loading short summaries at the start of a turn and pulling full notes on demand only when the agent decides a note is relevant to what you just asked.

The result: the bot remembers a lot, but each turn starts with a tight, focused context.

Notes live in four buckets, sorted by how durable they are. You will see these names in the dashboard and in the glossary — they are useful when you want to know where a note ended up.

Inside each bucket, the bot tags notes with a category: decision, constraint, failure, fix, preference, project_fact, task_state, or command_result. You will see these tags if you inspect the notebook directly, but you do not configure them — the bot picks the right one when it writes the note.

Open Settings → Memory in the dashboard. The first thing you see is a preset picker. Pick one that matches how you use the bot — you can change it later without losing anything.

Use coding_balanced if you are enabling memory for the first time. It is the default for a reason: it writes carefully (so the notebook does not fill up with noise), reads enough at the start of each turn to be useful, and lets the bot pull more detail when it needs it.

Switch to coding_deep only if you notice the bot forgetting things mid-session that it should still know. Switch to coding_fast if the bot feels sluggish or you mostly run short, throwaway chats. Switch to research_analyst or ops_support when your work fits one of those shapes — they trade some general usefulness for being better at one thing.

Most operators never need to leave the preset picker. If you do, every parameter — token budgets, per-bucket top-K, promotion, decay, disclosure, reranking — is documented on its own page with the values each preset uses, so you can copy from the closest one and adjust.

See Memory Tuning for the full reference and a side-by-side preset comparison table.

Notes are saved as JSON Lines (.jsonl) files — one JSON object per line, appended over time. They live under the memory directory inside the workspace volume. The directory name is memory/ by default and can be overridden in Settings → Memory.

Notes that are not tied to a specific session, goal, or task — the “global” scope — live at the top of that directory. Notes attached to a session, goal, or task live in parallel trees under scopes/, each with the same items/… layout inside.

memory/
├── items/                              # global scope
│   ├── semantic.jsonl                  # long-term facts
│   ├── procedural.jsonl                # how-to notes
│   └── episodic/
│       └── <YYYY-MM-DD>.jsonl          # dated events, one file per day
└── scopes/
    ├── session/<channel>/<sessionId>/
    │   └── items/…                     # same three files, scoped to one session
    ├── goal/<…>/
    │   └── items/…                     # scoped to one goal
    └── task/<taskId>/
        └── items/…                     # scoped to one task

Restoring a notebook is a file copy: drop the directory back in place. The bot reads notes lazily on each turn through memory recall, so new files are picked up the next time memory is queried — no restart required.