Vitto Unicorn Research — Senior Engineering Review

What This Document Is

A critical review of VITTO-EXPANDED-RESEARCH-UNICORN-PATH.md against our actual codebase and current S202 plan. The question: does this research change what we should build next?

Short answer: The research is strong on business strategy but partially redundant with what we already have. 3 of the 7 proposals already exist in our codebase in some form. 2 should be added to our plan. 2 should be deferred.

Section-by-Section Analysis

2.1 Voice-First Agent Interface — DEFER (correct in paper)

What the paper proposes: WhatsApp voice notes → Whisper transcription → Vitto processes → TTS response back.

What we already have:

• @libs-api/messaging-core exports a TtsService (text-to-speech)
• ChannelProcessingService in backend-vitto-api handles WhatsApp/Telegram messages
• ChannelGatewayService sends responses back to channels

What's actually missing: Audio file handling (receiving voice notes via Twilio webhook, sending audio blobs back). The Whisper/Realtime API integration.

My verdict: The paper correctly says "start with async voice messages, not real-time calling." I agree. But this is a product feature, not an infrastructure feature. It doesn't change our S202 plan. Defer to S206+ after generation pipeline is verified and dossier system is built. The voice pipeline is ~2 sessions of work when we get to it — the channel infrastructure is already there.

Confidence: Certain — based on actual codebase files.

2.2 Proactive Agent Behavior — ALREADY EXISTS (paper doesn't know this)

What the paper proposes: ProactiveSignal schema, ProactiveDecisionService, confidence threshold, auto-adjusting frequency.

What we actually have (the paper's cowork agent missed this):

• ProactiveMonitorService at APIs/backend-vitto-api/src/app/proactive/proactive-monitor.service.ts — Session 100, enhanced through Session 167
• ProactiveReachService — outbound message decisions
• HeartbeatService — periodic health pulsing
• DailyDigestService — scheduled digest generation
• ScheduledMessageQueueService — queued outbound messages
• Domain-specific checks: DeveloperChecksService, GithubChecksService
• MongoDB-persisted alerts with severity-based routing + escalation (6h threshold for unresolved criticals)
• Channel notification bridge — delivers alerts to user's preferred channel (WhatsApp/Telegram/Slack)

What's genuinely missing from what the paper proposes:

• Auto-adjusting confidence threshold based on user engagement (good idea, ~0.5 session to add)
• The ProactiveSignal as a formal typed schema (currently, signals are ad-hoc check results)

My verdict: This section of the research paper is almost entirely describing something we already built. The cowork agent that wrote the research apparently didn't explore the proactive/ directory in backend-vitto-api. No plan changes needed. The one good idea (auto-adjusting threshold) can be a small enhancement to ProactiveReachService — add it as a nitpick task, not a phase.

Confidence: Certain — verified all 7 files in proactive/ exist.

2.3 Human-Agent Handoff & Confidence Calibration — ALREADY EXISTS

What the paper proposes: 4-tier confidence escalation (90-100% autonomous, 70-89% confirm first, 40-69% present options, <40% escalate). Per-user calibration via Bayesian update.

What we actually have:

• TrustEscalationService at APIs/backend-vitto-api/src/app/engine/trust-escalation.service.ts — Session 158
• AutonomyConfigDoc schema with global level, per-session overrides, per-handoff overrides
• ActionTrustScore schema tracking per-action success rates
• 4 autonomy levels: OBSERVE, SUGGEST, DIRECT, AUTONOMOUS
• Thresholds: observe=0, suggest=0.3, direct=0.6, autonomous=0.85 (with 50 sample minimum)
• Consecutive success acceleration + instant downgrade on failure at AUTONOMOUS level
• Penalty cooldown for recovery from downgrade

This is more sophisticated than what the paper proposes. The paper describes static confidence bands. Our implementation has adaptive trust that learns from outcomes, with sample-size requirements and asymmetric escalation/de-escalation. The Bayesian update the paper suggests is conceptually what TrustEscalationService already does via success rate + sample size.

My verdict: No plan changes. Our existing system is better than what the paper proposes. The paper's cowork agent wrote a proposal for something we built 50+ sessions ago.

Confidence: Certain — read the actual service code.

2.4 Outcome-Based Pricing ("Vitto Work Units") — ADD TO PLAN (design only)

What the paper proposes: Charge per completed, verified action instead of per-seat or per-token.

What we have: MCP billing infrastructure exists (mcp-billing.controller.ts, mcp-usage.service.ts, tier-limit.guard.ts, mcp-usage.schema.ts). Stripe integration in backend-api/billing/billing.service.ts with subscription management, usage-based billing (atomic $inc overage tracking), and TIER_LIMITS.

What's genuinely missing: The "Vitto Work Unit" abstraction. Currently, usage is tracked by raw metrics (API calls, token counts). There's no concept of "a completed outcome" as a billing unit. The LlmCostTrackerService we just built tracks cost from our side, not value delivered to the user.

My verdict: The paper is right that outcome-based pricing is the correct model for an AI-first SaaS. But implementing it requires:

1. Defining what counts as a VWU (needs product decision, not engineering)
2. Adding outcome tracking to every Vitto action (the outcome() MCP tool partially does this)
3. Wiring outcomes to the billing system (Stripe metered billing)

This is a design + product decision first, engineering second. Add to our plan as a Phase 3.5 design task — write the VWU spec, don't build it yet. The engineering is straightforward once the product definition exists.

Confidence: Likely — based on existing billing infrastructure being extensible.

2.5 Agent Evaluation & Safety Framework — ADD TO PLAN (Golden Path tests)

What the paper proposes: Golden Path test suite (30-50 scenarios), real-time guardrails, trace-based observability.

What we have:

• ToolSecurityService in backend-vitto-api — sanitizes output, strips system-prompt leakage, env vars, internal URLs
• ComputerUsePermissionGuard — gates computer use actions
• CostGuardService — per-task budget enforcement (max iterations, tokens, timeout)
• ObservatoryService + LlmCostTrackerService — observability dashboard
• Decision logging via MCP log_decision() + outcome() tools
• 12K+ decisions in ai-agents database

What's genuinely missing:

• Golden Path test suite — zero automated regression tests for agent behavior. This is the paper's strongest recommendation. If we ship the runtime layer (Phase 4) and it subtly breaks 15% of user workflows, we have no way to detect it before users complain. This is a real gap.
• Trace-based session observability — we have decision logs but not full execution traces (input → reasoning → tool calls → outputs → cost per session, searchable). The ThoughtTraceService in mind/ exists but it's for internal reasoning, not user-facing audit.

My verdict: The Golden Path test suite should be added to our plan. Not as a separate phase — as a prerequisite for Phase 4 (Agent Runtime). You cannot safely refactor the agent loop without regression tests. Add as Task 2.4 in our current plan: "Create 20 Golden Path test scenarios for agent behavior regression testing."

The trace observability is good but lower priority. Our existing Observatory + decision logs cover 80% of the need. Full tracing can come with Phase 5 (Skills) since skill generation needs outcome data anyway.

Confidence: Certain — no agent regression tests exist anywhere in the codebase.

2.6 Edge AI — DEFER (paper agrees)

What the paper proposes: On-device intent classification, PII masking, offline task queuing. Paper itself says "2027 differentiator."

My verdict: Agree with the paper. Not relevant to our current plan. Defer.

Confidence: Certain — no infrastructure for on-device inference exists or is needed.

2.7 Hermes Agent Pattern — ALREADY INCORPORATED

What the paper proposes: Study Hermes Agent for: closed learning loop, dialectic user modeling, FTSS session search, subagent isolation via RPC.

What we're already building:

• Closed learning loop → Phase 5 of our plan (Skill Generation)
• User modeling → Phase 3 of our plan (User Dossier)
• Session search → ConversationGenomeService.semanticRecall() exists
• Subagent isolation → SubAgentService + DelegationManagerService exist

What Hermes does better than us: The "dialectic user modeling" — Hermes actively asks questions to learn about the user, rather than passively extracting from conversations. This is a good enhancement for our Dossier system. Add a "dialectic enrichment" capability to Task 3.2 (Dossier Hydration) — Vitto can occasionally ask clarifying questions and feed answers into the dossier.

Confidence: Certain — verified existing services match Hermes patterns.

What Changes in Our Plan

ADD These Items:

DO NOT ADD These Items:

Items the Paper Gets Wrong:

1. "No outcome tracking" for Hermes disadvantage — The paper claims Hermes doesn't track outcomes. But our outcome() MCP tool + LearningService already does this. The paper is comparing Hermes to capabilities we already have.

2. ProactiveSignal schema as new — We have a more complete implementation. The paper proposes what we built 100+ sessions ago.

3. Confidence bands as new — Our TrustEscalationService with adaptive thresholds, sample-size requirements, and asymmetric escalation is strictly better than the static 4-band system proposed.

The Paper's Best Insight (That Our Plan Underweights)

Section 2.4 on unit economics is the most important section in the entire paper. The paper correctly identifies that without knowing the cost-per-outcome, you can't price, optimize, or raise funding. Our S201 LlmCostTrackerService gives us cost-per-LLM-call. But we don't yet have cost-per-user-outcome — what does it cost Vitto to successfully generate a module, resolve a WhatsApp query, or deploy a platform?

The CostGuardService in backend-vitto-api tracks per-task budgets. The missing link is aggregating these into business-meaningful metrics: "average module generation costs $0.12 in LLM tokens" or "average WhatsApp resolution costs $0.03."

Recommendation: Add a simple aggregation query to the Observatory dashboard that groups LlmCostTrackerService records by caller field (which we added in S201). This gives per-feature cost breakdown immediately, with zero new code — just a new endpoint.

Updated Session Allocation (Changes in Bold)

Reviewed March 11, 2026 — S202 Planning Session Review of VITTO-EXPANDED-RESEARCH-UNICORN-PATH.md against actual codebase