🏗️ Architecture: How should backend-vitto-api integrate with the existing pla...

Date: 2026-02-09
Time: 03:19:38 UTC
Session: gspace1-100.2
Agent: backend
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How should backend-vitto-api integrate with the existing platform to achieve zero duplication and beautiful synergy?

Task: Not specified

🎯 Decision Made

Chosen:

Replace Vitto's LLM module with @libs-api/llm-integration, delegate decision logging to backend-ai-api, register as agent with proper capabilities, use internal service auth with BACKEND_API_INTERNAL_TOKEN, and emit orchestration events to Command Center Gateway

Options Considered:

• No alternatives documented

💭 Reasoning

After analyzing the codebase, the duplication is clear: Vitto has its own ProviderFactoryService that mirrors LLMService from @libs-api/llm-integration. Both initialize providers the same way, both track costs, both handle API keys. The platform already has mature infrastructure for decisions (DecisionService with auto-embedding), agent registration (AgentService with capabilities and heartbeat), and event broadcasting (CommandCenterGateway). Vitto should leverage these instead of duplicating them. The shared library approach ensures consistent LLM behavior across all APIs while Vitto keeps its unique orchestration logic.

📁 Files Involved

• apis/backend-vitto-api/src/app/llm/llm.module.ts
• libs/libs-api/llm-integration/src/lib/llm-integration.module.ts
• apis/backend-vitto-api/src/app/mind/mind.service.ts
• apis/backend-ai-api/src/app/infrastructure/services/decision.service.ts

🔗 Related

• Decision ID: dev_1770607178394_m6sw6s3
• Session: 100
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation