Architecture: How should the AI frontend libraries be organized to separat...

Documentation for Sessions

🏗️ Architecture: How should the AI frontend libraries be organized to separat...

Date: 2026-02-17
Time: 21:31:48 UTC
Session: gspace1-112.2
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should the AI frontend libraries be organized to separate concerns between Vitto (orchestrator), AI Panel (universal interface), and Space Agents (per-space)?

Task: Session 112: AI library architecture restructuring — vitto-hub, ai-panel-core, space-agents separation

🎯 Decision Made

Chosen:

Three-library architecture: (1) @libs-ai/vitto-hub for Vitto's mind/command hub only, (2) @libs-ai/ai-panel-core for the universal AI chat interface, (3) @libs-ai/space-agents (planned) for per-space dedicated agents. Each talks to distinct backends.

Options Considered:

  1. Consolidate everything into one library
  2. Two libraries (vitto-hub + ai-panel-core)
  3. Three libraries (vitto-hub + ai-panel-core + space-agents)
  4. Keep scattered across existing libraries

💭 Reasoning

The original space-assistant library mixed three unrelated concerns: Vitto's orchestration dashboard, the universal AI chat panel, and space-specific agent functionality. This caused confusion about what belongs where and created wrong coupling. Vitto is the orchestrator/mind (Jarvis) — talks to backend-vitto-api. The AI Panel is the universal interface for ALL AI interactions — talks to backend-ai-api + backend-api + backend-vitto-api. Space Agents are per-space dedicated agents — talk to backend-ai-api/space-agents. Each has distinct data ownership, lifecycle, and backend dependencies. Confirmed by code analysis: backend-vitto-api delegates DOWN to backend-ai-api via connectivity services (backend-ai-client.service.ts, infrastructure-client.service.ts, handoff-ws-client.service.ts).

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation