Perché Meno Strumenti Rendono un Agente AI Più Efficace

Dare a un agente AI dieci strumenti produce quasi sempre un output peggiore, non una maggiore capacità. Ogni strumento aggiunto rappresenta un'ulteriore opportunità per il modello di scegliere quello sbagliato, passare argomenti errati o fare la cosa sbagliata in silenzio, restituendo comunque una risposta che suona sicura. Gli agenti che funzionano davvero in produzione tendono a operare con due o cinque strumenti, ciascuno dedicato a un compito specifico.

Non si tratta di una preferenza teorica. Emerge continuamente nel modo in cui vengono descritti gli agenti ben costruiti: uno script che legge issue GitHub e manifesti di dipendenze e individua advisory reali senza toccare il codice, oppure uno scanner che classifica i sottodomini come probabilmente wildcard usando esclusivamente query DNS. Il denominatore comune non è un prompting sofisticato. È che ogni agente dispone di una cassetta degli attrezzi piccola e fissa, e non deve mai indovinare quale tra quindici opzioni utilizzare.

La trappola del numero di strumenti

Quando si definisce lo scope di un progetto con agenti, l'istinto naturale è essere generosi: si dà all'agente uno strumento di ricerca, uno per il database, uno per i file, uno per le email, uno per il calendario, "nel caso in cui" ne avesse bisogno. Sembra una scelta prudente. Non lo è — e i due esempi precedenti mostrano perché ogni modalità di errore è concreta, non ipotetica:

• La precisione di selezione cala. Lo scanner di manifesti di dipendenze funziona perché deve scegliere solo tra "leggi un manifesto" e "leggi un'issue". Aggiungendo una terza opzione — ad esempio uno strumento di ricerca web generico — il modello deve decidere a ogni esecuzione se l'advisory che cerca si trova nel repository o in rete, e indovinerà in modo sbagliato con una frequenza sufficiente a creare problemi.
• Gli errori negli argomenti si moltiplicano. Il classificatore di sottodomini basato su DNS accetta un solo input: un hostname. È l'intero schema. Nel momento in cui si aggiunge un secondo strumento con i propri parametri, si è raddoppiata la superficie esposta a chiamate malformate — e su un'azione in scrittura il costo di quella chiamata malformata non è più "risposta DNS sbagliata", ma "record errato inviato".
• I guasti diventano silenziosi. Entrambi questi strumenti sono in sola lettura, quindi una scelta sbagliata produce semplicemente una classificazione errata, visibile nell'output. Un agente dotato anche di uno strumento in scrittura può usarlo in modo improprio, registrare un successo e andare avanti — e nessuno se ne accorge finché non è un cliente a segnalarlo.
• I costi aumentano gradualmente. Ogni definizione di strumento occupa spazio nella context window a ogni chiamata, indipendentemente dal fatto che lo scanner di manifesti utilizzi il secondo o terzo strumento. Un elenco di strumenti gonfiato è un prompt gonfiato a ogni singolo turno.

Le stesse indicazioni emergono dalla prospettiva progettuale nel materiale di Anthropic sulla progettazione di agenti: i sistemi agentici più affidabili sono composti da componenti semplici e ben testati, non da un singolo agente che gestisce ogni capacità in una volta sola (cfr. il documento tecnico di Anthropic sulla costruzione di agenti efficaci). La semplicità non è un punto di partenza da cui ci si emancipa con la maturità. È ciò che continua a funzionare su scala.

Come si presenta uno scope ristretto nella pratica

Gestiamo il nostro motore di outbound in questo modo. Analizza il sito di un prospect, estrae le poche informazioni rilevanti e redige una singola email personalizzata, il tutto in un'unica chiamata mirata anziché in una catena multi-step con uno strumento di ricerca, uno CRM e uno di redazione collegati tra loro. Meno componenti in gioco ha significato meno punti in cui il processo poteva silenziosamente fallire, e un costo inferiore per ogni lead. La lezione si è generalizzata oltre l'outreach: meno strumenti deve raggiungere un agente, più è facile sapere esattamente cosa ha fatto e perché. È una questione diversa da quella relativa all'utilizzo di una singola chiamata LLM o una catena di agenti per un determinato compito, ma lo stesso principio si applica al livello degli strumenti: non si danno al modello opzioni di cui non ha bisogno.

Come verificare l'elenco degli strumenti di un agente

Se si sta valutando un progetto — sviluppato internamente o da un'agenzia — è opportuno richiedere l'elenco degli strumenti prima ancora di chiedere del modello o del prompt. Alcuni controlli da effettuare:

• Si riesce a definire in una sola frase il compito di questo agente? Il nostro motore di outbound supera questo test: trasforma il sito di un prospect in una bozza di email. Se la risposta per l'agente di qualcun altro richiede un paragrafo, probabilmente si tratta di due agenti in un unico vestito.
• Ogni strumento viene utilizzato in un'esecuzione normale, oppure alcuni sono presenti "nel caso in cui"? La chiamata scraping-estrazione-redazione non ha strumenti inutilizzati nello schema. Gli strumenti inutilizzati sono puro svantaggio: costo e confusione senza alcun beneficio.
• Ci sono due strumenti che si potrebbero facilmente confondere, stando solo ai nomi e alle descrizioni? Se un essere umano che scorre lo schema esiterebbe, il modello farà lo stesso.
• Cosa succede quando l'agente sceglie lo strumento sbagliato? Se non c'è un sistema di logging che evidenzi una chiamata errata, lo si scoprirà solo quando lo farà il cliente.
• Si potrebbe usare un router tra due agenti specializzati anziché un unico agente ampio? La logica di instradamento è prevedibile e testabile. Un singolo modello che gestisce dodici strumenti non lo è.

Quando più strumenti hanno davvero senso

Questo non significa che ogni agente debba essere uno script a strumento singolo. Alcuni compiti abbracciano realmente più sistemi: un agente di supporto che deve verificare un ordine, controllare un corriere e emettere un rimborso sta legittimamente facendo tre cose. In questi casi, la soluzione di norma non è ridurre gli strumenti su un unico agente, ma suddividere il compito in un workflow di passi più piccoli con passaggi espliciti, anziché lasciare che un singolo modello decida l'ordine tra una dozzina di opzioni a ogni turno. Un workflow deterministico che chiama tre agenti specializzati in sequenza è molto più facile da diagnosticare rispetto a un unico agente con nove strumenti che cerca di stabilire da solo la sequenza corretta.

Cosa chiedere a un fornitore in merito

Se si confrontano agenzie o proposte interne per un progetto agentivo, lo scope degli strumenti è una domanda semplice e di grande valore informativo da aggiungere alla propria checklist di valutazione dei fornitori. Si chieda di illustrare l'elenco degli strumenti previsti per l'agente e di giustificarne ciascuno. Un team che ha riflettuto seriamente su questo aspetto avrà una risposta chiara per ogni strumento. Un team che non lo ha fatto inizierà a spiegare gli strumenti descrivendo scenari ipotetici — e questo è quasi sempre il segnale di una scope creep in tempo reale.

Il numero di strumenti è una delle poche decisioni progettuali di un agente che si può verificare senza leggere una riga di codice, e correla fortemente con il comportamento dell'intero sistema una volta in produzione e senza supervisione diretta.

Se si sta definendo lo scope di un progetto agentivo e si desidera un parere esterno sull'elenco degli strumenti prima di impegnarsi, parliamone.