Active Memory plugin incompatible with third-party memory plugins — tied to stock memory-core only

Summary

The active-memory plugin only works with the stock @openclaw/memory-core plugin's tools (memory_search, memory_get). When a third-party memory plugin (such as a custom ChromaDB-based memory service or a personal knowledge base) registers the same tool names, the active-memory sub-agent cannot use them because the embedded agent runs in a lightweight context that does not load third-party plugins.

This severely limits the active-memory feature's usefulness for anyone using custom memory backends or third-party memory/knowledge plugins.

Environment

• OpenClaw version: 2026.5.12
• Platform: Linux x64
• Memory backend: Custom plugin (openclaw-memory-v2, ChromaDB-based with 450+ vectors)
• Stock plugin: @openclaw/memory-core (enabled but SQLite DB empty)

Expected Behavior

Active memory should work with any plugin that registers the standard memory tools (memory_search, memory_get, memory_recall, etc.), including:

• Third-party memory plugins
• Custom memory backends (ChromaDB, Weaviate, Pinecone, etc.)
• Personal/local knowledge bases
• Hybrid setups using both stock and custom memory

Actual Behavior

The active-memory sub-agent consistently times out with the error:

No callable tools remain after resolving explicit tool allowlist
(runtime toolsAllow: memory_search, memory_stats)
-> no registered tools matched
Fix the allowlist or enable the plugin that registers the requested tool.

The sub-agent cannot find or call memory_search because the third-party plugin that registers it is not loaded in the embedded agent's isolated context.

Root Cause

Looking at the active-memory source code (dist/extensions/active-memory/index.js), the sub-agent is spawned with:

const result = await params.api.runtime.agent.runEmbeddedPiAgent({
    toolsAllow: [...params.config.toolsAllow],  // ["memory_search", "memory_stats"]
    bootstrapContextMode: "lightweight",
    ...
});

The bootstrapContextMode: "lightweight" means the embedded agent does not load third-party plugins. The toolsAllow restricts the agent to only memory_search and memory_stats, but if neither is registered in this isolated context, no tools are available.

In contrast, the main agent session loads all enabled plugins — so memory_search from a third-party plugin is available there. The sub-agent simply inherits the tool allowlist but not the actual tool registrations.

For memory-core (stock SQLite-based), this works because memory_search is registered as a built-in tool by the OpenClaw runtime itself, not through a third-party plugin. But for any plugin-registered tool, the sub-agent cannot access it.

Impact

This means:

1. Custom memory backends are unusable with active-memory — A user who built a ChromaDB-backed memory plugin (or any custom backend) cannot use active-memory's proactive recall features.

2. Knowledge base plugins are excluded — Any plugin that provides a searchable knowledge base (wiki, document store, codebase index) cannot be leveraged by active-memory.

3. Fragmentation of the ecosystem — Users are forced to choose between active-memory + basic SQLite, or custom memory + no proactive recall. This discourages community innovation around memory plugins.

4. No benefit from invested effort — Organizations that have invested in building custom memory infrastructure (vector databases, knowledge graphs, etc.) cannot benefit from active-memory's features.

Suggestion

One or more of the following approaches could resolve this:

Approach 1: Allow active-memory to use the main agent's tool context

Instead of creating an isolated lightweight sub-agent, the active-memory could run in the parent agent's existing tool context, inheriting all registered tools from enabled plugins. This way, memory_search from any plugin would be available.

Approach 2: Plugin-aware tool allowlist resolution

When the active-memory sub-agent spawns, resolve toolsAllow against the PLUGIN tool registry (not just the built-in tool registry). If a plugin provides memory_search and memory_stats, the sub-agent should be able to use them.

Approach 3: Configurable tool registration for active-memory

Allow active-memory to specify which plugins' tools to make available in the sub-agent context, similar to:

{
  plugins: {
    entries: {
      "active-memory": {
        config: {
          pluginContexts: ["openclaw-memory-v2"], // load tools from this plugin
        },
      },
    },
  },
}

Approach 4: Generic memory search abstraction

Define a standardized memory search interface that any plugin can implement. Active-memory would call this abstract interface rather than being coupled to specific tool names. This is the most future-proof approach and would allow the community to build custom memory backends that work seamlessly with active-memory.

Related

• Issue Feishu DM sessions not recovering after gateway restart (timing issue - session store loaded after lock cleanup) #82974: Feishu session recovery timing (also discovered during the same investigation)
• Active-memory config: dist/extensions/active-memory/index.js lines 460, 1385-1399
• Embedded agent: runEmbeddedPiAgent with bootstrapContextMode: "lightweight"