Architecture: Should sessions be treated as temporal units (new session pe...

Documentation for Sessions

🏗️ Architecture: Should sessions be treated as temporal units (new session pe...

Date: 2026-03-27
Time: 14:28:11 UTC
Session: gspace2-0
Agent: storage
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Should sessions be treated as temporal units (new session per day/conversation) or as long-lived logical work groupings?

Task: Smart Session System v13.0 — session identity model

🎯 Decision Made

Chosen:

Sessions are long-lived logical work groupings. A session may span weeks. SubSessions are the temporal unit — each work stint (conversation, agent run) increments the sub. When resuming old work on a range branch, the system resolves to the same session number and increments the sub, rather than creating a new session.

Options Considered:

  1. A) Temporal sessions — new session per conversation
  2. B) Long-lived logical sessions with sub-session increments (CHOSEN)
  3. C) Hybrid — auto-create new session after 7 days of inactivity

💭 Reasoning

The owner observed that agents were creating new sessions when they should have continued existing ones. The fundamental insight: a session groups related work logically (e.g., 'implement email tombstones'). When an agent returns to the same branch weeks later, it should pick up the same session with a new sub-session, preserving the logical grouping. This is why the resolver uses most-recent commit tags on range branches — it finds which session was last active and continues it. Creating new sessions should be an explicit act (sessionNumber: 'new'), not an accident of forgetting the number.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation