Un agente IA aziendale non è un modello linguistico con un prompt lungo. È un anello chiuso: il modello riceve un obiettivo, sceglie un’azione, chiama uno strumento esterno, legge il risultato e decide il passo successivo — finché l’obiettivo non è raggiunto, finché non si blocca, o finché non esaurisce il budget di passi. Sotto il cofano ci sono soltanto quattro componenti: modello, strumenti, memoria e controllo. Nell’indagine McKinsey del novembre 2025 (1.993 rispondenti in circa 105 paesi) circa il 62% delle organizzazioni stava sperimentando agenti ma solo il 23% circa li aveva portati in scala, e Gartner prevede che oltre il 40% dei progetti di IA agentica verrà cancellato entro la fine del 2027. Quel divario quasi mai sta nel modello.
Che cosa distingue davvero un agente da un chatbot
La differenza non è la qualità delle risposte. È chi decide l’ordine delle operazioni. In un chatbot decide la persona: fa una domanda, riceve del testo e decide che cosa farne. Nell’automazione classica decide lo sviluppatore, in anticipo: il processo è scritto come un diagramma di flusso e ogni ramo è stato definito in fase di costruzione. In un agente quella decisione si sposta al momento dell’esecuzione — è il modello a scegliere quale strumento chiamare, in quale ordine e quando fermarsi.
È l’unica differenza che conta, ed è anche l’origine di ogni rischio. Nel momento in cui l’ordine delle operazioni non è fissato in anticipo, non puoi più testare il sistema come si testa un software ordinario, e non puoi più contare sul fatto che l’esecuzione riuscita di ieri seguirà oggi lo stesso percorso.
| Proprietà | Chatbot | Automazione classica | Agente |
|---|---|---|---|
| Chi stabilisce l’ordine delle operazioni | L’utente | Lo sviluppatore, in fase di costruzione | Il modello, in fase di esecuzione |
| Accesso ai sistemi | In genere nessuno | Fisso e predefinito | Dinamico, attraverso un livello di strumenti |
| Comportamento in caso di errore | Restituisce una risposta sbagliata | Si ferma e segnala un errore | Prosegue e amplifica l’errore |
| Che cosa testi prima del lancio | La qualità della formulazione | I percorsi noti | La distribuzione dei risultati su più esecuzioni |
La frase chiave: un’automazione che si rompe si ferma. Un agente che si rompe continua a lavorare. Per questo il controllo è un componente del sistema, non qualcosa che si aggiunge alla fine.
Il ciclo di esecuzione: pianificare, agire, osservare
Indipendentemente dal fornitore, dal linguaggio o dal framework, ogni agente esegue lo stesso ciclo. Il modello riceve l’obiettivo e lo stato attuale del mondo, produce una decisione sul passo successivo, emette una chiamata verso uno strumento esterno, riceve un risultato — e poi rilancia sé stesso con quel risultato come parte del proprio contesto. Il ciclo termina quando il modello dichiara di aver finito, quando uno strumento restituisce un errore bloccante, o quando un meccanismo esterno lo interrompe.
La parola importante qui è osservare. L’agente non sa nulla del mondo se non ciò che gli strumenti gli restituiscono sotto forma di testo. Se il CRM restituisce un campo vuoto, allora per l’agente il cliente davvero non ha un numero di telefono. La qualità dell’osservazione è quindi una variabile ingegneristica di primo ordine, non un dettaglio tecnico.
| Fase del ciclo | Che cosa succede davvero | Modalità di errore tipica |
|---|---|---|
| Ricezione dell’obiettivo | L’obiettivo diventa contesto iniziale, accanto alle istruzioni di sistema | Un obiettivo vago che produce un percorso diverso a ogni esecuzione |
| Pianificazione del passo | Il modello seleziona uno strumento e i suoi argomenti | Strumento giusto, argomento sbagliato — l’errore più frequente in assoluto |
| Esecuzione | Il livello degli strumenti esegue la chiamata contro il sistema reale | Un permesso troppo ampio che consente un’azione distruttiva |
| Osservazione | Il risultato rientra nel contesto | Una risposta lunga che espelle informazioni critiche precedenti |
| Decisione | Continuare o fermarsi | Un ciclo infinito che brucia il budget fino al tetto massimo |
I quattro componenti di cui è fatto ogni agente
Smonta un agente e ottieni quattro componenti. Tre di questi non sono il modello, ed è lì che si concentra la maggior parte del lavoro ingegneristico e quasi la totalità dei fallimenti.
| Componente | Il suo compito | Che cosa si rompe quando è debole |
|---|---|---|
| Modello | Produce la decisione sul passo successivo | Formulazione elegante con ragionamento difettoso; cambiare modello non ripara gli altri componenti |
| Strumenti | L’unica interfaccia dell’agente con la realtà | Una descrizione imprecisa dello strumento porta a un uso sbagliato anche con un modello eccellente |
| Memoria e contesto | Ciò che l’agente sa nel momento della decisione | Informazioni critiche espulse, oppure un contesto inquinato che trascina l’agente sulla pista sbagliata |
| Controllo | Limiti, permessi, budget di passi e punti di approvazione | Nessun modo di fermare un errore prima che tocchi un cliente o un sistema |
Nei progetti che vediamo, la prima reazione quando qualcosa non funziona è quasi sempre cambiare modello. Nella maggior parte dei casi non è lì il problema. Descrizioni precise degli strumenti, output strutturato invece di testo libero e una condizione di arresto chiara migliorano il tasso di successo più di qualsiasi passaggio a un modello superiore.
Il livello degli strumenti: che cosa ha cambiato davvero MCP
Fino a poco tempo fa ogni collegamento tra un modello e un sistema aziendale veniva scritto da zero: un’integrazione su misura per ciascuna combinazione di modello e sistema. Model Context Protocol ha sostituito tutto questo con un livello uniforme — un server che dichiara strumenti e un client che li chiama.
La revisione stabile della specifica, datata 28 luglio 2026, è la revisione più ampia del protocollo dal suo lancio. Le sessioni a livello di protocollo e l’intestazione Mcp-Session-Id sono state rimosse dal trasporto Streamable HTTP; l’handshake initialize è stato eliminato; e gli elenchi di strumenti, risorse e prompt non variano più da una connessione all’altra, il che li rende memorizzabili nella cache. In parallelo sono arrivate le richieste a più round trip, l’instradamento basato sulle intestazioni, un quadro formale di estensioni e un’autorizzazione irrobustita. Un server che ha bisogno di stato tra una chiamata e l’altra lo riceve ora tramite un identificatore esplicito emesso dal server e passato come un normale argomento di strumento.
Perché questo conta per chi non scrive codice: un protocollo senza stato può essere distribuito dietro un bilanciatore di carico standard, scalato orizzontalmente e monitorato con strumenti ordinari. In altre parole, il livello degli strumenti ha smesso di essere un progetto di ricerca ed è diventato un’infrastruttura che si può mettere a budget, gestire e sottoporre ad audit. Se prevedi di far girare quel livello sulla tua infrastruttura, il modello di costo completo è nella nostra guida su come far girare gli agenti sul proprio hardware.
Il contesto è un budget, non un magazzino
L’errore di progettazione più comune è trattare la finestra di contesto come uno spazio di archiviazione. Non lo è. È un budget consumato a ogni passo, e lo paghi di nuovo a ogni chiamata. Un agente che esegue venti passi paga venti volte la propria cronologia.
Da qui discendono tre decisioni di progettazione. Restituire dagli strumenti un output strutturato e compatto invece di documenti interi. Comprimere la cronologia in un riepilogo di stato dopo un numero fisso di passi. Recuperare la conoscenza aziendale in fase di esecuzione invece di precaricarla. Il lato economico di queste decisioni è trattato nella nostra guida alla riduzione del costo dell’inferenza.
Dove si rompe nella pratica
Tre cause spiegano la maggior parte dei fallimenti che incontriamo.
Errori cumulativi. In un ciclo, un errore al terzo passo non resta al terzo passo. Entra nel contesto e da lì alimenta ogni decisione successiva. Il guasto visibile compare quindi lontano dal punto in cui è stato creato, ed è per questo che eseguire il debug di un agente richiede di tracciare un’esecuzione completa invece di ispezionare una singola risposta.
Misurazione ottimistica. La metrica di successo più diffusa chiede se l’agente ci sia riuscito una volta, in condizioni favorevoli. In produzione ciò che conta è la stabilità: stessa attività, cento esecuzioni, quante si sono concluse correttamente. Il divario tra questi due numeri è il divario tra una demo impressionante e un sistema su cui puoi contare. Colmarlo è il tema della nostra guida alla valutazione degli agenti.
Agent washing. Gartner stima che, tra le migliaia di fornitori che promuovono capacità agentiche, solo circa 130 offrano la cosa vera; gli altri stanno rietichettando assistenti esistenti, RPA e chatbot. La domanda che filtra più in fretta durante una trattativa commerciale: quali strumenti può invocare questo agente, e chi decide quando li invoca.
La stessa nota di Gartner contiene l’altra faccia della storia: entro il 2028 circa il 15% delle decisioni di lavoro quotidiane sarà preso in modo autonomo e il 33% delle applicazioni software aziendali includerà capacità agentiche, rispetto a meno dell’1% nel 2024. La direzione è chiara; ciò che si rompe sono i tempi e le aspettative.
Una checklist prima del tuo primo agente
- Definisci un’attività che finisce. Un’attività con una condizione di completamento non ambigua, non un’area di responsabilità aperta.
- Conta gli strumenti. Se un primo agente ha più di dieci strumenti, probabilmente hai mappato un ruolo aziendale invece di un’attività.
- Scrivi le descrizioni degli strumenti come contratti. Che cosa entra, che cosa esce, che cosa succede in caso di errore e quando lo strumento non deve essere usato.
- Fissa un budget di passi e un budget di token. Un tetto rigido che ferma il ciclo anche quando il modello è convinto di essere sulla strada giusta.
- Marca le azioni irreversibili. Inviare un’email, addebitare, cancellare, aggiornare uno stato visibile al cliente — tutte queste azioni richiedono un punto di approvazione umana.
- Definisci i permessi prima di scrivere un prompt. È il modello dei permessi a limitare i danni, non la formulazione delle istruzioni. La trattazione completa è nella nostra guida ai confini dell’agente.
- Registra ogni esecuzione. Senza un log completo di chiamate e risultati non c’è debug e non c’è miglioramento.
Se preferisci partire da una valutazione strutturata dello stato attuale, comincia dalle nostre aree di competenza. Se sai già che cosa vuoi mettere in produzione, parliamone direttamente dalla nostra pagina di contatto.
Domande frequenti
Qual è la differenza tra un agente IA e la normale automazione?
Nell’automazione l’ordine delle operazioni è fissato in anticipo da uno sviluppatore. In un agente il modello sceglie le proprie azioni in fase di esecuzione, in base all’obiettivo e a ciò che osserva. L’automazione si testa quindi lungo percorsi noti, mentre un agente si testa attraverso la distribuzione dei risultati su esecuzioni ripetute.
Serve un modello particolarmente potente per costruire un agente?
Nella maggior parte dei casi no. Il tasso di successo dipende più dalla qualità delle descrizioni degli strumenti, dalla gestione del contesto e dalle condizioni di arresto che dalla scelta del modello. Un modello più potente nasconde per un po’ i problemi di progettazione, ma rende anche più costoso ogni passo del ciclo.
Che cos’è MCP e perché ne parlano tutti?
Model Context Protocol è un protocollo uniforme per collegare i modelli a strumenti e fonti di dati. La revisione stabile del 28 luglio 2026 lo ha reso senza stato: niente più sessioni a livello di protocollo, elenchi di strumenti memorizzabili nella cache e autorizzazione irrobustita. In pratica questo permette di distribuire un livello di strumenti come una normale infrastruttura invece che come un progetto una tantum.
Quanto tempo serve per portare un primo agente in produzione?
Una singola attività con tre-cinque strumenti e un punto di approvazione umana arriva di solito in produzione in quattro-otto settimane. La maggior parte di quel tempo non va nella costruzione del ciclo; va in un’integrazione pulita dei sistemi, nella progettazione dei permessi e nella costruzione della suite di test.
Qual è il segnale che un agente non è adatto a un’attività?
Se puoi scrivere il processo come un diagramma di flusso completo senza decisioni ambigue, non ti serve un agente — l’automazione sarà più economica, più veloce e testabile. Un agente diventa conveniente quando lo spazio delle possibilità è troppo ampio per essere scritto in anticipo.