CompositeCubeView currently uses a simple fast-mode strategy for multiple memory cubes: writes and feedback are fanned out to all cube views, while search results are merged from all cubes.
This is useful as a baseline, but it is not the ideal long-term behavior. In a mature multi-cube memory system, a new memory should not automatically be added to every accessible cube. It should be routed to the cube or cubes whose responsibility best matches that memory.
Context
Target file:
src/memos/multi_mem_cube/composite_cube.py
Current design note:
A composite view over multiple logical cubes.
For now (fast mode), it simply fan-out writes to all cubes;
later we can add smarter routing / slow mode here.
Goals
Improve CompositeCubeView so multi-cube behavior becomes more responsibility-aware:
- Avoid blindly writing every memory to all accessible cubes.
- Route add/feedback operations based on cube responsibility, request context, memory type, user/session metadata, or another explicit policy.
- Keep the current fan-out behavior available as a fallback or fast mode.
- Improve search aggregation so results preserve useful cube provenance.
- Handle partial failures clearly when one cube fails but others succeed.
Questions to Consider
- How should a cube declare or expose its responsibility?
- Should routing be rule-based, metadata-based, model-assisted, or configurable?
- When should a memory be written to multiple cubes vs exactly one cube?
- Should search results include
cube_id so downstream consumers know where each memory came from?
- What should happen when no cube clearly matches the memory?
Acceptance Criteria
CompositeCubeView has a clearer routing strategy beyond unconditional fan-out.
- The default/fast fan-out behavior remains available for compatibility.
- Add/search/feedback behavior is covered by tests in a multi-cube scenario.
- The implementation documents how cube responsibility is used or configured.
CompositeCubeViewcurrently uses a simple fast-mode strategy for multiple memory cubes: writes and feedback are fanned out to all cube views, while search results are merged from all cubes.This is useful as a baseline, but it is not the ideal long-term behavior. In a mature multi-cube memory system, a new memory should not automatically be added to every accessible cube. It should be routed to the cube or cubes whose responsibility best matches that memory.
Context
Target file:
src/memos/multi_mem_cube/composite_cube.pyCurrent design note:
Goals
Improve
CompositeCubeViewso multi-cube behavior becomes more responsibility-aware:Questions to Consider
cube_idso downstream consumers know where each memory came from?Acceptance Criteria
CompositeCubeViewhas a clearer routing strategy beyond unconditional fan-out.