S240: Unified Autonomy Engine — Technical Session Documentation

Session: 240 Date: 2026-03-19 Branch: session-238-239 (concurrent with S239 Memory v2) Status: Complete — 65/65 E2E tests, 0 type errors

Executive Summary

Session 240 built the Unified Autonomy Engine — the system that makes Vitto act like a 24/7 intelligent partner rather than a reactive chatbot. It fuses three previously disconnected concerns into one coherent decision pipeline:

1. VM Execution — Vitto can now run commands, install packages, and manage files on isolated Firecracker VMs per user
2. Adaptive Trust — Vitto earns autonomy through proven reliability, not static role assignments
3. Proactive Intelligence — Vitto learns recurring patterns and acts before being asked

Architecture Overview

The Autonomy Gate (Central Innovation)

Every Vitto action flows through an AutonomyGateService that assembles a read-only snapshot:

User message → AutonomyGate.evaluate(task) → {
  trust:  TrustScoringService.getScore(userId, domain)    // independent
  tier:   TierResolverService.resolve(task, trust)         // reads trust
  action: ActionDecider.decide(trust, tier, task)          // reads both
} → Route to execution tier → Execute → Outcome feeds trust

Design principle: Three independent services, one gate. No god object. Each concern evolves independently. The gate is the only place they meet.

Key Files Created

Schemas Created

Phase-by-Phase Breakdown

Phase 0: Configuration (Task 0.1)

• Added environment variables: VM_WARM_POOL_SIZE, VM_SESSION_TTL_MINUTES, TRUST_ESCALATION_CAP_DAYS
• Created MongoDB collections with indexes: compound on (userId, domain) for trust, TTL on checkpoints

Phase 1-2: Infrastructure Layer (Tasks 1.1, 2.1)

• Sandbox-Orchestrator: Added structured file operations controller (read/write/list files on VMs via HTTP)
• Backend-AI-API: Added 9-endpoint sandbox proxy controller that relays requests from vitto-api through ai-api to sandbox-orchestrator, preserving the existing SandboxProvider abstraction and circuit breaker

Phase 3: VM Execution Layer (Tasks 3.1–3.5)

VmApiClientService — HTTP client with retry + circuit breaker to ai-api's sandbox proxy. Handles:

• createSession, restoreSession, snapshotSession, destroySession
• executeCommand, readFile, writeFile, listFiles

VmSessionManagerService — Per-user VM lifecycle:

• Each user gets a snapshot-based 2GB micro-space
• First use: cold boot (~10s) + credential injection
• Subsequent uses: snapshot restore (~500ms) — credentials persist in snapshot
• Idle timeout: snapshot + suspend (configurable, default 15min)
• 10x cost reduction vs always-on (20GB peak vs 200GB)

SandboxedToolProxyService — The #1 blocker that was closed:

• When a sub-Vitto tool call needs VM tier, intercepts run_command/write_file/read_file
• Routes to VmSessionManagerService → VmApiClientService → ai-api → sandbox-orchestrator → VM
• Sticky claim: first tool pays ~500ms, subsequent tools reuse same VM
• Release on task completion

VmCredentialInjectorService — First-time setup:

• Injects deploy keys, git config, npm tokens, environment variables
• Only runs once per user snapshot — subsequent restores have credentials

Wiring (Task 3.5):

• SubVittoOrchestratorService reads tier from AutonomyContext
• AgentLoopService tool execution checks SandboxedToolProxyService before local ProcessSandboxService
• Fallback chain: if VM unavailable, degrade to in-process for safe tools

Phase 4: Adaptive Trust (Tasks 4.1–4.5)

TrustScore schema: Materialized in MongoDB, updated event-driven (not computed live):

{ userId, domain, score: 0-100, level: OBSERVE|SUGGEST|DIRECT|AUTONOMOUS,
  recentOutcomes: [...last 50], lastEscalation, trajectory }

Scoring algorithm:

• Complex success: +3 points, simple success: +1
• Recency decay: outcomes >30 days weighted at 0.5x
• Critical failure: immediate drop (destructive action user had to undo)
• Escalation cap: max +1 level per 7 days (trust earned slowly, lost quickly)
• User's preferredAutonomyLevel is a floor, not a ceiling

Domain isolation: Trust for code_execution ≠ trust for search_docs ≠ trust for send_message. A user can be AUTONOMOUS for doc search but SUGGEST for code execution.

Wiring:

• OutcomeFeedbackService → TrustScoringService (event-driven update after each outcome)
• AutonomyGateService → TrustScoringService (reads materialized score, ~1ms)
• SubVittoOrchestratorService → reports sub-Vitto outcomes (cross-agent learning)

Phase 5: Proactive Intelligence (Tasks 5.1–5.2)

TriggerPattern schema (stored in vitto_triggers, NOT VittoMemory):

{ pattern, action, confidence: 0-1, userId, spaceId,
  activations, suppressedCount, lastTriggered }

Detection: After each task completion, checks: "has this user asked for similar things 3+ times in 14 days?" If yes, creates pattern with confidence 0.5.

Lifecycle:

• Confirmed by user engagement → confidence increases
• Dismissed by user → confidence decreases
• Below 0.3 → auto-deleted
• Above 0.8 → eligible for AUTONOMOUS execution (if trust allows)

Why not VittoMemory: S239's admission control scores on factualConfidence and semanticNovelty. Trigger patterns are predictions (low factual) that repeat (low novelty) — they'd be quarantined.

Phase 6: Resilience (Tasks 6.1–6.3)

TaskRecoveryService — Genome-based checkpoints:

• After each tool execution: persist ConversationGenome (~500 tokens) + last 3 tool results + VM snapshot ID
• On crash recovery: BullMQ picks up task → detect checkpoint → inject genome as resume context
• TTL 24h auto-cleanup (no checkpoint accumulation)
• 100x smaller than raw message replay (~500 tokens vs ~50K)

Agent Nesting — Depth-2:

• MAX_DEPTH bumped from 1 to 2
• Depth-2 constraints: in-process only, 50% parent budget, max 3 tools
• Prevents resource explosion: 8 × 8 = 64 VMs impossible with in-process constraint
• Enables real decomposition: code reviewer spawns test runner, architect spawns linter

S239 Memory v2 Compatibility

Analyzed concurrently running S239 spec. Key integration points:

S239 features that benefit S240 for free:

• Dopamine-gated recall: Sub-Vittos get <5ms fast-route recall
• TOON compression: Sub-Vitto prompts use 30-60% fewer tokens
• Cognitive plugins: Trust updates implementable as onAfterResponse plugin
• Prospective indexing: VM task outcomes pre-indexed for future recall

Test Coverage

Decisions Logged (MCP)

All 6 outcomes reported as successful. 4 conventions added. 7 lessons reflected.

Conventions Established

1. Trust domain scoping: Scores are per (userId, actionDomain) — never assume cross-domain trust
2. Trigger storage isolation: Proactive triggers go in vitto_triggers, never VittoMemory
3. VM sticky claims: Per-tool-call claiming with sticky sessions — release on task completion
4. Nesting resource guards: Depth-2 is in-process only, 50% budget, 3-tool cap

Known Limitations & Future Work

Files Modified (Existing)