Molte aziende immaginano un “agente AI” come una chat un po’ più intelligente: fai una domanda, ricevi una risposta. Ma il salto di valore vero avviene quando l’agente smette di limitarsi a rispondere e inizia a fare — controllare un calendario, aggiornare un CRM, cercare un ordine, inviare una notifica. Questo meccanismo si chiama tool calling (o “uso di strumenti”) ed è oggi il cuore di qualsiasi automazione seria basata su AI. La domanda che conta, per chi deve portarlo in produzione, non è “l’agente può usare degli strumenti?” ma “come decide quale strumento usare, e cosa succede se sbaglia?”.
Cos’è il tool calling e perché conta per un’azienda
Un modello linguistico, da solo, non può leggere un database, mandare una email o modificare un evento in agenda: può solo generare testo. Il tool calling colma questo limite dando al modello un elenco di “strumenti” disponibili — funzioni con un nome, una descrizione e dei parametri — che l’agente può decidere di invocare durante la conversazione. Il modello non esegue nulla direttamente: propone la chiamata (es. “cerca_cliente con email=x”), il sistema la esegue per davvero, e il risultato torna all’agente per continuare il ragionamento.
Per un’azienda questo significa poter collegare un assistente conversazionale a ciò che già usa ogni giorno: gestionale, CRM, calendario, sistema di ticket, magazzino. L’agente diventa un livello di orchestrazione sopra i sistemi esistenti, non un sostituto da integrare da zero.
Come un agente decide quale strumento usare
La scelta dello strumento giusto non è magia: dipende da come viene progettato il contesto che il modello riceve.
Descrizioni chiare, non tecniche generiche
Se due strumenti hanno descrizioni ambigue o si sovrappongono, l’agente sbaglierà spesso. Nella pratica funziona molto meglio avere pochi strumenti ben distinti, con nomi e descrizioni scritte pensando a “quando esattamente va usato questo”, piuttosto che tanti strumenti generici che si accavallano.
Contesto e stato della conversazione
Un buon agente tiene traccia di cosa ha già fatto: se ha già recuperato i dati di un cliente, non dovrebbe richiamare lo stesso strumento due volte. Questo richiede una gestione della memoria di conversazione ben progettata — un tema che ho approfondito parlando di memoria degli agenti AI nel tempo.
Permessi e vincoli espliciti
Non tutti gli strumenti dovrebbero essere sempre disponibili. Un agente rivolto ai clienti non dovrebbe avere accesso agli stessi strumenti di un agente interno per il team amministrativo. Definire per ogni ruolo quali strumenti sono visibili riduce drasticamente il rischio di azioni indesiderate.
Cosa succede quando lo strumento sbaglia
In produzione, gli strumenti falliscono: un’API esterna va in timeout, un dato non esiste, un parametro è nel formato sbagliato. Un’automazione robusta deve gestire questi casi esplicitamente, non sperare che non accadano mai:
- Validazione dell’output: controllare che il risultato di uno strumento sia nel formato atteso prima di passarlo avanti all’agente.
- Retry mirati: ritentare solo gli errori transitori (timeout, rate limit), non quelli logici (cliente inesistente).
- Messaggi di errore leggibili dal modello: se uno strumento fallisce, l’agente deve ricevere un errore chiaro per poter decidere se riprovare, usare un’alternativa o chiedere aiuto all’utente.
- Un limite massimo di tentativi: senza un tetto, un agente bloccato può richiamare lo stesso strumento decine di volte, consumando budget di API senza arrivare a un risultato.
Questi meccanismi vanno di pari passo con una buona osservabilità: se non si registra ogni chiamata a uno strumento, con input, output ed esito, diventa impossibile capire perché un’automazione ha preso una certa decisione. Ne ho parlato più nel dettaglio nell’articolo sull’osservabilità degli agenti AI in produzione.
Sicurezza: il tool calling non è un assegno in bianco
Dare a un agente la capacità di agire sui sistemi aziendali introduce una superficie di rischio nuova. Un input malevolo — anche solo un’email o un documento che l’agente legge — può tentare di indurlo a invocare strumenti che non dovrebbe usare: è la stessa dinamica che ho descritto parlando di prompt injection e come proteggere gli agenti AI aziendali. Per questo, le azioni con effetti reali o difficilmente reversibili (inviare un pagamento, cancellare un record, comunicare all’esterno) dovrebbero passare da una conferma umana prima dell’esecuzione, come descritto nel modello human-in-the-loop per gli agenti AI. Il tool calling va progettato con lo stesso rigore con cui si progetta un’API pubblica: whitelist di azioni permesse, validazione degli input, log di ogni chiamata.
Un esempio pratico
Immaginiamo un agente AI per una PMI che gestisce richieste di appuntamento via chat. Un flusso tipico di tool calling potrebbe essere:
- Lo strumento cerca_disponibilita interroga il calendario aziendale per le fasce libere.
- Lo strumento verifica_cliente controlla se chi scrive è già a sistema nel CRM.
- Lo strumento crea_appuntamento scrive l’evento solo dopo conferma esplicita dell’utente.
- Lo strumento notifica_team avvisa via email o chat interna il collega coinvolto.
Ogni strumento fa una cosa sola, con un contratto chiaro. L’agente li combina in base alla conversazione, ma non ha accesso diretto al database: passa sempre attraverso interfacce controllate, tracciate e con permessi definiti.
Conclusione
Il tool calling è ciò che trasforma un chatbot in un vero agente operativo, capace di produrre valore concreto per un’azienda. Ma la qualità dell’implementazione — descrizioni degli strumenti, gestione degli errori, permessi, controlli di sicurezza — è quello che separa un’automazione affidabile da un rischio operativo. Se stai valutando come collegare un assistente AI ai sistemi della tua azienda in modo sicuro e solido, contattami: progetto e realizzo agenti AI e automazioni su misura, integrate con gli strumenti che già usi. Trovi altri esempi dei progetti che sviluppo su cornelcaba.com.
