RFC: multi-slot memory role architecture

[kklouzal]

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.recall
• memory.compaction
• memory.capture
• memory.dreaming
• memory.userModel

while preserving legacy plugins.slots.memory as deprecated shorthand for memory.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:

• canonical global memory role slots under plugins.slots
• legacy plugins.slots.memory compatibility
• conservative doctor --fix migration behavior
• per-agent memory role overrides under agents.list[].plugins.slots
• keeping contextEngine separate and global
• role-aware runtime/plugin behavior for validation, startup preload, uninstall cleanup, status, doctor output, skills, and hooks

It intentionally does not cover:

• removing plugins.slots.memory immediately
• adding per-agent contextEngine semantics
• introducing object-valued slot/provenance metadata
• requiring every memory plugin to implement every role
• settling all future memory-provider composition work

Implementation 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:

• c447e22033ca104cb9d5292edf4313bcb74f81cf

Latest local validation at that head:

pnpm tsgo:prod

passed before push.

Earlier exact-head proof referenced by the RFC:

• 3f1f547042220aee42b3e39b8cb7ecb15cfac993

That 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:

• whether these are the right first-class memory roles
• whether plugins.slots.memory should be legacy shorthand for memory.recall
• whether per-agent slot overrides should stay limited to memory roles for now
• whether contextEngine should remain separate/global in this RFC
• whether scalar plugin-id slot values are sufficient for this phase
• whether any role names should change before this becomes public config surface

RFC lifecycle notes

• Status is draft.
• issue is intentionally blank until acceptance.
• rfc_pr is set to this PR.
• A maintainer-discussion thread should be opened per the RFC repo flow if maintainers want to proceed with formal review there.

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/main collapses every kind: "memory" provider into one exclusive plugins.slots.memory owner, 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, and memory.userModel — while preserving legacy memory as a recall shorthand, so the documented memory-plugin interop story becomes actually representable in config and runtime behavior.

[clawsweeper]

Codex review: found issues before merge. Reviewed June 24, 2026, 4:23 PM ET / 20:23 UTC.

Summary
Adds a draft multi-slot memory-role RFC and supporting interop research for splitting OpenClaw memory ownership into recall, capture, compaction, dreaming, and user-model slots.

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.

• RFC Diff Surface: 2 files added, 798 lines added. The PR adds a proposal plus sidecar research, so review is primarily product/API direction rather than executable code.
• Public Config Surface: 5 role slots, 1 legacy shorthand, 1 per-agent override surface. The proposed names and compatibility rules would become durable API direction if accepted.
• RFC Number Conflict: 1 merged 0009 RFC on main plus 4 open 0009 candidates. Maintainers need an explicit numbering decision before another 0009 RFC can land cleanly.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Assign a unique RFC number and update the file/sidecar references.
• If accepted, update status and issue according to the RFC lifecycle.
• Coordinate final acceptance with feat(memory): add multi-slot memory role architecture openclaw#88504.

Risk before merge

• [P1] Merging as-is would leave two top-level RFC 0009 documents on current main because RFC: Hosted feeds for plugins and skills #19 already merged the hosted-feeds RFC as 0009.
• [P1] The proposed role names, default values, legacy shorthand behavior, disabled-slot semantics, and per-agent override scope become durable public config/API direction if accepted.
• [P1] The RFC is still status: draft with a blank issue, so final merge would conflict with the repository lifecycle unless maintainers first accept the RFC and fill the implementation issue.
• [P1] The linked implementation at feat(memory): add multi-slot memory role architecture openclaw#88504 is still open, so final RFC acceptance should stay coordinated with that review.

Maintainer options:

1. Renumber And Finalize If Accepted (recommended)
   If maintainers accept the direction, rename the RFC and sidecar path away from 0009, create or link the implementation issue, and update the RFC status before merge.
2. Coordinate With Implementation Review
   Pause final acceptance until feat(memory): add multi-slot memory role architecture openclaw#88504 converges if maintainers want that implementation review to settle the public API shape first.
3. Defer The Memory Role Taxonomy
   Pause or close this PR if maintainers do not want these memory role slots to become near-term public OpenClaw direction.

Next step before merge

• [P2] Maintainers need to choose the RFC number, acceptance state, and public memory role API; automation should not make that product decision.

