Un agente non deve vedere tutti i tool: deve sapere quali vale la pena provare

Quando un agente AI dispone di dieci strumenti, scegliere quello giusto sembra quasi un dettaglio. Quando gli strumenti diventano migliaia, invece, la scelta diventa parte del problema: non puoi infilare ogni schema nel contesto, non puoi provare ogni API per vedere se funziona e non puoi ignorare il costo delle chiamate come se latenza e budget fossero effetti collaterali.

Il paper Lookahead-R: Budget-Aware Tool Retrieval via Execution-Centric Planning propone di trattare il retrieval dei tool non come una semplice ricerca semantica, ma come una decisione sequenziale sotto vincoli. La parte interessante non è la sigla MCTS. È il cambio di prospettiva: un tool non è rilevante soltanto perché la sua descrizione assomiglia alla richiesta; è rilevante se, dentro il piano che stiamo costruendo, ha buone probabilità di funzionare a un costo accettabile.

Per un agente, trovare il tool “più simile” e trovare il tool che conviene davvero eseguire sono due problemi diversi.

Il catalogo dei tool sta diventando un problema di sistema

Il modo più immediato di collegare un LLM a molti strumenti consiste nel recuperare, a partire dalla richiesta, un piccolo insieme di API candidate e mostrarne descrizioni e schemi al modello. È ragionevole: riduce il contesto e restringe lo spazio di scelta. Ma porta con sé una supposizione forte, cioè che la similarità semantica sia un buon proxy dell’utilità operativa.

Non sempre lo è. Due API possono descrivere quasi la stessa capacità e avere comportamenti molto diversi: una richiede autenticazione non disponibile, una ha latenza elevata, una restituisce dati insufficienti per lo step successivo, una funziona soltanto dopo un’altra chiamata. Il retrieval classico vede soprattutto il significato dichiarato. L’esecuzione reale introduce vincoli che il testo della documentazione racconta solo in parte.

All’estremo opposto potremmo provare davvero i tool candidati e misurare cosa succede. Avremmo un segnale più vicino alla realtà, ma pagheremmo in chiamate, tempo e possibili effetti collaterali. È precisamente il tipo di soluzione che sembra rigorosa finché qualcuno non presenta la fattura o mette l’agente in produzione.

Lookahead-R prova a simulare prima di spendere

Lookahead-R inserisce tra retrieval ed esecuzione un surrogate world model: un modello leggero addestrato a stimare tre proprietà dei tool candidati senza invocarli realmente — probabilità di successo, costo di latenza e utilità semantica. Queste stime alimentano una Monte Carlo Tree Search cost-sensitive e guidata dall’incertezza, che esplora possibili scelte rispettando un budget.

In termini meno accademici: invece di chiedere soltanto “quale tool sembra pertinente?”, il sistema prova a ragionare su “quale sequenza di scelte sembra promettente, quanto mi costa esplorarla e dove vale la pena spendere altro budget?”. È una distinzione importante perché trasforma il retrieval da filtro statico a componente del planning.

Il paper costruisce il world model usando traiettorie sintetiche teacher-student e poi usa roll-out virtuali per guidare la ricerca online. Non significa che il sistema conosca davvero il futuro. Significa che sostituisce una parte delle esecuzioni costose con previsioni sufficientemente economiche da poter confrontare più alternative prima di scegliere.

La latenza non è una metrica di contorno

Uno dei risultati che gli autori evidenziano nelle ablation è il peso della modellazione esplicita della latenza. È un dettaglio più interessante dell’ennesimo incremento su una classifica: costringe a trattare il tempo come parte della qualità della decisione.

Un agente che trova il tool teoricamente migliore dopo avere interrogato venti alternative può essere peggiore di un agente che trova una soluzione leggermente meno elegante con tre chiamate. Dipende dal contesto. In un batch notturno potremmo privilegiare accuratezza; in un’interazione utente la latenza può dominare; in un servizio a consumo il numero e il costo delle chiamate diventano un vincolo economico.

Questo porta a una conseguenza architetturale semplice: il budget non dovrebbe essere un limite applicato alla fine, quando abbiamo già progettato il sistema. Dovrebbe entrare nella funzione di decisione. CPU, token, chiamate, latenza e probabilità di errore sono tutte risorse. Ho già discusso lo stesso principio parlando di ottimizzare le risorse dal codice ai processi: l’ottimizzazione ha senso quando parte dalla risorsa realmente scarsa, non quando rincorre una metrica per abitudine.

Il benchmark dice qualcosa, ma non dice “problema risolto”

