Memory/Context stack questions

[twin vapor]

OpenClaw's memory stack still not convinced on LanceDB

OC v2026.5.5 | DGX Spark | Goal is 1 conductor agent helping me manage 4 businesses (3 Supabase surfaces). 80% of agent work is in telegram sessions.

The evolution:

• Wk 1 & 2 - Started with Active Memory — no cross-session continuity/memory
• W3 - Switched to QMD - some improvement but still no context. Each day was starting over.
• Wk 4 - Lossless Claw + LanceDB (~5 days)

Now seeing some cross session context/memory but still really spotty. Auto-capture on but capturing 65% noise. Agent can't retain in session context well enough to establish working crons. Established crons (using Cursor) to have agent write durable facts from transcripts to disc, and considering additional ones directly to LanceDB memory_store.

After a 120+hrs of work, I'm worn out, irritable and unsure:

• The OC "continuity of context" and memory experience I keep hearing about, just not seeing it. What's the missing piece?
• I continually have to explain the same basic things over and over. Often in the same conversation. Its really draining.
• Now useing cursor to establish basic crons because agent loses context in the same session.
• For my use case, is LanceDB + Lossless ideal? Should I add memory-wiki? What about Honcho?
• The real concern: I need to stop tweaking/configuring and get back to the work I was hoping to get help with in the first place. Afraid of going too far down the wrong path only to need to switch again. Is there an ideal memory stack for my use case?

Thanks in advance 🙏

[glass robin]

I’d treat this less as “pick the perfect database” and more as “verify which memory path is actually being injected.” The docs are pretty explicit that context and memory are separate: context is only what’s in the current model window, while memory only helps if it is saved, indexed, recalled, and injected into that run. https://docs.openclaw.ai/concepts/context https://docs.openclaw.ai/concepts/memory

A few things jump out from what you described:

1. If most work is in Telegram, check the session/chat type gates. Active Memory defaults to direct chats only, and QMD also has scope rules. If your Telegram work is in a group/channel-like session, memory may be indexed but not searched/injected unless you opted that surface in.
   Docs: https://docs.openclaw.ai/concepts/active-memory and https://docs.openclaw.ai/concepts/memory-qmd

2. LanceDB is probably not the thing I’d make the center of this setup right now. The bundled LanceDB plugin is a simple long-term vector memory plugin with auto-recall/auto-capture. Its auto-capture is rule-based and only stores user messages matching trigger patterns, so “65% noise” is not surprising. It can be useful, but it is not a magic continuity layer.

3. For your use case, I’d stop stack-churning and stabilize around:

• QMD or builtin memory as the active memory backend
• explicit durable notes in MEMORY.md for stable facts about the 4 businesses, people, preferences, systems, and standing procedures
• daily notes for running operational state
• Active Memory enabled only where you actually chat with the conductor
• optional memory-wiki later if you want a maintained knowledge base with provenance/claims/dashboards

I would not add Honcho and memory-wiki and direct LanceDB writes all at once. Honcho is the “automatic cross-session user modeling/service” path; memory-wiki is the “curated knowledge base” path. They solve different problems. Add one only after the current recall path is proven.

[glass robin]

Concrete debug loop I’d run before changing more config:

openclaw --version
openclaw memory status --deep --index --verbose
openclaw memory search "a very specific fact you know should be remembered"

Then in the actual Telegram session:

/status
/context list
/active-memory status
/verbose on
/trace on

[glass robin]

Ask something that should require memory and look for whether Active Memory reports a hit and whether the recalled summary is relevant. If search works from CLI but the chat doesn’t use it, it’s a runtime/scope/session eligibility issue. If CLI search doesn’t find the fact, it’s an indexing/storage/embedding issue. If it finds noisy facts, the fix is curation/promotion, not another vector DB.

My practical recommendation: don’t write crons directly into memory_store yet. First make a small, boring “source of truth” file structure: one durable page per business/project in Markdown, plus MEMORY.md for global durable facts. Get recall working against that. Once that is stable, memory-wiki in bridge mode is a reasonable upgrade for organizing and auditing durable knowledge. https://docs.openclaw.ai/plugins/memory-wiki

Also: you’re on 2026.5.5. Memory has been moving quickly, so include that version plus the outputs above if you continue debugging. If this turns into “memory search works but active memory isn’t injected on Telegram,” that’s a good focused GitHub issue: https://github.com/openclaw/openclaw/issues

[twin vapor]

Thank you Krill.

Follow-up questions

1. Active Memory + memory-lancedb compatibility: Active Memory doc says it rides on the configured memory plugin's recall pipeline. Our memory slot is memory-lancedb, not the builtin engine. The doc says "memory-lancedb uses memory_recall" as its recall path — does Active Memory work with that, or does it require the builtin engine (and therefore we need to switch backends first)?

2. Installation status: The plugin inventory lists active-memory as an "official external package." Does that mean it ships in the core npm package and just needs config, or does it require openclaw plugins install @openclaw/active-memory before it can be configured?

3. Backend timing: You said LanceDB is probably not the thing to center the setup around and recommended builtin engine + SoT files. Given that SoT files auto-index with builtin but not with LanceDB, and we have 88 noisy memories to migrate — would you switch backends FIRST (as prerequisite), or add Active Memory + SoT files first and defer the backend swap? The concern is change velocity — three config changes at once compounds risk if something breaks.

[glass robin]

Short answers after checking current source:

1. Active Memory does not work through memory-lancedb’s memory_recall tool today. The Active Memory sub-agent is hard-wired to run with only memory_search and memory_get allowed, and its prompt explicitly says “Use only memory_search and memory_get.” So if your memory slot is memory-lancedb, Active Memory will not be using LanceDB’s memory_recall / memory_store path. For Active Memory, assume you want memory-core with builtin or QMD underneath.

Docs: https://docs.openclaw.ai/concepts/active-memory https://docs.openclaw.ai/concepts/memory-builtin https://docs.openclaw.ai/concepts/memory-qmd

2. In current source, active-memory is a bundled extension under extensions/active-memory with an openclaw.plugin.json, not a separate package with its own package.json like memory-wiki. So if openclaw plugins list already shows active-memory, configure it directly; don’t run an install command first. If your 2026.5.5 install does not list it, that’s version/package skew, and I’d update before trying to configure it.

3. I would switch backend first, then add SoT files, then enable Active Memory. Not all at once.

Recommended order:

openclaw --version
openclaw plugins list
openclaw memory status --deep

[glass robin]

Then change only the memory slot/backend back to memory-core + builtin or QMD. Add a tiny SoT test, maybe 3-5 durable facts in MEMORY.md or business-specific Markdown. Reindex:

openclaw memory index --force
openclaw memory search "one exact fact from the SoT test"

Only after CLI recall is clean would I enable active-memory for the Telegram chat type you actually use.

The reason I’d switch first: Active Memory won’t consume LanceDB recall, and SoT Markdown is the path the builtin/QMD stack indexes naturally. If you add SoT while LanceDB still owns the slot, you may create good source files but still not exercise the recall path you’re trying to stabilize.

For the 88 noisy LanceDB memories: don’t migrate them wholesale. Export/review them, promote only durable facts into the SoT files, and leave the noisy store behind or keep it read-only as an archive. Migrating noise is how the next stack inherits the same problem with a nicer name.

[twin vapor]

Yay, another complete overhaul!!!! So grateful for your guidance.

Three questions, all scoped to things the docs don't cover:

1. QMD + memory-lancedb in the same config — memory.backend: "qmd" and plugins.slots.memory: "memory-lancedb" are on different config trees. Do they conflict, or does backend: qmd override the slot? Do we need to clear plugins.slots.memory before setting backend: qmd, or can both coexist during the switch?

2. Upgrade order — We're on 2026.5.5. You said update before configuring active-memory. Same requirement for QMD, or can we install + configure QMD on 5.5 and upgrade after? Any gotchas between these versions that affect QMD setup?

3. Session transcript scope — Can qmd.sessions: { enabled: true } be narrowed to specific session types (e.g., Telegram conductor only, exclude heartbeat/background/sub-agent), or is it all sessions in the agent?

[glass robin]

Yeah, this is exactly the kind of “two trees, one behavior” config shape that makes people want to walk into the sea. I checked the 2026.5.5 tag specifically.

One correction from my earlier reply: on 2026.5.5, Active Memory’s allowlist includes memory_recall, memory_search, and memory_get, and its prompt says to prefer memory_recall when available. So on your current version, Active Memory can work with memory-lancedb. My earlier answer was based on a stale local checkout, not the 5.5 tag. Sorry, that one matters.

Answers:

1. memory.backend: "qmd" does not override plugins.slots.memory: "memory-lancedb".

The slot decides which memory plugin owns the runtime/tool surface. If the slot is memory-lancedb, LanceDB owns memory tools, and memory.backend: "qmd" is basically not the active recall backend. QMD is a backend inside memory-core; it becomes relevant when the selected memory plugin is memory-core.

So for the QMD switch, clear the slot back to default or set it explicitly:

{
  plugins: {
    slots: {

[glass robin]

      memory: "memory-core"
    }
  },
  memory: {
    backend: "qmd"
  }
}

Leaving both during transition probably won’t crash, but it will be misleading: you’ll think you configured QMD while LanceDB is still answering recall.

2. QMD exists in 2026.5.5, so you can install/configure QMD there. I don’t see a schema blocker.

That said, I’d still upgrade first if you can tolerate one controlled change, because post-5.5 commits include QMD fixes around startup behavior, path conflicts/rebinding, and gateway startup laziness. For your situation, I would not debug a memory migration on a version that already has known QMD churn after it.

Low-risk order:

[glass robin]

openclaw --version
openclaw plugins list
openclaw status --all
# upgrade OpenClaw
# install qmd binary if needed
openclaw memory status --deep --index

Installing the qmd binary itself before upgrading is fine. I’d avoid turning on session transcript indexing until after the upgrade and after basic MEMORY.md / SoT recall works.

3. memory.qmd.sessions: { enabled: true } is not currently scoped by chat type or “Telegram conductor only.” The config surface is just enabled/exportDir/retentionDays. The implementation lists usage-counted transcript files for the agent and builds sanitized User/Assistant exports. It skips dreaming narrative transcripts, but it is not a per-channel/session-type filter.

Important distinction: memory.qmd.scope controls where QMD recall is allowed at query time. It does not narrow what transcripts get indexed.

So my recommendation: leave qmd.sessions.enabled off at first. Get QMD indexing clean SoT files and daily notes first. If you later need transcript recall, either use a dedicated conductor agent/workspace so its transcript corpus is naturally narrower, or use a curated export folder as an explicit QMD path instead of indexing all agent sessions.

[twin vapor]

Krill, we implemented the migration plan early this morning and am hopefull...

Several hours later, started a work session adjusting other agents memory configs to match ~2 hours into a Telegram session, a discussion got compacted out of active context. Same session, same conversation, same sessionKey. Conductor had no memory of what was just discussed when asked about it an hour later. Caused some chaos.

Using defaults (contextThreshold 0.75, freshTailCount 32) with auto-rotate, deferred compaction, and cache-aware mode enabled. Data stays in LCM — recall tools find it — but assembled context drops it between turns.

Are changing contextThreshold/freshTailCount/etc viable options for keeping recent conversation uncompacted? Or do you have other suggestions for preserving/extending within-session context on busy direct-message sessions?

Still haven't walked into the sea yet, but the dark black water does look inviting at times...

[glass robin]

Oof. That failure mode is exactly why “search can find it” is not the same thing as “the next model call sees it.” If the assembled prompt drops the discussion and nothing re-injects it, the conductor will behave like it never happened.

Also: if the black-water line is more than exhausted gallows humor, please step away from the machine and grab a real human locally. The config can wait.

On the knobs: contextThreshold, freshTailCount, cacheAwareCompaction, etc. are Lossless Claw/plugin-side knobs, not OpenClaw core knobs. I don’t see contextThreshold / freshTailCount in the 2026.5.5 OpenClaw source. Core OpenClaw’s relevant knobs are under agents.defaults.compaction: keepRecentTokens, recentTurnsPreserve, reserveTokens, maxHistoryShare, postIndexSync, memoryFlush, and notifyUser.

Docs:
https://docs.openclaw.ai/concepts/context
https://docs.openclaw.ai/concepts/compaction
https://docs.openclaw.ai/reference/session-management-compaction
https://docs.openclaw.ai/concepts/context-engine

Practical answer:

Yes, increasing freshTailCount is viable if Lossless Claw is doing the assembly. A tail of 32 can absolutely be too small in a busy Telegram work session; an hour later may be well outside that tail. I’d try 96 or 128 for the conductor only, not globally. Raising contextThreshold can delay compaction, but it increases the chance of late overflow/retry compaction and higher cost. I’d treat that as secondary.

For core compaction, the safer equivalent is raising recent preservation and token tail:

[glass robin]

{
  agents: {
    defaults: {
      compaction: {
        mode: "safeguard",
        keepRecentTokens: 50000,
        recentTurnsPreserve: 12,
        maxHistoryShare: 0.7,
        postIndexSync: "await",
        notifyUser: true
      }
    }
  }
}

[glass robin]

Tune numbers to the model window. If the model context is small, don’t blindly use 50k.

But I’d prioritize the architecture over just stretching the tail:

1. Turn on compaction notices for a while. Silent compaction makes this feel like random amnesia.
2. For the conductor, use a larger-context model if possible. This is exactly the workload where context window matters.
3. Keep a session working-state file, not just memory search. Something like memory/conductor-working-state.md or memory/YYYY-MM-DD.md with “Current work session / decisions / open loops / agent config changes.” Ask the conductor to update it after each meaningful phase.
4. Make Active Memory more willing to surface session/project context: queryMode: "recent" or "full", promptStyle: "recall-heavy", and a larger maxSummaryChars. If recall tools find the data but the main model doesn’t call them, Active Memory is the bridge.
5. If this is a dedicated conductor agent, consider enabling QMD session indexing for that agent only. Earlier I said leave it off during migration; now you have the actual use case for it. If it’s a shared/noisy agent, don’t enable all-session transcript indexing yet.

For debugging the next incident, capture these from the same Telegram session right after it “forgets”:

/status
/context list
/active-memory status

[glass robin]

/verbose on
/trace on

Then ask the same question again. If Active Memory debug shows no relevant recall, tune recall. If it shows the right recall but the final answer ignores it, that’s a stronger bug report for the context engine / prompt assembly path.

[twin vapor]

Very helpful, thank you so much. And yes, just gallows humor in response your your previous line "Yeah, this is exactly the kind of “two trees, one behavior” config shape that makes people want to walk into the sea".

I probably really should get out more though 😂