Architecture: How should Vitto select tools for each request to reduce LLM...

Documentation for Sessions

🏗️ Architecture: How should Vitto select tools for each request to reduce LLM...

Date: 2026-03-19
Time: 11:32:55 UTC
Session: gspace1-234.6
Agent: backend
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How should Vitto select tools for each request to reduce LLM decision confusion?

Task: S234: Context-aware tool filtering for Jarvis-level agent

🎯 Decision Made

Chosen:

Context-aware tool filtering via TOOL_CATEGORIES (11 categories) + INTENT_TOOL_MAP (12 intents) in ToolRegistryService. User message is classified by intent (greeting, build, debug, browse, etc.), mapped to relevant tool categories, enriched by page context. Reduces 20+ tools to 5-8 per request. Safety: falls back to full tool list if filtering yields < 3 tools.

Options Considered:

  1. Intent-based tool category filtering (chosen)
  2. LLM-based tool selection pre-pass (too expensive — adds 200ms latency per request)
  3. Static per-page tool lists (too rigid — can't handle cross-cutting requests)
  4. Send all tools always (status quo — 3000 tokens wasted, poor selection quality)

💭 Reasoning

Sending all 20+ tools in every request wastes ~3000 tokens on tool descriptions and confuses the LLM — when it sees start_module_generation, browser_navigate, deploy_agents, oauth_api_call, and computer_use simultaneously, it has trouble selecting the right one. OpenAI's Agents SDK research confirms that fewer, more relevant tools improve decision quality. The intent classification is regex-based (no LLM call — must be instant) and maps to pre-defined category sets. Page context enrichment adds build+visual tools when user is in Studio, delegation+integration tools when in Vitto command hub. The < 3 fallback ensures the LLM is never stuck with too few options for ambiguous requests.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation