RFC: multi-slot memory role architecture#22
Open
kklouzal wants to merge 3 commits into
Open
Conversation
|
Codex review: found issues before merge. Reviewed July 3, 2026, 8:27 AM ET / 12:27 UTC. Summary Reproducibility: not applicable. this is a design RFC, not a runtime bug. The concrete checks are the PR diff, RFC lifecycle docs, current-main numbering, and linked implementation proof/status. Review metrics: 3 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: If maintainers accept the direction, assign a unique RFC id, update the sidecar path and links, set accepted lifecycle metadata, and refresh the linked implementation status/proof before merge. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a design RFC, not a runtime bug. The concrete checks are the PR diff, RFC lifecycle docs, current-main numbering, and linked implementation proof/status. Is this the best way to solve the issue? No for merge as-is: the RFC repository is the right review vehicle, but the number, lifecycle metadata, and stale implementation reference need maintainer decisions and updates before landing. 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 a8e0ba2701d6. Label changesLabel justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
clawsweeper
Bot
added
rating: 🦐 gold shrimp
clawsweeper
Bot
added
rating: 🦞 diamond lobster
|
ClawSweeper status: review started. I am starting a fresh review of this pull request: RFC: multi-slot memory role architecture This is item 1/1 in the current shard. Shard 0/1. This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking. Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted. |
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.