🏗️ Architecture: How should Vitto handle long-running complex tasks that exce...

Date: 2026-03-19
Time: 14:20:49 UTC
Session: gspace1-238.8
Agent: backend
Confidence: 90%
Status: ✅ Documented

📋 Decision Context

Question:

How should Vitto handle long-running complex tasks that exceed CostGuard's 10-15 minute limit?

Task: Not specified

🎯 Decision Made

Chosen:

BackgroundTaskService with template-guided decomposition into bounded subtask chains. Each subtask runs through normal AgentLoopService with normal CostGuard. Templates (RESEARCH, CODE_REVIEW, GENERATE) provide structure; LLM fills specifics. Chain state persisted in MongoDB via ChainCheckpoint schema. REST controller for cancel/pause/resume.

Options Considered:

1. Remove CostGuard limits (dangerous)
2. Free-form LLM decomposition (unreliable)
3. Template-guided decomposition with bounded subtasks (chosen)
4. Single long-running process with higher limits

💭 Reasoning

Root cause: CostGuard exists for good reason (runaway LLM costs). A 2-hour Opus task could cost $50+. Instead of removing the guard, we add an orchestration layer that chains bounded subtasks. Template-guided decomposition (not free-form LLM decomposition) was chosen because LLM task decomposition is unreliable — known failure mode where bad decomposition wastes subtasks. Templates provide guardrails; the LLM fills in specifics within the template structure. MongoDB persistence (not just Redis) survives process restarts. BullMQ job dependencies chain subtasks naturally. Each subtask picks its own model via SmartRouter (Haiku for search, Sonnet for analysis) for cost optimization.

📁 Files Involved

• APIs/backend-vitto-api/src/app/engine/background-task.service.ts
• APIs/backend-vitto-api/src/app/engine/background-task.controller.ts
• APIs/backend-vitto-api/src/app/engine/schemas/chain-checkpoint.schema.ts

🔗 Related

• Decision ID: dev_1773930049534_bor800u
• Session: 238
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation