mosaicstack/stack
25
0 Fork 1
Code Issues 402 Pull Requests 13 Packages Projects Releases 15 Wiki Activity

Memory as user-configurable plugins (mem0, Hindsight and others) with a Settings page #1856

New Issue
Open
opened 2026-11-06 23:00:00 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-11-06 23:00:00 +00:00
Owner
Copy link
Copy source

Jason, 2026-11-06, live uidev feedback:

memory management system like mem0, hindsight, etc. should be plugins/modules configurable by the user
Settings page will need to allow for the customization of the memory module

What is wanted

  • Agent memory is a plugin slot, not a built-in. A user picks a memory module per instance (and possibly per business), for example mem0, Hindsight, or none.
  • Each module declares its own settings (endpoint, storage, retention, scope per agent or per project, and any credential it needs as a runtime reference, never a value in the repo).
  • Settings gets a Memory section: choose the module, edit its settings, see whether it is reachable, and turn it off.

Starting points in the current foundation

  • The plug-in switch already exists: plugins / plugins.set verbs, human-only, logged in changes.jsonl, a missing module refused (packages/bus/src/runtime.mjs, pluginSettings, vikunja 19/305). Memory should be a module kind inside that mechanism, not a second switch.
  • Settings sub-routes and the section menu landed in UI slice 2 (packages/webui/src/public/bus.js, settings pages list).
  • Credentials stay runtime-only (invariant 3). A module that needs a key reads it from the instance's secrets store through the existing credential references.

Open questions for the design

  1. Scope: one module per instance, or per business, or per agent role?
  2. Interface: what calls does a memory module answer (add, search, forget, list), and which of them may an agent call versus only the human?
  3. Where memory runs: in-process adapter, a sidecar service, or a remote API. mem0 and Hindsight both offer self-hosted and hosted modes; the hosted mode is an external account and needs Jason's go.
  4. Evidence: memory writes are not run records, but a write an agent made should be traceable to the run that made it.
  5. Migration: what happens to stored memory when the user switches modules.

Acceptance (for the first slice)

  • A design doc answering the five questions, reviewed once.
  • One module working end to end on a local instance, with a no-op module as the default.
  • Settings Memory section with the module picker and its settings form, same patterns as the other Settings sections.

Not started. Filed by the Lead so it is on the list.

Jason, 2026-11-06, live uidev feedback: > memory management system like mem0, hindsight, etc. should be plugins/modules configurable by the user > Settings page will need to allow for the customization of the memory module ## What is wanted - Agent memory is a plugin slot, not a built-in. A user picks a memory module per instance (and possibly per business), for example mem0, Hindsight, or none. - Each module declares its own settings (endpoint, storage, retention, scope per agent or per project, and any credential it needs as a runtime reference, never a value in the repo). - Settings gets a Memory section: choose the module, edit its settings, see whether it is reachable, and turn it off. ## Starting points in the current foundation - The plug-in switch already exists: `plugins` / `plugins.set` verbs, human-only, logged in changes.jsonl, a missing module refused (`packages/bus/src/runtime.mjs`, `pluginSettings`, vikunja 19/305). Memory should be a module kind inside that mechanism, not a second switch. - Settings sub-routes and the section menu landed in UI slice 2 (`packages/webui/src/public/bus.js`, settings pages list). - Credentials stay runtime-only (invariant 3). A module that needs a key reads it from the instance's secrets store through the existing credential references. ## Open questions for the design 1. Scope: one module per instance, or per business, or per agent role? 2. Interface: what calls does a memory module answer (add, search, forget, list), and which of them may an agent call versus only the human? 3. Where memory runs: in-process adapter, a sidecar service, or a remote API. mem0 and Hindsight both offer self-hosted and hosted modes; the hosted mode is an external account and needs Jason's go. 4. Evidence: memory writes are not run records, but a write an agent made should be traceable to the run that made it. 5. Migration: what happens to stored memory when the user switches modules. ## Acceptance (for the first slice) - A design doc answering the five questions, reviewed once. - One module working end to end on a local instance, with a no-op module as the default. - Settings Memory section with the module picker and its settings form, same patterns as the other Settings sections. Not started. Filed by the Lead so it is on the list.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
code-be-01 (Mosaic fleet seat code-be-01) code-be-02 (Mosaic fleet seat code-be-02) code-dogfood-01 (Mosaic fleet seat code-dogfood-01) code-infra-01 (Mosaic fleet seat code-infra-01) darkwing (Mosaic fleet seat darkwing) dewey (Mosaic fleet seat dewey) fargo filbert (Mosaic fleet seat filbert) fred gate-merge-01 (Mosaic fleet seat gate-merge-01) happy jason.woltje (Jason Woltje) marcie merge-gate mosaic-stack-coder-bot (mosaic-stack coder bot) mosaic-stack-cto-bot (mosaic-stack cto bot) mosaic-stack-pm-bot (mosaic-stack pm bot) ops-01 (Mosaic fleet seat ops-01) ops-02 (Mosaic fleet seat ops-02) ops-03 (Mosaic fleet seat ops-03) ops-ci-01 (Mosaic fleet seat ops-ci-01) ops-deploy-01 (Mosaic fleet seat ops-deploy-01) orch-01 (Mosaic fleet seat orch-01) pepper resume rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev-security-03 (Mosaic fleet seat rev-security-03) rocko (Mosaic fleet seat rocko) sanity scooby (Scooby) scrappy shaggy tiny topher (Mosaic fleet seat topher) velma veronica (Mosaic fleet seat veronica) vision woodpecker
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1856