Architecture: How to unify 8 different session types (chat, agent, task, h...

Documentation for Sessions

🏗️ Architecture: How to unify 8 different session types (chat, agent, task, h...

Date: 2026-03-27
Time: 14:28:40 UTC
Session: gspace2-0
Agent: backend
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How to unify 8 different session types (chat, agent, task, handoff, VM, A2A, task-queue, dev) across the platform without rewriting each system?

Task: Smart Session System v13.0 — unified session architecture

🎯 Decision Made

Chosen:

SessionLink graph — a lightweight linking layer in MongoDB that connects sessions across layers via parent-child relationships, without modifying existing session code. Each system continues to work independently; links are additive enrichment. Traverse links to reconstruct full chains (chat -> task -> handoff -> agent).

Options Considered:

  1. A) SuperSession monolithic wrapper around all session types
  2. B) SessionLink graph — additive linking layer (CHOSEN)
  3. C) Unified session table with type discriminator
  4. D) Do nothing — keep session types isolated

💭 Reasoning

A monolithic 'SuperSession' wrapper would require every system to know about the wrapper — high coupling, high risk, each system would need migration. The graph approach is additive: create a SessionLink when a relationship is established (task from chat, handoff from task), and traverse later. Each existing system (chat sessions, Vitto tasks, handoffs, VM sessions) continues working independently. The linking layer is optional — if it fails, nothing breaks. This follows the 'strangler fig' pattern: add new capability around existing systems rather than replacing them. The graph naturally handles the complexity (one chat can spawn multiple tasks, one task can create multiple handoffs) without forcing a hierarchical model.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation