Architecture: Session 180 Phase 2: How to make Vitto smarter per message a...

Documentation for Sessions

🏗️ Architecture: Session 180 Phase 2: How to make Vitto smarter per message a...

Date: 2026-03-06
Time: 15:58:07 UTC
Session: gspace1-180.9
Agent: storage
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

Session 180 Phase 2: How to make Vitto smarter per message across 4 intelligence dimensions (history, suggestions, model memory, degradation awareness)?

Task: Phase 2: Intelligence improvements for Vitto chat

🎯 Decision Made

Chosen:

Four intelligence upgrades: (1) Genome-aware history: new GET /sessions/:id/genome endpoint + frontend getIntelligentHistory() that sends compressed genome (~500 tokens) + last 5 raw messages instead of 10 raw messages (~5000 tokens). 5-10x token efficiency. (2) Two-tier LLM suggestions: regex fallback shows instantly, Haiku-generated contextual suggestions replace them ~300ms later via POST /sessions/suggestions. (3) Model persistence: localStorage save/restore so preferred model survives reload. (4) Routing mode signal with header badge showing 'Direct mode' when Vitto engine unavailable.

Options Considered:

  1. Full genome endpoint with lazy compilation (chosen)
  2. Send all messages and let backend compile inline (too slow — adds 1s per message)
  3. Client-side genome compilation (requires LLM call from browser — impractical)
  4. Cache genome in IndexedDB alongside sessions (added complexity for marginal gain)

💭 Reasoning

Intelligence gaps identified during Phase 1 exploration: (1) History: getRecentHistory() just sliced last N messages — no relevance filtering, no token awareness, no genome integration. ConversationGenomeService already had compile() and hydrate() but was never wired to the frontend chat engine. The genome endpoint caches per session and falls back gracefully. (2) Suggestions: regex patterns ('ends with ?' → Yes/No) are embarrassingly simplistic. Haiku costs ~$0.00005 per suggestion call and returns in ~300ms — cheap enough for every response. The two-tier approach means zero latency regression (regex still shows instantly). (3) Model: VittoChatModelService had no persistence — signal(defaultModel) reset on every reload. Users who prefer Opus or Haiku had to re-select every time. localStorage is synchronous, instant restore. (4) Degradation: Silent fallback from Vitto (30+ tools, memory, multi-agent) to direct AI API (basic chat) with zero user indication. The routingMode signal tracks state, auto-recovers on next successful Vitto response, and the system message explains feature limitations.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation