Summary
I'm running a multi-agent setup (7 agents) with memory-lancedb as my primary memory plugin. I also have a knowledge graph layer (Cognee) that provides graph-based retrieval — entity relationships, multi-hop reasoning across projects, and temporal context that vector search can't do.
The problem: cognee-openclaw declares kind: "memory", so it can't coexist with memory-lancedb. Only one loads per the slot system. This forces an all-or-nothing choice between vector memory (which my 27 cron jobs and daily operations depend on) and graph memory (which adds relationship-aware context that vector search misses).
What I'm requesting: A way to run a secondary memory plugin alongside the primary slot holder. Possible approaches:
A memoryAugment slot (or array of supplementary memory plugins) that runs before_agent_start recall alongside the primary, injecting additional context without replacing the primary plugin's memory_recall/memory_store tools
Per-agent plugin slot overrides — let individual agents choose their memory plugin while others keep the default (I see this was raised in #25359)
A new plugin kind like "memory-augment" that hooks into the recall/capture lifecycle but doesn't compete for the exclusive memory slot
Use case: LanceDB handles fast vector recall and the memory_recall/memory_store tools that agents use constantly. Cognee adds a knowledge graph layer that understands entity relationships (e.g., "this person audits this project, which has this compliance obligation, which depends on this other project's deliverable"). These are complementary, not competing — vector search finds similar text, graph search traverses connections.
Current workaround: Running Cognee as a standalone API server and querying it directly via exec tool, bypassing the plugin system entirely. This works but loses the auto-recall/auto-capture lifecycle hooks that make memory plugins valuable.
Related: mem0ai/mem0#4126 describes the same constraint from the Mem0 side, and references #25359 for per-agent slots.
Happy to test any experimental approach if you want to prototype this.
Problem to solve
The plugins.slots.memory system only allows one kind: "memory" plugin to load. This forces users to choose between their primary memory plugin (e.g., memory-lancedb for vector recall/capture) and supplementary memory plugins (e.g., cognee-openclaw for knowledge graph retrieval). There's no way to run both — the second plugin is silently disabled. For multi-agent setups that depend on the primary memory plugin's tools (memory_recall, memory_store) across cron jobs and daily operations, switching the slot to a graph-based plugin isn't viable. But the graph plugin's relationship-aware context is genuinely additive and doesn't conflict with vector search. The current architecture treats complementary memory systems as mutually exclusive.
Proposed solution
Support a supplementary memory plugin layer that runs alongside the primary memory slot. Three possible approaches (any would solve this):
A plugins.slots.memoryAugment slot (or array) that loads additional kind: "memory" plugins for recall injection without competing for the primary slot
A new plugin kind ("memory-augment") that hooks into before_agent_start and agent_end lifecycle events but doesn't register memory_recall/memory_store tools or claim the memory slot
Per-agent slot overrides (ref #25359) so individual agents can use a different memory plugin while others keep the default
The key constraint: the primary plugin's tools and auto-capture must remain unaffected. The supplementary plugin only injects additional context during recall.
Alternatives considered
Switching the memory slot to the graph plugin: Breaks all existing operations that depend on memory_recall/memory_store from the primary plugin. Not viable for production setups with cron jobs and multi-agent workflows.
Running the graph engine as a standalone API server and querying via exec tool: This is our current workaround. It works but loses the auto-recall/auto-capture lifecycle hooks, requiring manual query calls instead of automatic context injection.
Patching the plugin source to declare a different kind: Hacky, breaks on updates, and the framework doesn't have lifecycle hooks for arbitrary plugin kinds.
Using context-engine slot instead: Context engine plugins own the full session context pipeline — too broad for a supplementary memory layer that just needs to inject additional recall results.
Impact
Affected users: Anyone running a knowledge graph memory plugin (Cognee, Mem0, Graphiti) alongside LanceDB or memory-core in a multi-agent setup. This also affects the Mem0 community (see mem0ai/mem0#4126 — same constraint reported independently).
Severity: Blocks workflow. The graph plugin either replaces the primary memory entirely (breaking existing operations) or can't load at all. There's no middle ground within the plugin system.
Frequency: Always. Every gateway restart, every session start — the second memory plugin is silently disabled. This isn't intermittent; it's a hard architectural constraint.
Consequence: Users who need both vector recall and graph recall are forced outside the plugin system entirely — running standalone API servers, writing custom exec tool wrappers, and manually triggering queries that should be handled by auto-recall lifecycle hooks. This adds infrastructure overhead (a persistent server process consuming ~2GB RAM in our case), eliminates auto-capture, and means graph context is only available when the agent explicitly calls a tool rather than being injected automatically before every turn. The practical result: the knowledge graph investment delivers a fraction of its value because it's disconnected from the memory lifecycle.
Evidence/examples
No response
Additional information
No response
Summary
I'm running a multi-agent setup (7 agents) with memory-lancedb as my primary memory plugin. I also have a knowledge graph layer (Cognee) that provides graph-based retrieval — entity relationships, multi-hop reasoning across projects, and temporal context that vector search can't do.
The problem: cognee-openclaw declares kind: "memory", so it can't coexist with memory-lancedb. Only one loads per the slot system. This forces an all-or-nothing choice between vector memory (which my 27 cron jobs and daily operations depend on) and graph memory (which adds relationship-aware context that vector search misses).
What I'm requesting: A way to run a secondary memory plugin alongside the primary slot holder. Possible approaches:
A memoryAugment slot (or array of supplementary memory plugins) that runs before_agent_start recall alongside the primary, injecting additional context without replacing the primary plugin's memory_recall/memory_store tools
Per-agent plugin slot overrides — let individual agents choose their memory plugin while others keep the default (I see this was raised in #25359)
A new plugin kind like "memory-augment" that hooks into the recall/capture lifecycle but doesn't compete for the exclusive memory slot
Use case: LanceDB handles fast vector recall and the memory_recall/memory_store tools that agents use constantly. Cognee adds a knowledge graph layer that understands entity relationships (e.g., "this person audits this project, which has this compliance obligation, which depends on this other project's deliverable"). These are complementary, not competing — vector search finds similar text, graph search traverses connections.
Current workaround: Running Cognee as a standalone API server and querying it directly via exec tool, bypassing the plugin system entirely. This works but loses the auto-recall/auto-capture lifecycle hooks that make memory plugins valuable.
Related: mem0ai/mem0#4126 describes the same constraint from the Mem0 side, and references #25359 for per-agent slots.
Happy to test any experimental approach if you want to prototype this.
Problem to solve
The plugins.slots.memory system only allows one kind: "memory" plugin to load. This forces users to choose between their primary memory plugin (e.g., memory-lancedb for vector recall/capture) and supplementary memory plugins (e.g., cognee-openclaw for knowledge graph retrieval). There's no way to run both — the second plugin is silently disabled. For multi-agent setups that depend on the primary memory plugin's tools (memory_recall, memory_store) across cron jobs and daily operations, switching the slot to a graph-based plugin isn't viable. But the graph plugin's relationship-aware context is genuinely additive and doesn't conflict with vector search. The current architecture treats complementary memory systems as mutually exclusive.
Proposed solution
Support a supplementary memory plugin layer that runs alongside the primary memory slot. Three possible approaches (any would solve this):
A plugins.slots.memoryAugment slot (or array) that loads additional kind: "memory" plugins for recall injection without competing for the primary slot
A new plugin kind ("memory-augment") that hooks into before_agent_start and agent_end lifecycle events but doesn't register memory_recall/memory_store tools or claim the memory slot
Per-agent slot overrides (ref #25359) so individual agents can use a different memory plugin while others keep the default
The key constraint: the primary plugin's tools and auto-capture must remain unaffected. The supplementary plugin only injects additional context during recall.
Alternatives considered
Switching the memory slot to the graph plugin: Breaks all existing operations that depend on memory_recall/memory_store from the primary plugin. Not viable for production setups with cron jobs and multi-agent workflows.
Running the graph engine as a standalone API server and querying via exec tool: This is our current workaround. It works but loses the auto-recall/auto-capture lifecycle hooks, requiring manual query calls instead of automatic context injection.
Patching the plugin source to declare a different kind: Hacky, breaks on updates, and the framework doesn't have lifecycle hooks for arbitrary plugin kinds.
Using context-engine slot instead: Context engine plugins own the full session context pipeline — too broad for a supplementary memory layer that just needs to inject additional recall results.
Impact
Affected users: Anyone running a knowledge graph memory plugin (Cognee, Mem0, Graphiti) alongside LanceDB or memory-core in a multi-agent setup. This also affects the Mem0 community (see mem0ai/mem0#4126 — same constraint reported independently).
Severity: Blocks workflow. The graph plugin either replaces the primary memory entirely (breaking existing operations) or can't load at all. There's no middle ground within the plugin system.
Frequency: Always. Every gateway restart, every session start — the second memory plugin is silently disabled. This isn't intermittent; it's a hard architectural constraint.
Consequence: Users who need both vector recall and graph recall are forced outside the plugin system entirely — running standalone API servers, writing custom exec tool wrappers, and manually triggering queries that should be handled by auto-recall lifecycle hooks. This adds infrastructure overhead (a persistent server process consuming ~2GB RAM in our case), eliminates auto-capture, and means graph context is only available when the agent explicitly calls a tool rather than being injected automatically before every turn. The practical result: the knowledge graph investment delivers a fraction of its value because it's disconnected from the memory lifecycle.
Evidence/examples
No response
Additional information
No response