Shared KB/MC Team Deployment MVP

Context

Epic #9999 already tracks cloud-native Knowledge Base and multi-tenant Memory Core work. The original topology plan intentionally supported both unified local ChromaDB and federated cloud ChromaDB so the MCP servers could run in isolation.

The near-term product need is narrower and more urgent: teams using agent harnesses across multiple developers need a shared Knowledge Base and Memory Core source of truth. The current per-developer local setup lets each developer's agents build stale, isolated KB/MC state. A team deployment should let agents discover summaries and raw memories produced by other team agents while preserving provenance and session boundaries.

This sub-epic defines the MVP slice under #9999. It deliberately avoids naming any private customer or deployment partner.

The Problem

The existing local-first pattern couples too much operational meaning to local process boundaries:

• KB and MC can point at separate ChromaDB processes even when a shared team deployment only needs one Chroma service with separate collections.
• Memory Core currently treats the server process as the default session owner (currentSessionId at boot), which breaks down for remote MCP servers, pooled MCP servers, and our own local harness reality where multiple MCP server instances can be started by one agent harness.
• Summarization can be triggered by server lifecycle instead of an explicit session lifecycle, causing duplicate or stale summary behavior when multiple MCP server instances observe the same shared data.
• Team-wide retrieval is only partially tracked by #10010 and needs to be positioned inside an MVP that prioritizes shared provenance over final enterprise isolation.

The Architectural Reality

Current relevant anchors:

• #9999 is the parent cloud-native KB/MC epic.
• #10015 tracks the earlier unified-vs-federated Chroma topology split.
• #10001 and #10007 are closed plumbing tickets for unified topology.
• #10008 remains open for unified monolithic topology validation.
• #10009 remains open for federated cloud topology validation, but federated Chroma should likely be demoted or superseded if the supported MVP path becomes one shared Chroma process.
• #10010 tracks Team vs Private Context Retrieval.
• #10011 remains the stronger Native Edge Graph tenant-isolation track and is not required for the first shared-memory MVP if graph/mailbox usage stays quiet.

Design stance for this MVP:

• One shared Chroma process by default for KB + MC.
• Separate Chroma collections remain the data boundary (neo-knowledge-base, neo-agent-memory, neo-agent-sessions, etc.). Do not collapse collections.
• Two MCP servers remain as protocol/tool surfaces, but they should no longer require separate Chroma process ownership.
• Session identity is client/logical-run scoped, not Memory Core server-process scoped.
• Summarization is coordinated by explicit session lifecycle state, not by whichever MCP server process happens to boot.

The Fix

Use this sub-epic to coordinate a compact team-sprint roadmap:

1. Standardize shared Chroma as the supported MVP deployment path for KB + MC while keeping collection boundaries.
2. Add a client-scoped Memory Core session lifecycle contract so remote/shared MCP server deployments do not depend on process-global currentSessionId state.
3. Add a summarization coordinator / queue so session summaries are generated once from finished sessions, with in-progress leases and retry/expiry behavior.
4. Position #10010 as the team/private retrieval policy layer; MVP can default to team-readable memory with author/session provenance.
5. Document and validate a shared deployment profile: shared Chroma, two MCP servers, local embedding/chat provider endpoints, healthcheck expectations, and migration notes from per-developer local mode.

Acceptance Criteria

• The MVP roadmap has native sub-issues for client-scoped sessions, summarization coordination, and shared deployment validation.
• Existing #10008 and #10010 are linked or referenced as part of the MVP path.
• #10009 is explicitly reviewed for supersession, demotion, or non-default diagnostic scope once shared-Chroma-default is confirmed.
• The roadmap states that one Chroma process does not mean one Chroma collection.
• The roadmap states that local and remote deployments use the same logical session contract.
• The roadmap avoids customer-specific naming and remains public-repo safe.

Out of Scope

• Full DreamService graph-processing rollout in external infrastructure.
• Final tenant isolation for the Native Edge Graph (#10011), unless graph/mailbox content becomes active in the MVP.
• A GitLab-specific support connector for forwarding private feature requests into public Neo tickets.
• Prompt-injection security hardening beyond documenting the risk as a follow-up lane.
• Removing all historical federated-topology code paths in this sub-epic; supersession can be handled by a dedicated cleanup ticket if approved.

Avoided Traps / Gold Standards Rejected

• Rejected: keep federated Chroma as a first-class MVP mode. It increases the test matrix and operator complexity without serving the immediate shared source-of-truth need.
• Rejected: one collection for all data. Separate collections are still the correct boundary for query semantics, migration safety, and future retention policy.
• Rejected: server-process session identity. It is already false in local harness reality and becomes unsafe in shared remote deployments.
• Gold standard retained: server-stamped identity. OAuth/OIDC identity should remain provider-agnostic and server-derived, not client-supplied.

Related

• Parent: #9999
• Existing topology sub-epic: #10015
• Unified topology validation: #10008
• Federated topology validation candidate for supersession/reframe: #10009
• Team/private retrieval policy: #10010
• Native Edge Graph tenant isolation: #10011
• Concept ontology parallel lane: #10030

Origin Session ID: d9cd4943-3285-47a6-b629-c05a9a2a38e4

Retrieval Hint: "shared KB MC team deployment MVP client scoped session summarization coordinator unified Chroma"