Active Memory vs Memory Core vs Memory Wiki | Friends of the Crustacean 🦞🤝 | Page 1

serene socket Apr 14, 2026, 1:28 PM

#

How these three working together?
Active Memory vs Memory Core vs Memory Wiki

ornate marshBOT Apr 14, 2026, 1:28 PM

#

pine berryBOT Apr 14, 2026, 1:28 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

ornate marshBOT Apr 14, 2026, 1:28 PM

#

fickle templeBOT Apr 14, 2026, 1:29 PM

#

Short version:

Memory Core = the base memory engine
- stores/indexes memory
- powers memory_search and memory_get
- handles promotion and dreaming
- default memory plugin is memory-core
Active Memory = the before-I-reply recall step
- runs before the assistant answers
- asks the memory system for relevant context
- injects a small summary so the reply feels naturally aware
Memory Wiki = the organized knowledge layer
- compiles durable memory into wiki-style pages
- adds claims, evidence, provenance, dashboards
- does not replace Memory Core

#

So the usual flow is:

Conversation happens
Active Memory queries Memory Core for relevant past context
Assistant replies with that context in mind
Memory Core keeps storing/promoting memory over time
Memory Wiki can compile the durable stuff into a cleaner knowledge base

A good mental model:

Memory Core = engine
Active Memory = proactive recall
Memory Wiki = curated library

One important bit: Memory Wiki sits beside Memory Core, not on top of it as a replacement. If bridge/shared search is enabled, you can search both together too.

Docs:

#

If you want, I can also draw the exact data flow with a tiny diagram.

serene socket Apr 14, 2026, 1:37 PM

#

I noticed in the config that if I setup memory-wiki, it sits on memory slot, and replaced memory core, do they co-exist?

fickle templeBOT Apr 14, 2026, 1:39 PM

#

Yep, they co-exist, but not in the same slot.

The key detail is:

plugins.slots.memory is a single-owner slot
that slot should point to the actual memory runtime plugin, usually memory-core
memory-wiki is a companion plugin, enabled separately under plugins.entries.memory-wiki

So the intended setup is:

memory-core owns recall, search, promotion, dreaming
memory-wiki sits beside it and compiles/organizes durable knowledge
optionally, memory-wiki can use bridge/shared search to read from memory-core

So if you set:

#

plugins: {
  slots: {
    memory: "memory-wiki"
  }
}

that would be replacing the memory runtime, which is not the normal/recommended setup.

What you usually want is more like:

plugins: {
  slots: {
    memory: "memory-core"

#

  },
  entries: {
    "memory-wiki": {
      enabled: true
    }
  }
}

Then add memory-wiki bridge/shared-search config if you want them connected.

The docs say this pretty directly:

plugins.slots.memory picks the active memory plugin
memory-wiki does not replace the active memory plugin, it sits beside it

#

Docs:

If you want, I can paste a minimal working config for memory-core + memory-wiki bridge mode.

serene socket Apr 14, 2026, 3:53 PM

#

This is mine...

    "slots": {
      "memory": "active-memory",
      "contextEngine": "lossless-claw"
    },
      "memory-wiki": {
        "enabled": true,
        "config": {
          "vaultMode": "bridge"
....
}

fickle templeBOT Apr 14, 2026, 3:54 PM

#

Ah, yep, that’s the mix-up.

In your config:

"slots": {
  "memory": "active-memory",
  "contextEngine": "lossless-claw"
}

active-memory is being used where memory-core should normally be.

The intended split

memory-core goes in plugins.slots.memory
active-memory goes in plugins.entries.active-memory

#

memory-wiki also goes in plugins.entries.memory-wiki

So the shape should be more like:

{
  plugins: {
    slots: {
      memory: "memory-core",
      contextEngine: "lossless-claw",
    },
    entries: {
      "active-memory": {
        enabled: true,
        config: {
          // your active-memory settings

#

        },
      },
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          // your wiki settings
        },
      },
    },
  },
}

How they work together then

#

memory-core = actual memory runtime, search, promotion, dreaming
active-memory = proactive recall before replies
memory-wiki = compiled wiki layer beside memory-core

So yes, they do co-exist, but active-memory should not be the thing in the memory slot.

Docs:

If you want, paste the full plugins block and I’ll sanity-check it.

serene socket Apr 14, 2026, 4:19 PM

#

