Architecture: Session 180: How to build Vitto's Awareness Hub — the connec...

Documentation for Sessions

🏗️ Architecture: Session 180: How to build Vitto's Awareness Hub — the connec...

Date: 2026-03-05
Time: 21:02:24 UTC
Session: gspace1-178.4
Agent: backend
Confidence: 92%
Status: ✅ Documented


📋 Decision Context

Question:

Session 180: How to build Vitto's Awareness Hub — the connective tissue that makes Vitto persistently aware across all surfaces?

Task: Not specified


🎯 Decision Made

Chosen:

Channel-based Awareness Hub on backend-vitto-api. AwarenessChannel interface mirrors frontend ChatPlugin pattern. 4 independent channels: ComputerUseBridge, SessionMemory, Routine, Proactive. Hub multiplexes with lazy activation, 2s timeout, priority budgeting (max 5 events). Integrated into ContextAssemblyService parallel fetch block. Frontend AwarenessDataService via Socket.IO. Observatory visibility via Prometheus metrics.

Options Considered:


💭 Reasoning

Three approaches considered: (1) Monolithic awareness service — rejected because codebase already has strong separation (EventBusService, ChannelGatewayService). (2) Event-sourced — rejected as over-engineered; existing EventEmitter2 + GoalHistory serve the purpose. (3) Channel-based hub — chosen because it mirrors the frontend ChatPlugin pattern the team already uses, enforces lazy activation (performance), keeps channels independent (maintainability), and uses existing infrastructure (EventBusService, ChatGateway Socket.IO, CostGuard, CircuitBreaker). The AwarenessChannel interface is the same composable pattern: initialize/activate/deactivate/getMetrics/destroy. Each channel is independently testable and can be disabled via config.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation