Chiedi a quasi qualsiasi vendor cosa fa il suo agente AI e riceverai una risposta fluente: risponde a domande, sintetizza documenti, gestisce ticket. Spingi un po’ — “ma come legge concretamente il nostro ERP?” — e la conversazione diventa rapidamente vaga.
Quella vaghezza vale la pena di notarla. Il divario tra un agente che parla di fare qualcosa e uno che lo fa davvero si riduce a una cosa sola: l’uso degli strumenti. In particolare, come un agente è collegato ai tuoi sistemi reali — database, CRM, ERP, calendari, archivi documentali — e quali standard regolano quel collegamento.
Questo articolo spiega come gli agenti AI usano gli strumenti, cosa sia effettivamente il Model Context Protocol (MCP) e le domande concrete che dovresti porre a qualsiasi vendor prima di impegnarti.
La differenza tra un chatbot e un agente che lavora davvero
Un modello linguistico da solo non ha mani. Elabora testo e restituisce testo. Utile per bozze e sintesi, certo — ma non può controllare il tuo inventario, aggiornare un record cliente o emettere un ordine di acquisto senza qualcosa in più.
Quel qualcosa in più è l’uso degli strumenti — il meccanismo con cui un agente chiama funzioni esterne, API o servizi nel corso della conversazione e incorpora i risultati nel proprio ragionamento. L’agente riceve una descrizione degli strumenti disponibili (ad esempio: “get_order_status(order_id)”, “create_calendar_event(…)”), decide quale strumento chiamare e con quali parametri, lo esegue e usa la risposta per produrre un output utile o compiere il passo successivo.
È anche questo che distingue un agente AI da un semplice chatbot o copilot. Un chatbot recupera e riformula. Un agente con strumenti legge, decide, agisce.
Come appare concretamente l’uso degli strumenti
Immagina un responsabile della logistica che chiede a un agente: “Quali ordini aperti rischiano di non rispettare il termine di venerdì?”
Senza strumenti, l’agente inventa una risposta plausibile. Con gli strumenti, la sequenza è questa:
- L’agente chiama
get_open_orders(status="pending", due_before="2026-06-13")sul tuo ERP. - Riceve un elenco di dodici ordini con i relativi stati di spedizione.
- Chiama
get_estimated_delivery(order_id=...)per ciascuno di quelli con stato incerto. - Confronta le date di consegna stimate con il termine e segnala i tre a rischio.
- Restituisce un riepilogo con i numeri d’ordine, il ritardo in giorni e il nome del responsabile commerciale dal tuo CRM.
Niente di tutto ciò è possibile senza gli strumenti. Gli strumenti — e la capacità dell’agente di concatenarli in più chiamate — sono ciò che rende il risultato operativamente utile. Questa concatenazione di chiamate all’interno di un singolo compito è il nucleo di ciò che i workflow agentici significano nella pratica.
Dove si inserisce MCP: il livello di integrazione spiegato
Definire singoli strumenti per ogni sistema che un agente deve raggiungere è un lavoro di ingegneria costoso. Scrivi la funzione, gestisci l’autenticazione, il versioning delle API, e ripeti per ogni fonte di dati. Per poche integrazioni in un ambiente controllato, è gestibile. Per un’azienda con CRM, ERP, archivio documentale, sistema di ticketing e calendario — tutti di vendor diversi — diventa un onere di manutenzione significativo.
Model Context Protocol (MCP) è uno standard aperto, pubblicato da Anthropic alla fine del 2024, che cerca di risolvere questo problema. Nel dicembre 2025, Anthropic ha donato MCP all’Agentic AI Foundation (AAIF), un fondo diretto della Linux Foundation co-fondato da Anthropic, Block e OpenAI — rafforzando il suo status di standard genuinamente neutrale rispetto ai vendor. L’idea è semplice: invece di integrare le connessioni direttamente nell’agente, MCP definisce un’interfaccia comune. Un sistema che implementa MCP espone i propri dati e azioni come “MCP server”. Un runtime agente che supporta MCP può connettersi a qualsiasi server conforme senza lavoro di integrazione personalizzato per ogni sistema.
Pensalo come lo standard USB per i dati. Prima dell’USB, ogni periferica aveva il proprio connettore. Dopo l’USB, periferica e dispositivo devono solo concordare su un protocollo.
In termini pratici: un’azienda potrebbe avere un MCP server per il proprio CRM, uno per il proprio ERP e uno per il file system. Un agente compatibile con MCP può scoprire cosa offre ciascun server e chiamarlo — senza che lo sviluppatore dell’agente scriva codice su misura per ogni integrazione.
Cosa MCP non è
Vale la pena essere precisi sullo stato attuale di MCP. A metà del 2026, MCP è uno standard con un’adozione solida e in crescita. I principali provider di modelli (Anthropic, OpenAI, Google) si sono mossi verso il suo supporto, e un numero significativo di vendor enterprise ha realizzato interfacce conformi a MCP. Ma molti sistemi che la tua azienda gestisce realmente — in particolare database costruiti su misura, istanze ERP pesantemente modificate e applicazioni di nicchia — mancano ancora del supporto MCP e richiedono lavoro di integrazione personalizzato.
Nella maggior parte dei deployment reali, quindi, è ancora necessario un mix: MCP dove disponibile, definizioni di strumenti personalizzate dove non lo è. Qualsiasi vendor che affermi che MCP elimina tutto il lavoro di integrazione sta esagerando.
Le domande che ogni buyer deve fare
Capire come gli agenti usano gli strumenti non è solo teoria. Cambia il modo in cui valuti i vendor e cosa inserisci in un contratto. Ecco le domande che contano davvero:
Come l’agente accede ai miei sistemi specifici? Non “può integrarsi con i CRM” — chiedi: “Come si connette alla mia istanza di HubSpot / SAP / Odoo, e chi mantiene quella connessione quando aggiorni la versione?”
Quali strumenti usa e quali permessi ha ciascuno? Uno strumento che può solo leggere dati ha un profilo di rischio fondamentalmente diverso da uno che può scrivere o eliminare. Dovresti vedere un manifesto degli strumenti — un elenco di cosa l’agente può chiamare e quale scope ha ogni chiamata. Questo è centrale per la sicurezza degli agenti AI e merita la stessa attenzione del controllo degli accessi in qualsiasi altro sistema.
Supporta MCP, e quali dei miei sistemi hanno MCP server disponibili? Se la risposta è “usiamo MCP”, la domanda successiva è: “Per quali sistemi specificamente, e quali integrazioni sono ancora personalizzate?” I vendor onesti distinguono le due cose.
Cosa succede quando una chiamata a uno strumento fallisce? Un agente che ignora silenziosamente una chiamata API fallita e continua a ragionare è pericoloso. Vuoi sapere: fa un retry, espone l’errore, scala a un essere umano o si interrompe? Il comportamento in caso di fallimento delle chiamate agli strumenti è una parte sottovalutata nella maggior parte delle specifiche degli agenti.
Come vengono gestite e ruotate le credenziali degli strumenti? Ogni chiamata a uno strumento che tocca un sistema reale richiede autenticazione. Le API key e i token OAuth invecchiano e devono essere ruotati. Chiedi chi gestisce questo e se la gestione delle credenziali è automatizzata.
Un esempio concreto: cosa significa per un distributore di medie dimensioni
Un distributore all’ingrosso con 40 dipendenti gestisce il business su un ERP di fascia media, un processo di preventivazione basato su fogli di calcolo e un CRM che il team commerciale usa in modo inconsistente. Vogliono un agente che gestisca le richieste di stato degli ordini dai clienti e segnali i trigger di riordino al team acquisti.
Sulla carta, il caso d’uso è chiaro. In pratica, arrivarci significa:
- Costruire o reperire strumenti compatibili con MCP per il loro ERP (o scrivere wrapper API personalizzati se il supporto MCP non è disponibile nella loro versione)
- Definire l’esatto perimetro di cosa l’agente può leggere rispetto a cosa può scrivere
- Configurare i flussi di autenticazione che l’agente può usare a runtime
- Testare i casi limite — cosa succede quando i dati di stock sono obsoleti, quando un ID ordine non esiste, quando l’API ERP è irraggiungibile durante l’orario lavorativo
Niente di tutto ciò è insormontabile, ma niente è “basta collegare un agente.” Il livello di integrazione è dove vive la vera ingegneria, ed è dove tende ad apparire il divario tra una demo convincente e un sistema affidabile in produzione. Per saperne di più su cosa comporta realmente questo lavoro di integrazione, consulta la nostra guida su come connettere gli agenti AI al tuo CRM e ERP.
Come si presenta una buona architettura agente
Un agente ben costruito non ha gli strumenti aggiunti come ripensamento. Il livello degli strumenti è progettato dall’inizio con:
- Privilegio minimo: ogni strumento ha il set di permessi più ristretto che consente ancora il compito
- Chiamate osservabili: ogni invocazione di uno strumento è registrata con input, output, timestamp e il passo di ragionamento dell’agente che l’ha attivata
- Degradazione controllata: l’agente sa cosa fare quando uno strumento non è disponibile — che spesso significa “chiedi all’essere umano” anziché indovinare
- Interfacce con versioning: quando un’API sottostante cambia, la definizione dello strumento si aggiorna senza richiedere modifiche alla logica di ragionamento centrale dell’agente
Per uno sguardo più approfondito su come questi componenti si incastrano, architettura degli agenti AI spiegata per i decision maker copre il design complessivo del sistema.
Chi dovrebbe occuparsene adesso
Se stai valutando un progetto di agente AI e la tua risposta a “come si connette l’agente ai nostri sistemi?” è “non sono sicuro”, stai portando un rischio tecnico che si materializzerà in fase di implementazione. Non è un motivo per ritardare — è un motivo per fare le domande giuste prima.
Se hai già un agente in produzione che non hai costruito tu, questo è un buon momento per fare un audit del suo manifesto degli strumenti. Cosa può chiamare? Con quali credenziali? Quali sono i modi di fallire? La maggior parte delle organizzazioni che usano agenti di terze parti non ha mai revisionato questo aspetto.
Parla con noi dei tuoi requisiti di integrazione
In Orange ITS progettiamo agenti in cui il livello di integrazione è una priorità — non un ripensamento. Il nostro servizio di sviluppo agenti AI copre l’intero stack: progettazione degli strumenti, adozione di MCP dove applicabile, integrazione personalizzata dove non lo è, e l’infrastruttura di credenziali e osservabilità che garantisce l’affidabilità in produzione.
Se stai valutando un progetto agente e vuoi un secondo parere sulla solidità dell’approccio di integrazione — o se stai partendo da zero e vuoi evitare le trappole più comuni — prenota una call di 30 minuti con il nostro team. Analizzeremo insieme il tuo ecosistema di sistemi e ti daremo una valutazione diretta di cosa avrebbe bisogno un agente per connettersi a essi.