#Memory

12 messages · Page 1 of 1 (latest)

chrome obsidian
#

Can you list pros and cons of using memory core stack with active memory/dreaming/memory-wiki vs using honcho?

trail turretBOT
#

Short version, I’d frame it like this:

memory-core stack = local, inspectable, curated
Honcho = automatic, cross-session, service-backed

Also, one important nuance: this is not fully either/or.

  • Active Memory is a separate pre-reply enrichment layer
  • memory-wiki can sit beside different memory backends
  • Dreaming is documented as a memory-core feature specifically
  • Honcho can also coexist with other memory pieces

memory-core + Active Memory + Dreaming + memory-wiki

Pros

  • Local-first and transparent: memory lives in Markdown / local storage, easy to inspect and edit
  • Human-reviewable: MEMORY.md, daily notes, DREAMS.md, wiki pages
#
  • Strong provenance with memory-wiki: claims, evidence, contradictions, freshness
  • Good for PKM / Obsidian-style workflows
  • No extra service required for the builtin stack
  • Dreaming helps keep long-term memory cleaner instead of dumping everything into MEMORY.md

Cons

  • More moving parts and more tuning
  • More operational complexity than “just remember everything”
  • User modeling is less automatic than Honcho
  • Cross-session continuity is more file-driven than conversation-native
  • Dreaming is experimental
  • Active Memory is bounded/eligibility-based, not universal magic recall

Honcho

Pros

  • Automatic cross-session memory after every turn
#
  • User + agent modeling built in
  • Semantic search over past conversations
  • Better multi-agent awareness
  • Works well if you want memory to feel seamless across sessions/channels
  • Can be managed or self-hosted

Cons

  • Extra plugin/service dependency
  • Less file-native / less inspectable than the Markdown-first stack
  • Less suited to “curated knowledge base” workflows than memory-wiki
  • Manual editing / auditing is weaker than just opening a Markdown file
  • If you care a lot about provenance-rich, wiki-style knowledge, Honcho alone is thinner there

My recommendation

  • If you want control, inspectability, and knowledge curation, go with the memory-core stack
  • If you want frictionless conversational memory across sessions, go with Honcho
chrome obsidian
#

I can’t get memory wiki working with honcho because honcho doesn’t expose the memory so wiki will always be empty

trail turretBOT
#

Yeah, I think that’s the catch.

memory-wiki bridge mode only works when the active memory side exposes public memory artifacts for the wiki to import. The docs call this out pretty directly:

  • bridge mode can be enabled but have zero exported artifacts
  • in that case, the active memory plugin is not exposing public bridge inputs yet

So if Honcho isn’t exporting those artifacts, then yes, the wiki bridge has nothing to ingest and it stays empty.

Practical reality today

  • memory-core / QMD + memory-wiki bridge: good fit
  • Honcho + memory-wiki bridge: likely empty / not really wired up
  • Honcho + memory-wiki isolated mode: works, but they’re basically separate systems
  • Honcho alone: great for conversational memory, not great as a source for wiki compilation

So I’d revise my earlier framing to:

chrome obsidian
#

How can the wiki be filled in isolated mode with honcho backend

trail turretBOT
#

Basically, it doesn’t auto-fill from Honcho in isolated mode.

In isolated mode, memory-wiki is its own vault, not a mirror of the Honcho store. So the flow is:

  1. Init the wiki

    openclaw wiki init

  2. Put source material into it

    • ingest files / URLs:
      openclaw wiki ingest ./notes/alpha.md
    • or have the agent use wiki_apply to create/update syntheses, claims, metadata

  3. Compile + lint

# 
   openclaw wiki compile
   openclaw wiki lint

So with Honcho backend + isolated wiki:

  • Honcho = conversational recall / user modeling / search
  • Wiki = separate curated knowledge base you populate intentionally

What Honcho can still do here

Honcho can help the agent find relevant history, but the wiki only gets filled if something then writes into the wiki:

  • wiki_ingest
  • wiki_apply
  • manual editing in the vault
  • agent workflows that turn recalled info into syntheses/pages
#

Important distinction

  • search.backend: "shared" can help search span layers
  • but searching is not importing
  • isolated mode still won’t magically sync Honcho memory into wiki pages

So if your expectation is:

“Use Honcho as memory backend, and have wiki automatically build itself from that”

then yeah, that path doesn’t really exist today.

If you want, I can sketch the least-janky setup for:

  1. Honcho for recall
  2. wiki for curated durable knowledge
  3. minimal manual work.