Skip to content

DR-002: Per-agent cwd model for memory namespace isolation

Status

Accepted — 2026-04-14 · CEO-approved during Jordan's kickoff preparation

Context

Claude Code scopes memory files to the current working directory (cwd). Each cwd gets its own memory namespace at /Users/rhartley/.claude/projects/{cwd-slug}/memory/. When multiple agents run in the same cwd, they share a memory namespace — which means their feedback, preferences, and project context cross-pollute.

During the v1.2 migration, chief.staff discovered that Jordan's production memory had 44 files at the old /ecomonetize/Project.Manager/ path. If Jordan launched from any cwd within /Claude/, he'd start amnesiac — old memory doesn't follow the cwd change.

The question: where should each agent launch from, and how isolated should their memory namespaces be?

Decision

Every Active agent launches from its own dedicated cwd at /Claude/sessions/{agent.id}/. Memory namespaces are scoped per-agent, stored at /Users/rhartley/.claude/projects/-Users-rhartley-Claude-sessions-{agent.id}/memory/.

Pattern: - chief.staff → /Claude/sessions/chief.staff/ - project.manager → /Claude/sessions/project.manager/ - code.platform → /Claude/sessions/code.platform/ - ... etc., one folder per agent

The sessions/ folder at vault root exists specifically to anchor memory namespaces. Agents do their real work in the shared vault (/missions/, /plans/, /operations/, /system/, /knowledge/) — the session folder is just the cwd anchor, not the workspace.

Alternatives considered

Option A — Shared root cwd (/Users/rhartley/Claude/)

All agents launch from the vault root. Memory namespace is -Users-rhartley-Claude.

Rejected. All 21 agents would share one memory namespace. chief.staff's "plain-text section notation" feedback and Jordan's "no live debugging" feedback and code.platform's "schema naming discipline" feedback would all end up in the same folder. Personality bleed. The MEMORY.md index would exceed ~200 lines (truncation threshold) and drop content silently.

Option B — Per-agent cwd (this decision)

Accepted. Clean separation, scalable to 21+ agents, matches the mental model of agents as independent operators.

Option C — Per-department cwd (e.g., /Claude/system/agents/executive/)

Agents in the same department share a memory namespace.

Rejected. chief.staff and project.manager would still share, just with fewer cross-department collisions. Doesn't fully solve the personality-bleed problem, and adds complexity (department-level vs. agent-level routing).

Consequences

What becomes easier: - Memory migration is clean: each agent's production memory migrates to its own new namespace - No personality bleed between agents - Kickoff pattern is uniform: create sessions/{agent.id}/, migrate or greenfield memory, launch from there - Each agent's MEMORY.md index stays short and complete - The aifactory-menu launcher can validate per-agent directory existence as a kickoff signal

What becomes harder: - 21 memory namespaces to maintain (vs. 1 shared) - Cross-agent memory references require explicit paths (not implicit via shared namespace) - The sessions/ folder adds a layer at the vault root

Trade-off accepted: More folders + more namespaces in exchange for clean agent isolation and scalable kickoff patterns.

Exception currently in effect

chief.staff is the exception as of 2026-04-14 — she was already running from a legacy namespace at /Users/rhartley/.claude/projects/-Users-rhartley-Claude-system-agents-executive/memory/ before this decision was made. A placeholder directory at /Claude/sessions/chief.staff/ exists for launcher compatibility, but the actual memory migration is deferred to a natural session break to avoid mid-session context drift.

  • [[CLAUDE]] Section 14 — /Claude/sessions/ included in the folder tree
  • [[agent-memory-migration-protocol]] — the execution protocol for cutovers
  • [[/Claude/sessions/README]] — documents the pattern
  • Jordan's cutover QA report (first successful cutover under this model)

2026-04-16 Amendment (DR-012)

Per-agent cwd memory isolation is not natively supported by Claude Code's auto-memory under the grid launch pattern. Root cause confirmed via SEV2 incident INC-2026-04-15-harness-memory-namespace-fallback: VS Code workspace root determines memory namespace, not terminal cwd. When Rick runs grid N, all panes share VS Code workspace = /Claude/, so all agents load the same auto-memory namespace regardless of their per-agent session dir.

The isolation principle is preserved via convention, not harness enforcement:

  • Shared namespace at -Users-rhartley-Claude/memory/ is now the read-only governance baseline — Rick's preferences, feedback rules, reference pointers, system-wide project context. Maintained by chief.staff (Eva). Agents inherit this content on every session start. Agents do NOT write to this namespace.
  • Per-agent working context lives in /Claude/sessions/{agent.id}/memory-notes.md — each agent reads at session start and writes at session end. These files are agent-maintained, not auto-loaded by the harness.

What this changes from the original DR-002: - The sessions/{agent.id}/ directories still exist and serve as cwd anchors (unchanged) - Per-agent memory at -Users-rhartley-Claude-sessions-{agent}/memory/ directories are decommissioned — they contain forensic artifacts from the SEV2 mitigation phase and do not affect harness behavior - Memory isolation is enforced by convention (agents write to memory-notes.md, not to auto-memory) rather than by the harness - MEMORY.md in the shared namespace is curated by chief.staff as a governance artifact, not an ad-hoc write target

See DR-012 at /Claude/knowledge/decisions/DR-012-shared-governance-baseline-plus-session-dir-context-files.md for the full model specification.


Date: 2026-04-14 · Author: chief.staff · Stakeholders: ceo, chief.staff · Amended: 2026-04-16 (DR-012)