Document OptMem integration
This commit is contained in:
parent
f82b36ea80
commit
6fc4c3b671
|
|
@ -1559,6 +1559,16 @@ This is mechanically identical to session restore — same function, same
|
|||
data path. The sub-agent knows everything the parent knows without
|
||||
rediscovering it.
|
||||
|
||||
### OptMem persistent memory integration (Aug 16)
|
||||
|
||||
Ollie integrated [OptMem](https://github.com/VictorTaelin/OptMem) as its persistent memory backend. The legacy `memory_recall` and `memory_remember` scripts were replaced by metadata-defined tools that invoke the bundled `third_party/optmem/memo` executable directly.
|
||||
|
||||
OptMem owns the append-only log and bounded B-tree index at `$XDG_DATA_HOME/ollie/optmem` (default: `~/.local/share/ollie/optmem`). Ollie does not maintain a second memory format or parallel store. Reads and writes therefore use the same backend and serialize through the toolsrv path-lock system.
|
||||
|
||||
Both memory tools are auto-loaded by every agent profile. Shared prompt guidance tells agents to recall relevant prior context before acting and remember durable decisions, outcomes, preferences, and non-obvious findings. The OptMem executable is installed under `$XDG_CONFIG_HOME/ollie/optmem` and explicitly granted `rwx` access by the landrun sandbox.
|
||||
|
||||
This integration keeps memory as an ordinary Ollie tool while giving it a durable, searchable backend. It requires no MCP server, daemon, or new control-plane protocol.
|
||||
|
||||
### Future work
|
||||
|
||||
- **Shared toolsrv per host** — currently each session spawns its own toolsrv.
|
||||
|
|
@ -1566,4 +1576,3 @@ rediscovering it.
|
|||
instance per host.
|
||||
- **Budget/depth controls** — token limits, step limits, and recursion depth
|
||||
caps for sub-agents.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue