OpenClaw’s plugin system exposes a
memory slot (plugins.slots.memory) that exactly one memory provider occupies at a time — see OpenClaw’s memory plugin docs for the current, canonical schema. A real sovseal plugin would need to implement OpenClaw’s memory-provider interface (it would expose memory_search/memory_get-style tools, not just proxy to @sovseal/mcp-server’s store_memory/recall_memory MCP tools directly) and call @sovseal/sdk’s store()/recall() underneath.Installation
Install@sovseal/sdk (the underlying calls a real sovseal-backed plugin would make):
Configuration (illustrative — see warning above)
To register asovseal-memory plugin in OpenClaw, you would modify your agent’s configuration file (~/.openclaw/config.json) along these lines:
How it Would Affect the Planning Loop
Once a real sovseal memory plugin exists, integrating local memory would alter OpenClaw’s core execution loop in three key ways:- Context-Aware Initialization: Before commencing a task, the agent queries
recall_memoryto check for past execution attempts, known file structures, and deprecated functions in the workspace. - Dynamic Skill Loading: Based on retrieved memories, OpenClaw dynamically selects which helper tools to load, reducing LLM token budget waste.
- Automatic Fact Extraction: Upon task completion, the agent calls
store_memoryto write the lessons learned to the local LanceDB store, ensuring state continuity for subsequent runs.