openclaw - 💡(How to fix) Fix memory-wiki: per-agent / per-sessionKey scope for `includeCompiledDigestPrompt` and `registerMemoryPromptSupplement` [1 comments, 2 participants]

Summary

The memory-wiki plugin's context.includeCompiledDigestPrompt: true injects the compiled wiki digest into every agent prompt build, with no way to scope it to specific agents, sessions, or session-key prefixes. Same applies to any plugin registered via registerMemoryPromptSupplement. This makes the plugin practically unusable in multi-session setups where the operator wants the digest in interactive sessions but not in tactical cron-fired sessions.

Current behavior (v2026.5.3-1, but applies to all recent versions)

memory-wiki registers its prompt section as a global supplement:

// dist/extensions/memory-wiki/index.js
api.registerMemoryPromptSupplement(createWikiPromptSectionBuilder(config));

The builder type signature exposes only availableTools and citationsMode (no session context):

// plugin-sdk/src/plugins/memory-state.d.ts
export type MemoryPromptSectionBuilder = (params: {
    availableTools: Set<string>;
    citationsMode?: MemoryCitationsMode;
}) => string[];

The downstream buildMemorySection call site (in system-prompt-*.js) similarly receives only { isMinimal, includeMemorySection, availableTools, citationsMode } — sessionKey / agentId are never threaded down to this layer.

Result: a plugin author has no way to filter the supplement output by session, and an operator has no config knob to do it either.

Use case

Daily setup with one Telegram-routed interactive agent (agent:main:telegram:direct:<userId>) and ~16 cron-fired sessions (agent:main:cron:<jobId>:run:<runId>). The interactive session benefits from cross-project wiki context. Cron sessions are tactical (post a tweet, scrape a page, reconcile billing) and the digest is pure noise — at best ignored, at worst causing cross-pollination where a cron reads workflow rules from another project.

Operationally we worked around this by stripping forced wiki_get / wiki_search calls from every cron's SKILL.md (10 files). That reduces behavioral drift but the digest is still pasted into every cron's system prompt, costing ~250 tokens × N runs/day.

Suggested API

Two options, in order of cleanliness:

A) Plugin-config scope predicate — extend the context block of any plugin that registers a memory prompt supplement:

\"context\": {
  \"includeCompiledDigestPrompt\": true,
  \"scope\": {
    \"includeSessionKeyPatterns\": [\"agent:main:telegram:*\"],
    \"excludeSessionKeyPatterns\": [\"*:cron:*\"]
  }
}

B) Session context in builder — extend MemoryPromptSectionBuilder:

export type MemoryPromptSectionBuilder = (params: {
    availableTools: Set<string>;
    citationsMode?: MemoryCitationsMode;
    sessionKey?: string;   // <-- new
    agentId?: string;       // <-- new
}) => string[];

…and thread sessionKey from the agent run context through buildMemorySection → buildMemoryPromptSection. Plugins can then filter themselves.

(A) is no-code-change for plugin authors and matches the user-mental-model. (B) is more flexible but pushes the responsibility into every plugin.

Related

• mem0ai/mem0#4126 — "Support per-agent memory configuration in multi-agent setups" (parallel ask in mem0)
• #17732 — Per-topic agent/model bindings for Telegram (similar scoping ask, different surface)
• #12213 — Add UserPromptSubmit and PreToolUse hooks for memory injection (related prompt-time hook ask)

Workaround until fix

For now: set includeCompiledDigestPrompt: false and rely on wiki_search / wiki_get tools called explicitly from interactive sessions only. Loses passive injection benefit; requires the agent to remember to call wiki tools.