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: repo-local, machine-local, explicitly shared 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
- .trw/memory/memory.db in one repo
- Activation
- Default project store; recalled through explicit MCP calls
- Network
- Local database; embedding warm-up may fetch model artifacts unless cached or offline mode is set
- Boundary
- Does not discover sibling repositories automatically
Machine-local user tierInspect
- Storage
- Default ~/.trw/memory/memory.db; overridable through TRW_USER_DIR or XDG_DATA_HOME
- Activation
- Opt-in federated recall with a configured result cap
- Network
- Machine-local
- Boundary
- Shares selected user-scope memory, not arbitrary sibling .trw stores
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 | .trw/memory/memory.db in one repo | Default project store; recalled through explicit MCP calls | Local database; embedding warm-up may fetch model artifacts unless cached or offline mode is set | Does not discover sibling repositories automatically |
| Machine-local user tier | Default ~/.trw/memory/memory.db; overridable through TRW_USER_DIR or XDG_DATA_HOME | Opt-in federated recall with a configured result cap | Machine-local | Shares selected user-scope memory, not arbitrary sibling .trw stores |
| 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. Dense embeddings, sqlite-vec vectors, and BM25 support are optional extras, not base-install guarantees.
pip install trw-memory
pip install "trw-memory[embeddings]"
pip install "trw-memory[vectors,bm25]"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
trw-memory: memory_local_only- Default
- false
- Purpose
- Standalone-package control that denies memory-network access rather than merely omitting credentials
| 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 |
trw-memory: memory_local_only | false | Standalone-package control that denies memory-network access rather than merely omitting credentials |
Limits by surface
- Repo-local MCP memory does not crawl adjacent repositories for matching entries.
- 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.