openclaw - 💡(How to fix) Fix Multi-Slot Memory Architecture [1 comments, 2 participants]

Summary

Replace the single plugins.slots.memory slot with multiple purpose-specific memory slots, allowing different memory providers to handle distinct layers of the memory stack simultaneously.

Problem

OpenClaw currently supports exactly one plugin for the memory slot. Enabling any memory provider replaces whatever was there before. This forces users to choose a single solution for all memory concerns — factual recall, compaction, auto-capture, user modeling — even though these are fundamentally different problems solved by different tools.

Problem to solve

Allows users to take advantage of all the various useful Memory plug-ins for Openclaw. Currently, you can only have one memory plug-in. We currently have Memory-Core + QMD in that slot. There is a second slot we are also hi-jacking as a workaround, the plugin-slots.contextEngine slot is owned by Lossless Claw. Our 2nd Memory plug-in that solves a different problem. Then we had to manually build out a way to run Hindsight independently because it also did something we wanted for our agents memory. Today, we looked at adding Honcho. LOVE what it does, where do we put it? It tries to displace Memory-Core. Memory and memory management is the biggest problem Openclaw has and the 3rd Party community has done a great job creating solutions. Unfortunately, the underlying platfom makes adding them very complicated and a total one off!

Proposed solution

Introduce purpose-specific memory slots instead of a single generic one. Each slot handles a distinct concern in the memory lifecycle:

{
  "plugins": {
    "slots": {
      "memory.recall": "memory-core",
      "memory.compaction": "lossless-claw",
      "memory.capture": "hindsight",
      "memory.userModel": "openclaw-honcho"
    }
  }
}

Suggested slot taxonomy

Each slot would have its own hook points in the agent lifecycle:

• memory.recall → before_prompt_build (inject relevant context)
• memory.compaction → on_context_pressure (manage window)
• memory.capture → after_agent_reply (extract and store)
• memory.userModel → before_prompt_build (inject user profile/preferences)

Per-agent scoping

Each slot should be configurable at the agent level, not just globally:

{
  "agents": {
    "list": {
      "nancy": {
        "plugins": {
          "slots": {
            "memory.userModel": "openclaw-honcho"
          }
        }
      }
    }
  }
}

This allows testing a new memory provider on a single agent without affecting production agents.

Alternatives considered

No response

Impact

e run a multi-agent OpenClaw deployment with four memory-related tools. Getting three of them running simultaneously required workarounds — only one is actually using the memory slot as designed:

Honcho's user modeling capability tested well in isolation (9/10 on implicit preference detection, low false inference rate, strong preference drift tracking). But enabling the Honcho plugin replaces memory-core globally — there is no userModel slot for it to occupy alongside memory-core. The same problem occurred with ByteRover — enabling it displaced memory-core.

The system currently supports one memory plugin by design. We have three memory tools running only because two of them found workarounds (different slot, sidecar process). A fourth tool with genuine value — Honcho — cannot join the stack at all because there is nowhere to put it.

The result: genuinely useful tools cannot be composed because they compete for a single slot instead of complementing each other.

Evidence/examples

Memory is the differentiator between a stateful agent and a chatbot. The ecosystem is producing genuinely capable memory tools — Honcho for user modeling, Hindsight for auto-capture, various vector stores for semantic recall — but they can't be composed because they all compete for one slot.

The current architecture forces an all-or-nothing choice. A layered architecture lets each tool do what it's best at.

Backward Compatibility

• The existing plugins.slots.memory key could continue to work as a shorthand that populates memory.recall (or all sub-slots), preserving existing configs.
• Plugins that currently register as memory providers would default to the memory.recall slot unless they declare a more specific slot.
• No breaking change required if the single-slot path remains valid as a fallback.

Additional Context

• Tested on OpenClaw 2026.4.2 with a 5-agent deployment
• Honcho evaluation report available showing strong inference quality (9/10) but integration rated 3/10 due to slot exclusivity
• Same architectural limitation blocked ByteRover integration earlier
• Lossless Claw works around this by using the contextEngine slot instead of memory, but that's a workaround, not a solution
• Hindsight runs as a sidecar LaunchAgent — also a workaround

Environment

• OpenClaw 2026.4.2
• macOS (Apple Silicon)
• Multi-agent deployment (5 agents)
• Memory stack: memory-core + Lossless Claw + Hindsight (production), Honcho (evaluated, cannot integrate)

Additional information

No response