Architecture: What is the architecture strategy for making Vitto a Jarvis-...

Documentation for Sessions

🏗️ Architecture: What is the architecture strategy for making Vitto a Jarvis-...

Date: 2026-03-17
Time: 18:28:46 UTC
Session: gspace1-229.11
Agent: architecture
Confidence: 88%
Status: ✅ Documented


📋 Decision Context

Question:

What is the architecture strategy for making Vitto a Jarvis-like persistent AI agent?

Task: Vitto Jarvis architecture strategy and competitive analysis


🎯 Decision Made

Chosen:

Three-pillar strategy: (1) Ship existing Tauri desktop app as always-on daemon with heartbeat, (2) Enhance remote CU with persistent browser sessions via VM snapshots + OAuth credential delegation, (3) Build browser extension relay for controlling existing Chrome tabs. 4-phase roadmap from shipping existing code to Jarvis parity. Key insight: vitto-local-bridge and vitto-desktop already exist in codebase — the gap is deployment/daemon lifecycle, not code.

Options Considered:

  1. Build everything from scratch
  2. Fork OpenClaw and adapt
  3. Three-pillar strategy: ship existing + enhance remote + browser relay

💭 Reasoning

Comprehensive competitive analysis of 15+ AI agent products (OpenAI Operator/ChatGPT Agent, Google Mariner, Anthropic Cowork, Microsoft Copilot Studio, Simular, Perplexity Computer, Rabbit DLAM, etc.) combined with architecture pattern research (persistent browser sessions, credential management, always-on agents, VM snapshots). Found that nobody has nailed the full Jarvis vision yet. Vitto's unique position is cloud intelligence + local presence + continuous learning. The Tauri app (S141, S191.3) already exists with 13 tools, system tray, global hotkey, auto-updater — it just needs daemon mode and hardening. Remote infrastructure needs Browserbase-style persistent browser contexts (achievable via existing Firecracker snapshots) and Composio-style OAuth delegation.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation