🏗️ Architecture: How should Vitto's Sub-Vitto parallel execution engine be ar...

Date: 2026-03-18
Time: 16:37:07 UTC
Session: gspace1-234.3
Agent: backend
Confidence: 90%
Status: ✅ Documented

📋 Decision Context

Question:

How should Vitto's Sub-Vitto parallel execution engine be architected?

Task: S234: Jarvis Evolution Phase 1 - Sub-Vitto Engine

🎯 Decision Made

Chosen:

Refactored SubAgentService.executeTask() to delegate to AgentLoopService.run() instead of maintaining its own while loop. Created SubVittoOrchestratorService for parallel dispatch via Promise.allSettled() with concurrency limits. Added deploy_agents tool plugin. Used SubVittoSSEProxy to scope SSE events with subvitto.* prefix. Added frontend SubVittoOrchestrationRenderer.

Options Considered:

• No alternatives documented

💭 Reasoning

The existing SubAgentService had a duplicated ~160-line while loop that bypassed stuck detection, checkpoints, parallel tool calls, and SSE streaming. By refactoring to use AgentLoopService.run(), sub-agents get all engine features for free ("one engine, N contexts"). The orchestrator uses Promise.allSettled() for simplicity — no need for complex orchestration frameworks. SSE proxy prevents sub-Vitto events from polluting the main stream. Recursion depth guard (max 1) prevents infinite sub-Vitto spawning.

📁 Files Involved

• APIs/backend-vitto-api/src/app/engine/sub-vitto-orchestrator.service.ts
• APIs/backend-vitto-api/src/app/engine/sub-vitto-sse-proxy.ts
• APIs/backend-vitto-api/src/app/engine/sub-agent.service.ts
• APIs/backend-vitto-api/src/app/tools/plugins/orchestration.plugin.ts

🔗 Related

• Decision ID: dev_1773851826908_08v62jz
• Session: 234
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation