Background
We maintain a long-running fork of this project with 148 commits that are not in upstream. The work is substantial and production-tested. Every time upstream cuts a new release, we spend significant effort rebasing, resolving conflicts, and re-validating everything.
We would like to discuss merging some or all of these features upstream so we can stop maintaining a permanent divergence. Carrying this as a private fork is increasingly painful — the upstream codebase is actively developed and the conflict surface grows with every release.
This issue is an invitation to discuss which parts upstream would accept, and in what form.
What we have built
1. Project topic inbox
Aggregates L1 traces by topic, persists a project-scoped topic inbox with durable processing guarantees, idempotency keys, and conflict boundaries. Lets the memory system track what an agent is actually working on across sessions.
Key commits: feat: add project topic inbox, feat(memory): aggregate L1 traces into project topics, feat(memory): persist project topic inbox, feat(api): expose project topic inbox
2. Topic Decision system (multi-agent deliberation)
A full-stack feature: bounded decision sessions, multi-agent position synthesis, evidence gating, reversible action execution with double-confirmation, idempotent replay, conflict resolution, and a Viewer panel. Agents propose positions on a topic; the system synthesizes them into a decision with risk/assumption tracking.
Key commits: feat(memory): synthesize bounded topic decisions, feat(topic-decision): implement multi-agent decision data-flow contracts, feat(memory): execute approved reversible topic actions, feat(memory): add topic decision console, feat(topic-decision): harden position generation and expose staged API
This is the largest feature block — roughly 40 commits covering storage, service, HTTP contracts, and Viewer UI.
3. Memory Assets
A lifecycle for reusable named knowledge artifacts that persist across tasks: asset storage layer, loadout management, recall, temporal validity, evolution. REST API and full test coverage.
Key commits: feat(memory): add asset/evolution storage layer, feat(memory): asset lifecycle, loadout, recall, temporal validity services, feat(memory): REST API for assets, loadouts, sequences, recalls, temporal validity
4. Authoritative project context governance
A mechanism for designating one memory as the authoritative context pack for a project — the agent always loads it at session start. Desktop, Backend, and Agent endpoints wired. Context pack history view and token usage stats in the Viewer.
Key commits: feat(memory): add authoritative project context, feat(backend): expose project context governance, feat(agent): preserve project context turn provenance, feat(desktop): add project context governance, feat: add context pack history and secure docker releases, feat: add context pack views and token usage stats
5. MCP bridge for DeepSeek Harness
Full MCP integration: DSH source adapter with session discovery and zstd decode, DSH lifecycle tools, agent plugin that reads token from preset config, workspace auto-injection into opened sessions. Allows DeepSeek Harness sessions to write and read Memory through MCP without any manual config.
Key commits: feat(memory): add MCP bridge for DeepSeek Harness integration, feat(memory): DSH source adapter - session discovery, zstd decode, import, feat(mcp): DSH lifecycle tools + agent plugin (Phase 2), feat(mcp): carry workspace into memories via auto-opened session
6. Additional agent source integrations
- OMP and FreeBuff agent source adapters
- Pi memory integration
- memmy-project-summarize skill for producing project-state summaries from Memory
Key commits: feat: integrate OMP and FreeBuff agent sources, feat: add Pi memory integration, feat: add memmy-project-summarize skill
7. L1 retrieval layer tuning
Exclude L1 memories from turn-start and intent retrieval layers to reduce noise in the agent context injection path.
Key commit: feat(memory): exclude L1 from turn-start and intent retrieval layers
8. Project-scoped review synthesis
A synthesis layer that reviews memories within a project scope and produces a consolidated insight.
Key commit: feat(memory): add project-scoped review synthesis, feat: add scoped memory governance protocol
9. Memory panel as standalone browser entry point
Deploy the Memory Viewer without the Electron wrapper — accessible as a plain web app. This is already how we run it in Docker.
Key commit: feat(web): deploy Memmy browser entry point without Electron
10. Inactive evolution memory lifecycle
Centralizes the lifecycle for memories that have stopped evolving — grading project evidence, archiving stale candidates cleanly.
Key commit: feat(memory): centralize inactive evolution memory lifecycle and grade project evidence
Our ask
We are not asking upstream to accept all of it at once. We would prefer to discuss:
- Which of the above upstream considers in scope and worth reviewing as a PR
- Whether there is a preferred order (e.g. smaller/cleaner items first to build trust)
- Whether any items conflict with planned upstream work we should know about
- If upstream prefers a different contribution format (one feature per PR, RFC-first, design doc first)
The features with the most value to the broader user base are probably Topic Decision (novel capability), Memory Assets (reusable knowledge across tasks), and authoritative project context (every power user wants this). The MCP/DSH integration and additional agent sources are more niche but add real coverage for users of those tools.
We are happy to rebase any of these cleanly onto the current main and open separate PRs. What we want to avoid is continuing to carry all of this as a private patch set forever.
Context
Our fork: https://github.com/bluewatercg/memmy-agent
Branch with the work: wip/pre-upstream-convergence-20260827
Commits unique to our fork vs upstream main: 148
Background
We maintain a long-running fork of this project with 148 commits that are not in upstream. The work is substantial and production-tested. Every time upstream cuts a new release, we spend significant effort rebasing, resolving conflicts, and re-validating everything.
We would like to discuss merging some or all of these features upstream so we can stop maintaining a permanent divergence. Carrying this as a private fork is increasingly painful — the upstream codebase is actively developed and the conflict surface grows with every release.
This issue is an invitation to discuss which parts upstream would accept, and in what form.
What we have built
1. Project topic inbox
Aggregates L1 traces by topic, persists a project-scoped topic inbox with durable processing guarantees, idempotency keys, and conflict boundaries. Lets the memory system track what an agent is actually working on across sessions.
Key commits:
feat: add project topic inbox,feat(memory): aggregate L1 traces into project topics,feat(memory): persist project topic inbox,feat(api): expose project topic inbox2. Topic Decision system (multi-agent deliberation)
A full-stack feature: bounded decision sessions, multi-agent position synthesis, evidence gating, reversible action execution with double-confirmation, idempotent replay, conflict resolution, and a Viewer panel. Agents propose positions on a topic; the system synthesizes them into a decision with risk/assumption tracking.
Key commits:
feat(memory): synthesize bounded topic decisions,feat(topic-decision): implement multi-agent decision data-flow contracts,feat(memory): execute approved reversible topic actions,feat(memory): add topic decision console,feat(topic-decision): harden position generation and expose staged APIThis is the largest feature block — roughly 40 commits covering storage, service, HTTP contracts, and Viewer UI.
3. Memory Assets
A lifecycle for reusable named knowledge artifacts that persist across tasks: asset storage layer, loadout management, recall, temporal validity, evolution. REST API and full test coverage.
Key commits:
feat(memory): add asset/evolution storage layer,feat(memory): asset lifecycle, loadout, recall, temporal validity services,feat(memory): REST API for assets, loadouts, sequences, recalls, temporal validity4. Authoritative project context governance
A mechanism for designating one memory as the authoritative context pack for a project — the agent always loads it at session start. Desktop, Backend, and Agent endpoints wired. Context pack history view and token usage stats in the Viewer.
Key commits:
feat(memory): add authoritative project context,feat(backend): expose project context governance,feat(agent): preserve project context turn provenance,feat(desktop): add project context governance,feat: add context pack history and secure docker releases,feat: add context pack views and token usage stats5. MCP bridge for DeepSeek Harness
Full MCP integration: DSH source adapter with session discovery and zstd decode, DSH lifecycle tools, agent plugin that reads token from preset config, workspace auto-injection into opened sessions. Allows DeepSeek Harness sessions to write and read Memory through MCP without any manual config.
Key commits:
feat(memory): add MCP bridge for DeepSeek Harness integration,feat(memory): DSH source adapter - session discovery, zstd decode, import,feat(mcp): DSH lifecycle tools + agent plugin (Phase 2),feat(mcp): carry workspace into memories via auto-opened session6. Additional agent source integrations
Key commits:
feat: integrate OMP and FreeBuff agent sources,feat: add Pi memory integration,feat: add memmy-project-summarize skill7. L1 retrieval layer tuning
Exclude L1 memories from turn-start and intent retrieval layers to reduce noise in the agent context injection path.
Key commit:
feat(memory): exclude L1 from turn-start and intent retrieval layers8. Project-scoped review synthesis
A synthesis layer that reviews memories within a project scope and produces a consolidated insight.
Key commit:
feat(memory): add project-scoped review synthesis,feat: add scoped memory governance protocol9. Memory panel as standalone browser entry point
Deploy the Memory Viewer without the Electron wrapper — accessible as a plain web app. This is already how we run it in Docker.
Key commit:
feat(web): deploy Memmy browser entry point without Electron10. Inactive evolution memory lifecycle
Centralizes the lifecycle for memories that have stopped evolving — grading project evidence, archiving stale candidates cleanly.
Key commit:
feat(memory): centralize inactive evolution memory lifecycle and grade project evidenceOur ask
We are not asking upstream to accept all of it at once. We would prefer to discuss:
The features with the most value to the broader user base are probably Topic Decision (novel capability), Memory Assets (reusable knowledge across tasks), and authoritative project context (every power user wants this). The MCP/DSH integration and additional agent sources are more niche but add real coverage for users of those tools.
We are happy to rebase any of these cleanly onto the current
mainand open separate PRs. What we want to avoid is continuing to carry all of this as a private patch set forever.Context
Our fork: https://github.com/bluewatercg/memmy-agent
Branch with the work:
wip/pre-upstream-convergence-20260827Commits unique to our fork vs upstream
main: 148