This is my current:

    "slots": {
      "memory": "memory-core",
      "contextEngine": "lossless-claw"
    },

    "entries": {
      "telegram": {
        "enabled": true,
        "config": {}
      },
      "discord": {
        "enabled": true,
        "config": {}
      },
      "lossless-claw": {
        "enabled": true,
        "config": {
          "freshTailCount": 48,
          "contextThreshold": 0.75,
          "incrementalMaxDepth": -1,
          "ignoreSessionPatterns": [
            "agent:*:cron:**"
          ],
          "statelessSessionPatterns": [
            "agent:*:subagent:**"
          ],
          "skipStatelessSessions": true,
          "newSessionRetainDepth": 2,
          "summaryModel": "google/gemini-3.1-flash-lite-preview",
          "expansionModel": "google/gemini-3.1-flash-lite-preview",
          "delegationTimeoutMs": 180000,
          "summaryTimeoutMs": 60000
        }
      },
      "brave": {
        "enabled": true,
        "config": {
          "webSearch": {
            "mode": "llm-context",
            "apiKey": "${BRAVE_API_KEY}"
          }
        }
      },
      "google": {
        "enabled": true,
        "config": {
          "webSearch": {
            "model": "gemini-3.1-flash-lite-preview"
          }
        }
      },
      "exa": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": "${EXA_API_KEY}"
          }
        }
      },
      "firecrawl": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": "${FIRECRAWL_API_KEY}"
          }
        }
      },
      "openrouter": {
        "enabled": true
      },
      "memory-wiki": {
        "enabled": true,
        "config": {
          "vaultMode": "bridge",
          "vault": {
            "path": "xxxxxxx",
            "renderMode": "obsidian"
          },
          "obsidian": {
            "enabled": true,
            "vaultName": "xxxx",
            "openAfterWrites": false
          },
          "bridge": {
            "enabled": true,
            "readMemoryArtifacts": true,
            "indexDreamReports": true,
            "indexDailyNotes": true,
            "indexMemoryRoot": true,
            "followMemoryEvents": true
          },
          "ingest": {
            "autoCompile": true,
            "maxConcurrentJobs": 1
          },
          "search": {
            "backend": "shared",
            "corpus": "wiki"
          },
          "context": {
            "includeCompiledDigestPrompt": false
          },
          "render": {
            "preserveHumanBlocks": true,
            "createBacklinks": true,
            "createDashboards": true
          }
        }
      },
      "acpx": {
        "enabled": true,
        "config": {
          "timeoutSeconds": 120,
          "permissionMode": "approve-all",
          "nonInteractivePermissions": "deny"
        }
      },
      "active-memory": {
        "enabled": true,
        "config": {
          "enabled": true,
          "agents": [ xxx, xxxx, xxx
          ],
          "allowedChatTypes": [
            "direct",
            "group",
            "channel"
          ],
          "model": "google/gemini-3.1-flash-lite-preview",
          "queryMode": "recent",
          "promptStyle": "balanced",
          "timeoutMs": 10000,
          "maxSummaryChars": 300,
          "persistTranscripts": false,
          "logging": true
        }
      }

fickle templeBOT Apr 14, 2026, 4:19 PM

#

Yep, this looks structurally correct now ✅

You’ve got the layers separated the right way:

slots.memory: "memory-core"
→ good, that’s the actual memory runtime
entries.active-memory
→ good, this is the pre-reply recall pass
entries.memory-wiki with vaultMode: "bridge"
→ good, this lets wiki compile from the memory layer instead of replacing it

So in your setup, the flow is basically:

memory-core stores/searches/promotes memory
active-memory queries that before replying

#

memory-wiki builds a cleaner Obsidian/wiki layer from exported memory artifacts

Two small nuances in your current config

"corpus": "wiki"
- this means the wiki search side is focused on wiki pages only
- if you want shared search across memory + wiki, use "all"
"includeCompiledDigestPrompt": false
- this means the compiled wiki digest is not being appended into prompt context
- so right now, wiki is mostly a companion knowledge layer, not an extra prompt injection layer

That’s not wrong, just worth knowing.

So your current setup means

chat recall is mainly memory-core + active-memory

#

memory-wiki is acting more like a compiled/Obsidian knowledge vault
bridge mode keeps them connected without replacing memory-core

Also, logging: true on active-memory is nice while tuning, but I’d turn it off later once you’re happy with behavior.

If you want, I can translate your exact config into a one-line mental model, like “what affects chat replies vs what is just for the wiki.”

serene socket Apr 14, 2026, 4:24 PM

#

What other config changes do you recommand

fickle templeBOT Apr 14, 2026, 4:25 PM

#

I’d keep the changes pretty small.

My recommendations

Narrow allowedChatTypes
Right now you have:
```
["direct", "group", "channel"]
```
I’d usually start with:
```
["direct", "group"]
```

#

or even just ["direct"] if you want the safest/lowest-noise setup.

Reason: Active Memory on every channel message can add latency/cost and pull in recall where you may not want it.

Turn off Active Memory logging after tuning
You currently have:
```
"logging": true
```
Good while testing. After you’re happy, I’d switch it to false.
Decide whether wiki search should be wiki or all
You currently have:

#

   "search": {
     "backend": "shared",
     "corpus": "wiki"
   }

keep "wiki" if you want wiki tools focused on compiled wiki pages only
change to "all" if you want shared search across both raw memory + wiki

If your goal is “one memory system that sees everything”, I’d use:

"corpus": "all"

Keep includeCompiledDigestPrompt: false for now

#

I actually like your current setting there.
It keeps the prompt cleaner until you know the wiki output is genuinely useful.

Only enable dreaming if you explicitly want auto-promotion
Optional, but if you want Memory Core to automatically consolidate more useful long-term memory, look at:
```
plugins.entries.memory-core.config.dreaming.enabled
```
I would treat this as an intentional next step, not something to flip on blindly.

So my practical “best default” tweak set would be

allowedChatTypes: ["direct", "group"]

#

logging: false once tuned
memory-wiki.search.corpus: "all" if you want unified recall

Then validate with:

openclaw memory status --deep
openclaw wiki doctor

If you want, I can turn your pasted config into a recommended cleaned-up version with just those edits.

serene socket Apr 14, 2026, 4:27 PM

#

How to enable dreaming

fickle templeBOT Apr 14, 2026, 4:28 PM

#

Add this under plugins.entries.memory-core.config:

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true
          }
        }
      }
    }
  }
}

#

Then restart the gateway.

If you want a custom schedule:

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "timezone": "America/Chicago",
            "frequency": "0 */6 * * *"
          }
        }

#

      }
    }
  }
}

A few useful bits:

default schedule is 0 3 * * *
dreaming is experimental
only the deep phase writes durable memory to MEMORY.md
you can also toggle it in chat with:
- /dreaming status
- /dreaming on
- /dreaming off

#

To verify:

openclaw memory status --deep

Docs:

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

#Active Memory vs Memory Core vs Memory Wiki

The intended split

How they work together then

Two small nuances in your current config

So your current setup means

My recommendations

So my practical “best default” tweak set would be