Non cercare il modello migliore. Cerca il Tool Router.
Ogni settimana spunta un modello nuovo. Il landscape dei LLM si muove veloce: nuovi pesi, nuove finestre, nuovi benchmark. Il risultato è che nessun modello domina su tutti — ognuno eccelle in una fetta.
Eppure la domanda che ricevo più spesso dai team tecnici è sempre la stessa: "Quale modello scelgo?"
È la domanda sbagliata.
Il problema vero: context bloat
Quando costruisci un agente AI produttivo — non una demo, non un chatbot helpdesk, ma un sistema che opera su codice, documenti, API — ti scontri con un limite architetturale prima ancora di toccare i limiti del modello. Ogni tool che registri, ogni schema MCP che carichi, ogni istruzione di sistema che aggiungi gonfia il contesto. Arrivi a 200K token di finestra e li consumi tutti prima che l'agente abbia fatto nulla di utile.
L'ecosistema SDK per agenti AI sta convergendo su un pattern che risolve questo: il Tool Router. Invece di caricare tutti i tool nel contesto dell'agente, li organizzi dietro un router dinamico. L'agente vede solo i tool rilevanti per il task corrente. Il routing avviene via MCP con selezione contestuale. Non è un esperimento — è un'architettura che il mercato sta adottando rapidamente.
Perché il Tool Router batte il cambio modello
Il ragionamento comune è: se il modello A non performa su un task, switcha al modello B. LiteLLM lo rende facile — unifica decine di provider dietro un'unica API. Ma cambiare modello è un'operazione costosa: diversa system prompt, diversi formati di tool call, diversi limiti di contesto, diversa latenza. E il modello B potrebbe essere peggiore del modello A su altri task che nello switch hai dato per scontati.
Il Tool Router inverte la logica. Tieni il modello migliore per il tuo caso d'uso dominante. Ma invece di affogarlo in un contesto monolitico, gli dai accesso selettivo ai tool. Meno rumore, più precisione, meno token sprecati, meno costo per invocazione.
Insight pratico: mappa i tuoi tool come faresti con i microservizi
Se stai costruendo un agente oggi, fai questo esercizio prima di scrivere una riga di codice:
1. Inventa i tuoi tool per dominio, non per funzione. Non "tool_leggi_file" e "tool_scrivi_file". Ma "tool_gestione_repo", "tool_analisi_log", "tool_deploy_staging". Ogni dominio diventa un gruppo MCP.
2. Definisci un router che attiva solo i gruppi rilevanti per l'intento rilevato. Se l'utente chiede "analizza gli errori in produzione", il router attiva solo il gruppo di analisi — non quello di deploy.
3. Misura i token di system prompt prima e dopo. Ridurre il contesto iniziale significa più spazio per il ragionamento effettivo dell'agente, meno allucinazioni da sovraccarico, risposte più veloci.
Il costo? Un layer di routing in più. Il beneficio? Un agente che scala orizzontalmente senza esplodere verticalmente.
Il modello è il motore. L'architettura è il veicolo.
Un modello potente con subagenti paralleli è un motore impressionante. Ma un motore V8 su un telaio che sprofonda non va da nessuna parte. Il Tool Router è il telaio. È quello che decide se la tua potenza diventa movimento o calore disperso.
Se il tuo team sta valutando quale modello adottare e si blocca sui benchmark — fermati. Il vantaggio competitivo non è nel modello. È nell'architettura dei tool.