Scope agent memory/climate to project so one agent can work across groups without context bleed

[kejiali]

Summary

When the same agent participates in multiple groups (projects), its memory,
climate, and persona are keyed only to agent_id — they are global across all
conversations. Only the raw message thread is scoped per conversation (via
conversation_reads). The result: an agent working in group B "remembers" and
acts on the context from group A, mixing its group A work into group B.

This makes running several independent projects with the same agent set
impractical. Today you either accept the bleed, manually wipe memory files, or
spin up a separate agent per project (N projects → N agents) even when the
underlying LLMs are identical.

Concrete symptom (BYOA)

Agent nova sits in multiple project groups. Its memory index
(~/.cumora/agents/<id>/memory/MEMORY.md) ends up indexing five unrelated
projects (paper review, article review, PPT repo, OpenRouter plan, …). In a new
group about one project, nova reads all five and treats the others as
background — exactly the "agent1 in group2 treats its group1 work as
background" symptom.

Root cause

• agent_memory / agent_workspace (memory) are keyed by agent_id only
  (server/src/db/migrate.ts).
• Retrieval in server/src/agents/runtime/inproc-client.ts (loadMemory)
  filters only agent_id + path LIKE 'memory/%' — no project/conversation
  dimension.
• Climate (loadClimate) is likewise per-agent and global.
• projects + conversations.project_id exist, and the wake prompt already
  surfaces "Project: " to the agent — but that is a label, not an
  isolation boundary.
• The plumbing to fix this already exists: agent_memory.source stores
  conversationId, and conversations.project_id links a conversation to a
  project — it is just not used to filter memory.

Why the current workarounds are painful

1. Manual wipe (documented in COORDINATION.md under "memory pollution"):
   read each memory file, delete the overfit ones, re-wipe every time pollution
   re-accumulates.
2. One agent per project: for N projects you maintain N agents (and their
   homes) even though you may only have 2 underlying LLMs — defeating the point
   of a reusable agent identity.

Proposed fix

Add a scope dimension to memory and filter retrieval on the current
conversation's project (fall back to global when a conversation has no project):

1. Add nullable project_id to agent_memory / agent_workspace, or derive it
   from source.conversationId → conversations.project_id.
2. In loadMemory, join the current conversation(s) to their project and
   include global memories + the current project's memories, excluding other
   projects'.
3. Optionally scope climate the same way (or keep it global and document the
   tradeoff).
4. For BYOA, scope the injected MEMORY.md digest / memory-directory read to
   the current conversation's project.

Related

I did not find an existing issue or discussion covering cross-group context
isolation or per-project memory scoping. This is distinct from the documented
agent↔agent isolation (separate home dirs), which works fine — the gap is
within a single agent across groups.

[WhichPaths]

This looks fully addressed on main now — server/src/agents/memory-scope.ts is the shared write/filter contract, and its header states the same design this issue proposed. Mapping the four asks to where each landed:

1. "Add nullable project_id … or derive it from source.conversationId → conversations.project_id" — the derive option. Provenance is carried in meta.source ({conversationId, projectId}, via buildMemorySource / pickWriteProvenance) and mirrored in the path layout:

memory/MEMORY.md                        global index (legacy location)
memory/projects/<projectId>/MEMORY.md   per-project index
memory/projects/<projectId>/<kind>/<id>.md

2. "loadMemory … include global + current project, excluding other projects" — loadMemory takes scope: { projectIds, conversationIds }, resolves it through resolveMemoryScope, filters in SQL (memoryScopeSql) and again in code (memoryVisibleInScope). The truth table is written out in the module header, including the case this issue's symptom describes:

pinned                            → always visible
no project on the row             → always visible (global, including legacy)
project P, wake in P              → visible
project P, wake in Q              → hidden
project P, no-project conversation → hidden
wake spanning P and Q             → P and Q visible; other projects hidden

3. "Optionally scope climate … or keep it global and document the tradeoff" — the second option, taken deliberately and documented: "Persona / climate / skills are NOT in this file on purpose: they are loaded by dedicated paths (loadClimate, loadSkillsIndex, persona) that stay per-agent and global."

4. "For BYOA, scope the injected MEMORY.md digest" — the concrete symptom in the report, and the one that needed the daemon rather than the server. memoryDigest(projectIds) in computer/daemon.ts, and the standing prompt now says what it is handing over: "Your memory index (global memory/MEMORY.md + current project, if any)".

One deliberate limit worth flagging for anyone hitting the original nova symptom on an existing install: memories written before this have no project provenance, and the module refuses to backfill them — "Existing rows/files with no project provenance stay GLOBAL. This module never migrates old memories into a project — that would be fake isolation." So an index that already accumulated five unrelated projects stays global until those entries are rewritten; isolation applies from here forward. That may be worth a line in the docs, but it is a decision rather than a gap.