Gli autori valutano Lookahead-R su ToolBench. Sullo split I3, quello indicato come più difficile, riportano NDCG@5 pari a 91,40%, contro 90,16% di ToolGen: un vantaggio di 1,24 punti. Il risultato sostiene la tesi che si possa migliorare il compromesso fra qualità del retrieval e costo, ma va letto nel perimetro corretto.

ToolGen, usato come confronto, affronta lo stesso problema da una direzione diversa: rappresenta i tool come token e integra retrieval e calling nel processo generativo. E ToolBench stesso nasce come ambiente di valutazione su grandi collezioni di API. Sono benchmark utili per confrontare metodi, non una replica perfetta di un’infrastruttura aziendale con credenziali che scadono, rate limit, API che cambiano, permessi differenti e costi contrattuali.

Quindi 91,40% non significa che un agente in produzione sceglierà correttamente i tool nel 91,40% dei casi. NDCG@5 misura la qualità del ranking nel benchmark. Confondere le due cose sarebbe esattamente l’errore che dovremmo evitare quando progettiamo sistemi autonomi: trasformare una metrica locale in una promessa operativa.

Il world model è utile proprio perché può sbagliare

Un modello surrogato introduce un nuovo rischio: può prevedere male. Potrebbe stimare come economico un tool diventato lento, considerare affidabile un endpoint degradato o non conoscere una modifica recente all’autenticazione. La risposta non può essere fingere che il modello rappresenti la realtà. Deve essere progettare il sistema sapendo che rappresenta un’approssimazione.

Qui l’incertezza usata nel planning è concettualmente importante. Se una previsione è fragile, il sistema può decidere che vale la pena acquisire informazione; se è abbastanza sicura, può evitare un’esecuzione esplorativa. È una logica più interessante del “fidati del ranking”, perché ammette che conoscere il proprio margine di dubbio ha valore operativo.

Un world model non deve sostituire la realtà. Deve dirci dove possiamo permetterci di non interrogarla subito.

In produzione servirebbe un circuito di feedback

Se portassi questa idea in un sistema reale, il punto centrale non sarebbe implementare MCTS perché compare nel paper. Sarebbe costruire un circuito in cui previsione ed esecuzione si correggono a vicenda.

• Il registry dei tool dovrebbe descrivere non solo semantica e schema, ma anche capability, permessi, costo e vincoli osservabili.
• Le esecuzioni reali dovrebbero produrre telemetria su successo, latenza, errori e retry.
• Il retriever dovrebbe poter usare questi segnali per aggiornare la stima operativa, senza confondere un incidente temporaneo con una proprietà permanente.
• Il planner dovrebbe ricevere un budget esplicito per run o per fase, non un generico invito a “essere efficiente”.
• Il sistema dovrebbe conservare una via di verifica reale quando l’incertezza del surrogato è troppo alta o la decisione è critica.

Questa impostazione è coerente con un’altra lezione che emerge nei sistemi agentici: il modello non è il sistema. Registry, action space, errori, permessi, telemetria e quality gate determinano quanto le capacità del modello possano diventare comportamento affidabile. Aggiungere più tool senza progettare questi confini significa aumentare contemporaneamente potenza e superficie di errore.

Lo stesso problema riappare un passo più avanti, quando il tool non va soltanto scelto ma può essere eseguito in anticipo in modo speculativo: TomasuLLM mostra perché latenza, isolamento, dipendenze e commit diventano parte dello stesso problema di controllo operativo.

La domanda giusta non è “quanti tool posso dare all’agente?”

Per molto tempo la scalabilità del tool use è stata raccontata come un problema di quantità: come facciamo a mettere a disposizione 100, 1.000 o 50.000 API? Lookahead-R suggerisce una domanda più matura: quanta parte di quello spazio vale la pena esplorare per questa richiesta, con questo budget e con queste incertezze?

È un cambio piccolo solo in apparenza. Un catalogo enorme è una capability potenziale. Un agente utile deve trasformarla in una sequenza di decisioni che rispetti tempo, costo e affidabilità. A quel punto il retrieval non è più il motore di ricerca davanti al catalogo: diventa un pezzo del controllo operativo.

Ed è probabilmente questa la parte più trasferibile del paper, anche se domani useremo un planner diverso da MCTS o un world model costruito in altro modo. Quando gli agenti iniziano davvero ad agire, non basta che sappiano quale strumento “sembra giusto”. Devono imparare a decidere quale informazione vale il costo di essere verificata, quale chiamata vale il budget di essere eseguita e quando una previsione è abbastanza incerta da meritare un contatto con la realtà.