RFC: multi-slot memory role architecture - #22
Open
kklouzal wants to merge 3 commits into
Open
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed August 15, 2026, 3:58 PM ET / 19:58 UTC. ClawSweeper reviewWhat this changesThe PR adds a draft RFC and research note proposing separate plugin slots for recall, compaction, capture, dreaming, and user-model memory roles. Merge readinessThis draft RFC is not ready to merge: it reuses an allocated RFC namespace, lacks the required recorded maintainer discussion, and needs current implementation provenance before its compatibility contract can be accepted. Priority: P2 Review scores
Verification
How this fits togetherOpenClaw plugin configuration selects memory providers, which the plugin loader and agent runtime use for recall and related memory work. This RFC would change that contract from one shared memory selector to several role-specific selectors. flowchart LR
A[Plugin configuration] --> B[Memory role selection]
B --> C[Legacy memory mapping]
B --> D[Plugin activation]
D --> E[Recall and capture services]
D --> F[Agent runtime]
F --> G[Status and doctor guidance]
Decision needed
Why: The RFC intentionally leaves role names, scalar slot shape, per-agent scope, and legacy migration policy open; these are public compatibility choices rather than mechanical documentation fixes. Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Assign a new RFC namespace, record the maintainer discussion, and explicitly sponsor or revise the role-slot and compatibility contract against a current implementation reference. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a design RFC, and the proposed runtime behavior belongs to the linked implementation rather than this documentation-only patch. Is this the best way to solve the issue? Unclear: role-specific slots are a coherent direction, but their public names, migration behavior, and per-agent boundary require maintainer product approval before this RFC can be accepted. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning high; reviewed against af708f0ddb6f. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (50 earlier review cycles; latest 8 shown)
|
clawsweeper
Bot
added
rating: 🦐 gold shrimp
clawsweeper
Bot
added
rating: 🦞 diamond lobster
clawsweeper
Bot
removed
proof: sufficient
clawsweeper
Bot
added
merge-risk: 🚨 compatibility
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a draft RFC for the multi-slot memory role architecture implemented in openclaw/openclaw#88504.
This turns OpenClaw memory from one overloaded global selector into a composable role-based memory surface, so recall, compaction, capture, dreaming/consolidation, and user-model memory can be owned by different plugins without fighting over
plugins.slots.memory.The RFC proposes purpose-specific memory role slots:
memory.recallmemory.compactionmemory.capturememory.dreamingmemory.userModelwhile preserving legacy
plugins.slots.memoryas deprecated shorthand formemory.recall.Problem solved
Today, OpenClaw effectively has one memory plugin slot. That makes sense for simple factual recall, but it breaks down as memory becomes a richer runtime subsystem.
A factual recall provider, capture plugin, compaction memory provider, dreaming/consolidation owner, and user-model plugin are different responsibilities. With only one selector, they either compete for ownership, require plugin-specific side channels, or get pushed toward unrelated extension points such as
contextEngine.This RFC gives those responsibilities explicit config/runtime slots while keeping old configs working.
Scope
This RFC is about the public config/API shape and migration contract for memory role composition.
It covers:
plugins.slotsplugins.slots.memorycompatibilitydoctor --fixmigration behavioragents.list[].plugins.slotscontextEngineseparate and globalIt intentionally does not cover:
plugins.slots.memoryimmediatelycontextEnginesemanticsImplementation reference
Implementation PR: openclaw/openclaw#88504
The implementation updates config schema, slot resolution, plugin loading, memory runtime resolution, doctor repair, uninstall/update cleanup, status output, docs, and tests.
The RFC keeps the detailed implementation file list and proof notes inside the RFC body so this PR description can stay reviewable.
Validation / proof
The implementation PR has source and runtime proof notes attached.
Current implementation head referenced by the RFC:
c447e22033ca104cb9d5292edf4313bcb74f81cfLatest local validation at that head:
passed before push.
Earlier exact-head proof referenced by the RFC:
3f1f547042220aee42b3e39b8cb7ecb15cfac993That proof covered the role-slot contract, per-agent overrides, legacy compatibility, disabled recall slots, doctor migration/repair behavior, role-slot plugin activation/validation, upgrade behavior, and live gateway/source runtime behavior.
Review focus
Feedback requested on:
plugins.slots.memoryshould be legacy shorthand formemory.recallcontextEngineshould remain separate/global in this RFCRFC lifecycle notes
draft.issueis intentionally blank until acceptance.rfc_pris set to this PR.Memory-plugin interop research: the supporting research document validates this RFC as necessary architecture work, not optional extensibility: OpenClaw's own documentation already describes memory as a composable ecosystem where builtin/QMD recall, Honcho user/session modeling, LanceDB recall/capture, Active Memory orchestration, dreaming/consolidation, and Memory Wiki compilation can coexist, but current
origin/maincollapses everykind: "memory"provider into one exclusiveplugins.slots.memoryowner, making those documented combinations impossible or dependent on brittle exceptions. This RFC closes that product/docs/runtime gap by replacing the single memory owner with explicit role slots —memory.recall,memory.capture,memory.compaction,memory.dreaming, andmemory.userModel— while preserving legacymemoryas a recall shorthand, so the documented memory-plugin interop story becomes actually representable in config and runtime behavior.