Architecture: Should desktop/browser control move from backend-ai-api to b...

Documentation for Sessions

🏗️ Architecture: Should desktop/browser control move from backend-ai-api to b...

Date: 2026-02-11
Time: 20:06:21 UTC
Session: gspace1-106.6
Agent: backend
Confidence: 85%
Status: ✅ Documented

📋 Decision Context

Question:

Should desktop/browser control move from backend-ai-api to backend-vitto-api?

Task: Session 106: Vitto architecture - desktop/browser ownership

🎯 Decision Made

Chosen:

Move DesktopService and BrowserAutomationService into backend-vitto-api. Vitto is the primary consumer of these services (15/18 tools are file/command/browser operations). The double-hop (Vitto → backend-ai-api → DesktopService) adds latency for Vitto's most frequent operations. Backend-ai-api retains the infrastructure endpoints for other consumers (MCP, dashboard). Desktop daemon evolves as a remote bridge later.

Options Considered:

  1. Keep in backend-ai-api, Vitto calls via HTTP (current)
  2. Move DesktopService + BrowserAutomationService to backend-vitto-api
  3. Duplicate in both (redundant)
  4. Use desktop daemon as the bridge for both

💭 Reasoning

Analysis of gograb-desktop-daemon shows it's a POC not actively used by backend-ai-api. Backend-ai-api has DesktopService (child_process.exec + fs/promises) and BrowserAutomationService (Playwright) running locally. Vitto's InfrastructureClientService calls these via HTTP REST. Since Vitto's tool registry has 18 tools and most involve file/command/browser operations, every tool call pays the HTTP overhead. Moving these services into backend-vitto-api eliminates the hop. Backend-ai-api keeps its copies for MCP gateway consumers. This is the standard pattern: the primary consumer owns the capability.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation