Grilling: what does continuous episodic-memory organization mean?

[antejavor]

Part of #259

Question

actions-graph already writes structured Session/Action/FOLLOWED_BY at capture time (per-action, synchronously, via hooks). Given that, what would a background "organize episodic memory" job actually DO that capture doesn't already do?

Candidates to grill through: consolidating raw actions into higher-level named episodes/summaries (like the old ai-memory.md demo's Interaction {summary: "kickoff"}); computing/caching "what happened last time" style rollups; something else entirely. Resolve with the driving user via /grilling + /domain-modeling.

[antejavor]

Resolution

Episodic-memory organization resolves to a narrow, concrete mechanism, reached via /grilling + /domain-modeling with the driving user:

The core distinction that unlocked this: actions-graph's raw (:Action) capture (as it works today, synchronously via hooks) is collection-tier, not memory — it's ephemeral observability data, explicitly separate from memory-tier data (the clean, distilled, durable output). This collection-vs-memory split is a general principle that also applies to sessions-graph's and skills-graph's raw inputs, not just actions-graph (see the new ticket this spawned, linked below).

Concrete design for episodic, specifically:

• No new node type, no new domain term "Episode." actions-graph/CONTEXT.md's existing vocabulary (Session, Action) is sufficient — introducing "Episode" as a 1:1 synonym for Session would just be noise.
• A background job — reusing the unstructured2graph-style reconciliation mechanism sessions-graph already has (see Research: what does sessions-graph's existing reconciliation actually write today? #260's findings), triggered the same way (on SESSION_END, like today's reconciliation_status='pending' pattern) — produces a narrative summary property (plus a status/provenance field, e.g. episodic_summary_status/summarized_at) written directly onto the existing (:Session) node once a session completes.
• That Session.summary is the episodic memory — the thing a "what happened last time?" recall query actually reads. Raw Action data remains available for observability/analytics in the interim but is explicitly not memory itself.
• Cross-session narrative stitching (one episode spanning multiple sessions) is explicitly out of scope — episode = exactly one Session, since Session is already the load-bearing boundary every other context-graph component keys off (HAS_ACTION, PRODUCED_MEMORY, USED_SKILL all hang off session_id). Solving session-clustering/thread-stitching is a separate, harder problem this ticket doesn't need to block on.
• Raw Action deletion/retention timing (when collection-tier data actually gets deleted once distilled) is deliberately not decided here — split out to a new ticket, since it's a cross-cutting concern across all three collection layers (actions-graph, sessions-graph, skills-graph), not episodic-specific.

[antejavor]

Reversal

During implementation (PR #271), the driving user revisited this ticket's "no new node" decision and reversed it: episodic memory is now a real (:Episode {summary, summarized_at}) node, linked via (:Session)-[:HAS_EPISODE]->(:Episode) (MERGEd on the relationship pattern, so re-reconciling updates the one Episode rather than accumulating duplicates), instead of summary/summarized_at properties directly on (:Session).

Rationale for the reversal: matches this codebase's existing pattern of dedicated node types for owned data (Memory, Action, Chunk) rather than growing Session's own property set indefinitely. The original "Episode = redundant synonym for Session" concern was about introducing the term without a structural reason; a real node with its own properties, reached via a named relationship, isn't that.

Everything else this ticket resolved is unchanged: episode = exactly one Session (no cross-session stitching), produced by the same reconciliation pass/trigger as semantic extraction, no separate schedule.