Security
Cleared: The diff only adds Markdown RFC/research files and does not change executable code, dependencies, workflows, secrets handling, or package metadata.

Review findings

• [P2] Resolve the RFC number before merge — rfcs/0009-multi-slot-memory-role-architecture.md:1

Review details

Best possible solution:

Keep this PR open for maintainer API review; if accepted, assign a unique RFC number, update lifecycle metadata, and coordinate with the linked OpenClaw implementation PR.

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 public memory role API require maintainer decisions before landing.

Full review comments:

• [P2] Resolve the RFC number before merge — rfcs/0009-multi-slot-memory-role-architecture.md:1
  Current main already contains rfcs/0009-hosted-feeds-for-plugins-and-skills.md from RFC: Hosted feeds for plugins and skills #19. This added RFC should be assigned a unique number before merge to avoid two accepted documents claiming 0009.
  Confidence: 0.93

Overall correctness: patch is incorrect
Overall confidence: 0.88

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against 89cf322325b0.

Label changes

Label justifications:

• P2: The PR proposes significant memory plugin API direction and needs normal maintainer review, but it is not an urgent production regression.
• merge-risk: 🚨 other: Merging before maintainer acceptance would publish unresolved RFC lifecycle, numbering, and product/API direction.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (linked_artifact): The RFC links to an implementation PR with copied runtime, upgrade, doctor, focused-test, and gateway proof for the proposed memory role-slot behavior.
• proof: sufficient: Contributor real behavior proof is sufficient. The RFC links to an implementation PR with copied runtime, upgrade, doctor, focused-test, and gateway proof for the proposed memory role-slot behavior.

Evidence reviewed

What I checked:

• No target AGENTS.md: The target openclaw/rfcs checkout has no AGENTS.md, so no target-specific AGENTS policy applies. (89cf322325b0)
• RFC lifecycle policy: The README says new RFCs should not be merged while status: draft, require a maintainer discussion thread, and accepted RFCs should set an implementation issue before merge. (README.md:80, 89cf322325b0)
• PR head metadata: The added RFC currently has status: draft, a blank issue, and rfc_pr pointing to this PR, which is appropriate for review but not final accepted metadata. (rfcs/0009-multi-slot-memory-role-architecture.md:7, 63fb092a20f8)
• Current-main RFC number collision: Current main already contains merged RFC 0009 for hosted feeds from RFC: Hosted feeds for plugins and skills #19, so this branch would add a second top-level 0009 RFC unless renumbered. (rfcs/0009-hosted-feeds-for-plugins-and-skills.md:1, 89cf322325b0)
• Open 0009 queue: GitHub still shows multiple open RFC PRs using or reserving 0009, including RFC 0009: Gmail Pub/Sub pull delivery #8, docs: add Agent Profiles RFC #18, RFC 0009: Iroh Gateway transport #23, and RFC 0009 addendum: Feed observability and usage telemetry #24.
• Linked implementation status and proof: The linked OpenClaw implementation remains open and proof-positive, with copied validation covering role-slot contract, upgrade behavior, focused tests, and live gateway/source runtime behavior, but the RFC still requires maintainer product acceptance.

Likely related people:

• kevinlin-openai: Blame and history tie the draft/acceptance/issue lifecycle rules that govern this PR to this contributor. (role: RFC process contributor; confidence: high; commits: e366ea9825a4, bbb4058da234, f4fdf38f4717; files: README.md, rfcs/0000-template.md)
• Dallin Romney: Blame and history tie the sidecar layout rules used by this PR's rfcs/0009/ research file to this contributor. (role: recent RFC structure contributor; confidence: medium; commits: 3aa7d727383f; files: README.md, rfcs/0000-template.md)
• giodl73-repo: Current main's merged RFC 0009 came from this contributor's hosted-feeds RFC, making them relevant to numbering coordination. (role: adjacent RFC number contributor; confidence: medium; commits: 89cf322325b0; files: rfcs/0009-hosted-feeds-for-plugins-and-skills.md)
• ragesaq: Current main contains this contributor's context-engine runtime settings RFC, adjacent to this PR's plugin slot and contextEngine boundary decisions. (role: adjacent plugin/config RFC author; confidence: medium; commits: 951ec46d8675; files: rfcs/0008-context-engine-runtime-settings.md)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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 keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.