Cross-project memory boundaries
TRW exposes several ways to reuse knowledge beyond one conversation, but they are not one automatic propagation pipeline. Choose the storage and network boundary deliberately: a project's own namespace, the machine-wide user:local namespace, explicitly shared standalone namespaces, or hosted team sync.
Four distinct surfaces
The word “sharing” can hide important implementation differences. This matrix states what exists today and what setup each surface requires.
MCP project memoryInspect
- Storage
- This project’s namespace (project_namespace in .trw/config.yaml) in the daemon’s store, by default ~/.trw/memory/memory.db
- Activation
- Default namespace for the checkout; recalled through explicit MCP calls
- Network
- Local database; models load from the local cache only and never download at runtime
- Boundary
- Does not discover sibling repositories automatically
Machine-wide user:local namespaceInspect
- Storage
- Same store as project namespaces, default ~/.trw/memory/memory.db; overridable through TRW_USER_DIR or XDG_DATA_HOME
- Activation
- Included in recall by default, capped at recall_user_tier_cap hits (default 5); learnings reach it through scope="user" or when scope="auto" classifies them as portable
- Network
- Machine-local
- Boundary
- Shared by every checkout on the machine; holds user-scope learnings, not other projects’ namespaces
Standalone shared namespace rootInspect
- Storage
- .memory/<namespace>/memory.db under one configured storage_path
- Activation
- Application explicitly co-locates namespaces; cross-validation needs embeddings
- Network
- Local filesystem
- Boundary
- A trw-memory capability, not automatic MCP repo-to-repo propagation
Hosted team syncInspect
- Storage
- Remote backend plus each participant’s local store
- Activation
- Explicit backend credentials and sharing/sync opt-ins
- Network
- Yes
- Boundary
- Background sync behavior is separate from delivery and session-start calls
| Surface | Storage | Activation | Network | Boundary |
|---|---|---|---|---|
| MCP project memory | This project’s namespace (project_namespace in .trw/config.yaml) in the daemon’s store, by default ~/.trw/memory/memory.db | Default namespace for the checkout; recalled through explicit MCP calls | Local database; models load from the local cache only and never download at runtime | Does not discover sibling repositories automatically |
| Machine-wide user:local namespace | Same store as project namespaces, default ~/.trw/memory/memory.db; overridable through TRW_USER_DIR or XDG_DATA_HOME | Included in recall by default, capped at recall_user_tier_cap hits (default 5); learnings reach it through scope="user" or when scope="auto" classifies them as portable | Machine-local | Shared by every checkout on the machine; holds user-scope learnings, not other projects’ namespaces |
| Standalone shared namespace root | .memory/<namespace>/memory.db under one configured storage_path | Application explicitly co-locates namespaces; cross-validation needs embeddings | Local filesystem | A trw-memory capability, not automatic MCP repo-to-repo propagation |
| Hosted team sync | Remote backend plus each participant’s local store | Explicit backend credentials and sharing/sync opt-ins | Yes | Background sync behavior is separate from delivery and session-start calls |
What delivery actually writes
Delivery can generate local topic documents under .trw/knowledge/ when the configured threshold is met. Those Markdown summaries are browsable project artifacts; they do not move memory records into sibling repositories or trigger hosted team sync.
Standalone trw-memory
The base package provides the local memory engine and defaults to .memory/<namespace>/memory.db and includes sqlite-vec vector storage. BM25 keyword ranking is part of the base install; dense embeddings are the optional[embeddings] extra.
pip install trw-memory
pip install "trw-memory[embeddings]"Cross-project graph validation in the standalone package operates across namespaces discovered beneath one configured storage_path and requires compatible embeddings. The MCP integration uses a different default layout, so switching between the two paths requires an explicit storage or migration decision.
Network and hosted controls
Hosted sharing is additive and opt-in. Usage telemetry and learning-content sharing are separate decisions; enabling one does not silently enable the other. The final row is a standalone-package control rather than a flat TRWConfig field.
- Control
learning_sharing_enabled- Default
- false
- Purpose
- Allows learning-content egress when hosted sync is configured
- Control
team_sync_enabled- Default
- false
- Purpose
- Allows pulled team-learning rows to merge into the local store
- Control
backend_url / backend_api_key- Default
- empty
- Purpose
- Select and authenticate the hosted backend
| Control | Default | Purpose |
|---|---|---|
learning_sharing_enabled | false | Allows learning-content egress when hosted sync is configured |
team_sync_enabled | false | Allows pulled team-learning rows to merge into the local store |
backend_url / backend_api_key | empty | Select and authenticate the hosted backend |
Limits by surface
- MCP memory reads only its own project namespace and user:local; it does not search other projects' namespaces in the same store.
- Standalone cross-validation requires co-located namespaces and compatible embeddings.
- The standalone package includes an optional SSE subscriber; that does not make MCP team sync real-time.
- Conflict graph and filter primitives can surface relationships, but no universal contradiction arbiter chooses the correct project fact.