Un agente che sa descrivere una procedura non sta ancora lavorando nel processo. Per verificare una disponibilità a magazzino, aprire una richiesta di assistenza o aggiornare un record CRM, deve poter dialogare con sistemi reali. È qui che tool use e function calling trasformano un modello linguistico da interfaccia conversazionale a componente operativa dell’architettura aziendale.
La differenza è sostanziale. Un chatbot produce testo in risposta a una domanda. Un agente AI può interpretare un obiettivo, recuperare informazioni autorizzate, scegliere uno strumento, compilare parametri strutturati, eseguire un’azione e restituire un esito verificabile. AI che agisce, non soltanto risponde.
Questa capacità non dipende solo dal modello scelto. Dipende soprattutto da come sono progettati strumenti, dati, regole di autorizzazione, workflow, controlli e supervisione. Una demo può mostrare una chiamata API riuscita. Un sistema pronto per la produzione deve invece gestire errori, ambiguità, permessi, audit e continuità operativa.
Che cosa sono tool use e function calling
Il function calling è il meccanismo con cui un modello linguistico richiede l’esecuzione di una funzione software definita dall’applicazione. La funzione può cercare un ordine, interrogare un ERP, creare un ticket, leggere un documento, calcolare una previsione o inviare una comunicazione secondo policy precise.
Il modello non accede direttamente al database e non dovrebbe possedere credenziali indiscriminate. Riceve una descrizione controllata delle funzioni disponibili, comprende quale sia pertinente alla richiesta e genera una chiamata strutturata, spesso in formato JSON. L’applicazione valida la richiesta, esegue l’operazione nel sistema autorizzato e restituisce il risultato all’agente.
Il tool use è il concetto più ampio: comprende l’uso di funzioni, API, motori di ricerca, sistemi documentali, calcolatori, code di messaggistica e applicazioni proprietarie. Il function calling è una delle modalità con cui questo utilizzo viene implementato in modo prevedibile e tracciabile.
La distinzione conta perché impedisce un errore frequente: scambiare la capacità del modello di proporre un’azione con la capacità dell’azienda di eseguirla in sicurezza. Il modello ragiona sul linguaggio. L’architettura software governa l’azione.
Dal prompt al processo: come lavora un agente
Un flusso affidabile parte da un’intenzione concreta. Un responsabile commerciale può chiedere: “Prepara una bozza di offerta per il cliente, usando il listino aggiornato e le condizioni contrattuali vigenti”. L’agente deve prima identificare il cliente, recuperare dati dal CRM, verificare prezzi e disponibilità sui sistemi corretti, consultare le regole commerciali e generare una bozza da sottoporre ad approvazione.
Ogni passaggio richiede strumenti con responsabilità circoscritte. Una funzione per cercare il cliente non deve poter modificare l’anagrafica. Una funzione per creare una bozza d’offerta non deve inviarla automaticamente. Separare lettura, scrittura, approvazione e invio riduce il rischio e rende più semplice controllare il comportamento del sistema.
Il ciclo operativo è normalmente composto da quattro fasi: interpretazione della richiesta, selezione dello strumento, esecuzione validata dal software e lettura dell’esito. In processi complessi, questo ciclo si ripete più volte. L’agente può accorgersi che manca un dato, richiedere un’integrazione all’utente oppure indirizzare il caso a una persona competente.
Non ogni processo richiede autonomia completa. Per attività informative, come la ricerca di una fattura o di una specifica tecnica, l’AI può operare in sola lettura. Per attività con impatto economico, contrattuale o reputazionale, è spesso preferibile introdurre un checkpoint umano. L’automazione efficace non elimina il controllo: lo colloca nel punto in cui genera valore.
Tool use e function calling non sono un RAG
Un sistema RAG recupera contenuti pertinenti da una knowledge base e li porta nel contesto del modello per formulare una risposta fondata sui documenti. È essenziale per consultare manuali, procedure, contratti, policy e documentazione tecnica. Ma non basta quando l’informazione cambia in tempo reale o quando è necessaria un’azione.
Per sapere come gestire un reso, il RAG può recuperare la procedura interna. Per verificare lo stato reale di una spedizione, l’agente deve interrogare il gestionale o il corriere tramite tool. Per avviare la pratica di reso, deve chiamare una funzione di creazione, applicando le regole previste.
Le architetture più utili combinano entrambe le capacità. Il RAG fornisce contesto e conoscenza aziendale affidabile; il tool use porta l’agente dentro i sistemi operativi. Software, dati e intelligenza artificiale in un’unica architettura.
Progettare strumenti che il modello possa usare bene
Una funzione non deve essere pensata come una scorciatoia tecnica per collegare il modello a qualsiasi API esistente. Va progettata come un contratto operativo chiaro, con un obiettivo limitato, parametri comprensibili, vincoli espliciti e una risposta strutturata.
Una funzione chiamata `aggiorna_cliente` è troppo ampia se consente di cambiare indirizzi, condizioni di pagamento, classificazioni fiscali e stato commerciale con la stessa autorizzazione. È preferibile esporre operazioni specifiche, come la proposta di variazione dell’indirizzo di consegna, con campi obbligatori e controlli di coerenza.
Anche la descrizione dello strumento incide sulla qualità. Se la funzione serve solo a cercare ordini aperti negli ultimi novanta giorni, questa regola deve essere esplicita. Lasciare troppa interpretazione al modello produce chiamate errate, risultati ambigui e costi di manutenzione più alti.
Le risposte degli strumenti dovrebbero contenere dati utili al passo successivo, non intere tabelle o payload inutilmente estesi. Ridurre il contesto migliora prestazioni, limita l’esposizione di dati e rende il ragionamento dell’agente più leggibile. Il principio è semplice: fornire all’AI solo ciò che serve per completare l’azione autorizzata.
Sicurezza, autorizzazioni e tracciabilità
Il punto più delicato non è far funzionare una chiamata, ma stabilire chi può avviarla, su quali dati e con quali conseguenze. Un agente non deve ereditare privilegi amministrativi solo perché opera per conto di un dipendente. Deve rispettare ruoli, business unit, perimetri territoriali, deleghe e policy applicative.
L’autorizzazione va verificata dal backend, mai affidata soltanto alle istruzioni date al modello. Un prompt può guidare il comportamento, ma non costituisce una misura di sicurezza. Ogni tool deve applicare controlli server-side e utilizzare identità tecniche con privilegi minimi.
La tracciabilità deve registrare richiesta iniziale, strumenti selezionati, parametri inviati, esiti ricevuti, eventuali approvazioni e identità dell’utente. Questi log consentono audit, analisi degli errori e miglioramento continuo. Sono anche indispensabili quando l’AI interviene su processi regolati o su informazioni sensibili.
Servono poi limiti operativi: soglie di importo, vincoli temporali, idempotenza per evitare doppie esecuzioni, timeout, gestione dei retry e blocchi per azioni irreversibili. Se un ERP non risponde, l’agente non deve inventare un esito positivo. Deve segnalare l’anomalia, preservare il contesto e attivare il percorso di recupero previsto.
Dove generano valore nei processi aziendali
Il valore emerge quando l’agente riduce passaggi tra persone, inbox e applicazioni senza bypassare le regole. Nel customer service può cercare ordini, verificare garanzie, proporre soluzioni e aprire ticket completi. Nella supply chain può confrontare disponibilità, tempi di consegna e priorità produttive, generando segnalazioni per il pianificatore.
In amministrazione può classificare documenti, estrarre dati, controllare incongruenze e preparare pratiche da validare. In area commerciale può costruire briefing cliente combinando CRM, storico ordini, documenti tecnici e dati di assistenza. Il risultato non è un’altra chat isolata, ma un’interfaccia intelligente che coordina sistemi già presenti.
Il caso d’uso giusto ha tre caratteristiche: dati accessibili e affidabili, azioni chiaramente definibili e un beneficio misurabile. Se il processo è confuso, privo di ownership o basato su eccezioni non formalizzate, l’AI rischia di amplificare la confusione. Prima dell’agente può essere necessario intervenire su qualità dei dati, API e standardizzazione del workflow.
Dalla demo alla produzione
Portare tool use e function calling in produzione richiede valutazioni su casi reali, non solo test su domande ideali. Occorre misurare la corretta selezione del tool, la validità dei parametri, il tasso di completamento, le escalation umane, i tempi di risposta e gli errori per integrazione.
È utile partire da un processo circoscritto, con strumenti in sola lettura o con azioni reversibili, per costruire evidenze operative. Una volta validati qualità, sicurezza e adozione, il perimetro può crescere. L’obiettivo non è dare al modello accesso a tutto, ma assegnargli responsabilità precise che producano un impatto verificabile.
PurpleSoft progetta questo livello di architettura per collegare modelli linguistici, knowledge base, ERP, CRM, gestionali e software proprietari. Non semplici chatbot, ma sistemi AI integrati, controllabili e pronti per la produzione.
La domanda utile, quindi, non è “quale modello può usare le nostre API?”. È: quale attività vogliamo affidare all’AI, quali dati le servono davvero e quale controllo deve rimanere alle persone? Da questa risposta nasce un agente capace di lavorare nel processo, non di limitarsi a raccontarlo.
Hai un progetto software o un'idea da sviluppare?
Raccontaci in due righe cosa ti serve — software su misura, app, integrazioni o soluzioni AI. Ti rispondiamo entro un giorno lavorativo, senza impegno.
