Carlo Poli

Dagli LLM (Large Language Models) iniziali verso l’Intelligenza Artificiale Agentica

Il Large Language Model (LLM) nasce come una “macchina del linguaggio”, uno strumento molto potente …… ma inizialmente limitato nella sua capacità di interagire con il mondo esterno…… da cui il lento e lungo percorso verso l’intelligenza artificiale agentica …

Corso di Alfabetizzazione di Intelligenza Artificiale di TOPForGrowth

Lezione 5 di 8

1. Il Contesto Evolutivo: Oltre il Testo (Slide 1-5)

1.1 La Genesi e la Limitazione del Paradigma Iniziale

L’analisi del percorso evolutivo dell’Intelligenza Artificiale Generativa, osservata attraverso la lente del corso “TOPForGrowth” del 7 Gennaio 2026, rivela una traiettoria che si dipana dalla staticità dei primi modelli linguistici verso la dinamicità dei sistemi agentici.1

Per comprendere appieno la magnitudo della rivoluzione attuale, è indispensabile dissezionare con rigore critico il punto di partenza: i Large Language Models (LLM) nella loro concezione originale, intesi fondamentalmente come pure “macchine del linguaggio”.2

Nelle fasi embrionali di questa tecnologia, e fino a tempi molto recenti, il paradigma dominante era quello del “text-to-text”.1 In questo schema operativo, l’input dell’utente veniva trasformato in un output testuale attraverso processi probabilistici complessi, senza tuttavia alcuna possibilità di deviazione verso azioni concrete o modifiche dello stato del mondo reale.

Sebbene potenti nella manipolazione sintattica e semantica, questi modelli presentavano limiti strutturali intrinseci che ne impedivano un uso realmente operativo nel business.1

La capacità di generare prosa, poesia o codice di alta qualità rimaneva confinata in una sorta di limbo digitale: il modello poteva descrivere un’azione con precisione millimetrica, ma non poteva eseguirla.2

Questa limitazione si manifestava principalmente in due dimensioni critiche analizzate nel materiale didattico:

Assenza di Azione (Action Gap): Il paradigma “text-to-text” permetteva al modello solo di generare parole. Non esisteva un ponte funzionale tra la generazione del token e l’esecuzione di un comando su un sistema informatico.1 Un sistema in grado di diagnosticare perfettamente un errore in una linea di codice, ma incapace di lanciare il processo di debug o di applicare la patch, offre un valore limitato in termini di automazione end-to-end.2 L’intelligenza rimaneva intrappolata nella finestra di chat, inerte di fronte ai sistemi che sapeva analizzare teoricamente.

Isolamento Operativo (Operational Isolation): L’LLM viveva metaforicamente in una “scatola chiusa” (black box), ermeticamente separata dal resto dell’infrastruttura tecnologica.2 Questo isolamento si articolava in tre sotto-deficienze cruciali:

Assenza di Memoria Strutturata: Il modello mancava di una memoria operativa che andasse oltre la singola conversazione (context window).1 Ogni interazione rappresentava una tabula rasa, impedendo la costruzione di flussi di lavoro complessi che richiedessero il mantenimento dello stato o la conoscenza delle preferenze storiche dell’utente.2
Disconnessione dal Mondo Esterno: L’LLM non possedeva “organi di senso” digitali.2 Non poteva connettersi a database in tempo reale, non poteva navigare sul web per verificare l’attualità di un’informazione, né poteva interagire con API di servizi terzi.1
Staticità della Conoscenza: La conoscenza del modello era congelata al momento del training (training cut-off), rendendolo intrinsecamente obsoleto e incapace di reagire a eventi recenti senza un nuovo, costoso addestramento.2

Questa architettura generava quello che il documento definisce il “Paradosso Iniziale dell’AI Generativa” 1: avevamo a disposizione un’intelligenza straordinaria nella comprensione e nel ragionamento, capace di superare esami universitari complessi, ma fondamentalmente inerte, isolata dal mondo che sapeva descrivere così bene.2

1.2 Il Cambio di Paradigma: Verso l’AI Agentica

Oggi stiamo assistendo a una transizione epocale che sposta il baricentro dall’LLM come “oracolo passivo” all’LLM come “agente attivo”.1

Questo cambiamento non è un semplice aggiornamento incrementale delle capacità del modello (come potrebbe essere l’aumento dei parametri o della dimensione del dataset), ma una ridefinizione completa dell’architettura in cui il modello è inserito.

Nella nuova visione presentata nel corso, l’LLM non fornisce più semplici risposte testuali, ma ottiene l’accesso a strumenti operativi, database esterni, API e ambienti di esecuzione.2 La transizione è netta e trasforma la natura stessa dell’interazione uomo-macchina:

Prima: Il modello generava parole.
Ora: Il modello interroga sistemi, elabora dati in tempo reale e, fattore cruciale, orchestra azioni complesse.1

L’apertura dell’LLM al mondo esterno genera nuove possibilità applicative che prima erano inimmaginabili.

Non siamo più di fronte a un sistema che simula una conversazione, ma a un sistema che lavora.2 L’integrazione con strumenti operativi significa che l’AI può leggere un database aziendale, interpretare i dati, decidere una strategia e attuare una modifica nel sistema gestionale (ERP, CRM), il tutto in autonomia o sotto una supervisione minima.

Caratteristica	Paradigma LLM Iniziale	Paradigma AI Agentica
Output Primario	Testo (Token)	Azioni e Decisioni
Connettività	Isolato (Offline/Black Box)	Connesso (API, DB, Web)
Memoria	Limitata alla sessione	Strutturata e Persistente (RAG)
Ruolo	Oracolo Passivo	Collaboratore Proattivo
Aggiornamento	Statico (Training Cut-off)	Dinamico (Real-time Data)

Questo passaggio segna l’ingresso nell’era dell’Intelligenza Artificiale Agentica.

L’agente AI si distingue dal semplice chatbot proprio per questa capacità di agency (agenzialità): la facoltà di agire sull’ambiente per modificarlo in funzione di un obiettivo.1

Se l’LLM tradizionale era un osservatore passivo della conoscenza cristallizzata nel suo training set, l’Agente AI è un attore partecipe nel flusso di dati e operazioni del presente, capace di “sporcarsi le mani” con i dati reali.

2. La Visione Sistemica: L’LLM come Sistema Operativo (Slide 6-12)

2.1 Software 3.0: Una Nuova Forma di Programmazione

Per comprendere la profondità strutturale di questa trasformazione, il corso adotta la prospettiva teorica visionaria proposta da Andrej Karpathy, ex Director of AI di Tesla, che classifica l’evoluzione del software in tre ere distinte.1

Questa tassonomia non è solo accademica, ma serve a inquadrare il cambiamento nel ruolo dello sviluppatore e dell’utente.

Software 1.0 (Codice Esplicito): È il paradigma tradizionale che ha dominato l’informatica per decenni. In questa fase, il software è costituito da regole scritte esplicitamente dall’uomo (C++, Python, Java). Il programmatore deve codificare ogni singola istruzione, ogni condizione if-then-else, ogni flusso logico e gestione delle eccezioni.2 È un approccio deterministico: la macchina esegue esattamente ciò che le viene ordinato, nulla di più e nulla di meno. La complessità è gestita interamente dalla mente umana, che deve prevedere a priori ogni possibile stato del sistema.1 Il limite è la scalabilità della complessità gestibile dal cervello umano.
Software 2.0 (Reti Neurali): Con l’avvento del Machine Learning e del Deep Learning, il paradigma è cambiato. Invece di scrivere regole, forniamo alla macchina coppie di input e output desiderati (dati di training) e lasciamo che sia la rete neurale a “scrivere” il programma interno durante l’addestramento (backpropagation).2 Il comportamento emerge dai dati, non da regole esplicite. Questo ha permesso di risolvere problemi percettivi (visione artificiale, riconoscimento vocale) impossibili da codificare con il Software 1.0, ma ha introdotto l’opacità della “black box”.1
Software 3.0 (Linguaggio Naturale): È l’era attuale, inaugurata dagli LLM avanzati. Qui il linguaggio naturale diventa la nuova forma di programmazione.2 Non scriviamo codice (Software 1.0) e non ci limitiamo a fornire dataset per l’addestramento (Software 2.0); dialoghiamo con il sistema descrivendo l’intenzione e il risultato atteso.1

In questo scenario del Software 3.0, l’interazione uomo-macchina subisce un’evoluzione radicale: l’utente descrive il “cosa” (l’obiettivo, l’intento), e l’LLM si occupa del “come” (la traduzione dell’intenzione in azioni, codice o chiamate API).2

L’LLM agisce come un compilatore semantico ultra-avanzato, traducendo l’ambiguità e la sfumatura del linguaggio umano in istruzioni macchina eseguibili.1 Prompt, contesto e dialogo iterativo sostituiscono la sintassi rigida dei linguaggi di programmazione, democratizzando l’accesso alla creazione di software complesso.

2.2 La Nuova Architettura: Il Sistema “LLM-centrico”

In questa visione sistemica, cambia radicalmente anche il modo in cui valutiamo, progettiamo e costruiamo le applicazioni.

L’LLM cessa di essere il prodotto finale da interrogare e diventa l’infrastruttura abilitante.2 Possiamo pensarlo come il “kernel” o il sistema operativo su cui costruiamo applicazioni intelligenti.1

Il valore di una soluzione AI moderna non risiede più nella valutazione del singolo modello in isolamento (contando i parametri o misurando l’accuratezza su benchmark accademici generalisti), ma nella valutazione dell’intero ecosistema.2

Un modello GPT-4 isolato è meno utile di un modello leggermente inferiore ma perfettamente integrato con gli strumenti aziendali e dotato di una memoria contestuale ricca.

L’equazione del valore diventa sistemica:

Valore = Modello + Strumenti + Contesto + Integrazione.2

Un sistema “LLM-centrico” moderno si fonda su quattro pilastri architetturali indispensabili, che devono essere orchestrati armoniosamente per funzionare:

Nucleo LLM (Il Motore di Ragionamento): Al centro del sistema c’è il modello linguistico (come GPT, Gemini, Claude). La sua funzione non è più quella di “sapere tutto” (ruolo delegato alla memoria esterna), ma di “ragionare su tutto”.2 Funge da unità di elaborazione cognitiva (CPU) che interpreta le richieste, pianifica le strategie, scompone i problemi complessi e decide quali strumenti attivare.1 La sua qualità primaria diventa la capacità di instruction following (seguire istruzioni complesse) e la logica deduttiva.
Layer di Strumenti (Tools & API): Sono le “mani” del sistema. Questo layer comprende le API, le funzioni custom, i collegamenti a database e i servizi SaaS che l’LLM può invocare.2 Attraverso questo strato, l’intenzione astratta del modello si trasforma in azione concreta: inviare una mail, interrogare un CRM, eseguire uno script Python, calcolare una formula.1 Senza questo layer, l’LLM rimane un filosofo teorico; con esso, diventa un operatore pratico.
Memoria e Contesto: Se l’LLM è la CPU, questa è la RAM e l’Hard Disk. I sistemi moderni necessitano di uno storage strutturato per mantenere la continuità delle conversazioni (short-term memory) e per accedere a una base di conoscenza aziendale vasta e persistente (long-term memory, spesso gestita tramite RAG e database vettoriali).2 Questo garantisce che l’agente “conosca” l’utente, il progetto e l’azienda, offrendo risposte personalizzate e coerenti nel tempo, superando l’amnesia tipica delle sessioni chat isolate.1
Controllo e Sicurezza (Guardrails): In un sistema deterministico (Software 1.0), la sicurezza è codificata nelle regole. In un sistema probabilistico (Software 3.0), la sicurezza deve essere imposta tramite meccanismi di validazione, autenticazione e “guardrail” etici e operativi.2 Questo layer assicura che le azioni dell’LLM siano non solo efficaci, ma anche sicure, appropriate e conformi alle policy aziendali, prevenendo output dannosi, iniezioni di prompt avversari o fughe di dati sensibili.1

2.3 Sfide e Considerazioni Critiche nell’Implementazione

L’implementazione di questa architettura non è esente da sfide significative che richiedono un approccio ingegneristico maturo, definito nel documento come “AI System Engineering”.1

Non basta collegare un LLM a internet per avere un agente funzionante; bisogna gestire complessità emergenti tipiche dei sistemi non deterministici:

Affidabilità e Allucinazioni: Gli LLM sono motori probabilistici che predicono il prossimo token, non motori di verità. Possono generare informazioni plausibili ma false (“allucinazioni”). In un contesto creativo questo può essere accettabile, ma in un contesto operativo (es. eseguire un bonifico, modificare un record database o diagnosticare un guasto industriale) è critico.2 È essenziale implementare meccanismi di verifica (grounding), validazione umana (human-in-the-loop) o validazione automatica (code execution checks) delle azioni proposte dall’agente prima della loro esecuzione finale.1
Privacy e Sicurezza dei Dati: Integrare l’LLM con i dati aziendali solleva enormi questioni di governance. I dati sensibili non devono finire nel training set dei modelli pubblici. Inoltre, l’agente deve rispettare le ACL (Access Control Lists) aziendali: non deve poter leggere documenti HR riservati o bilanci non pubblicati solo perché un dipendente senza i giusti privilegi glielo chiede.2 La sicurezza deve essere granulare e contestuale.
Costi Operativi: Ogni chiamata all’LLM e ogni utilizzo di tool ha un costo (token cost, API cost). Un’architettura mal progettata che esegue loop infiniti, query ridondanti o che utilizza il modello più costoso per task banali può diventare rapidamente antieconomica.2 L’ottimizzazione del rapporto costo/prestazioni, selezionando il modello giusto per il task giusto (model routing), è una nuova competenza chiave.
Latenza e User Experience: Le risposte generate da LLM complessi, specialmente se richiedono più passaggi di ragionamento (Chain of Thought) o l’uso di tool esterni sequenziali, richiedono tempo.2 L’interfaccia utente deve gestire questa latenza in modo elegante, informando l’utente sullo stato del processo (“Sto cercando nel database…”, “Sto analizzando il documento…”) per mantenere la fiducia e l’engagement, evitando che l’utente percepisca il sistema come bloccato o lento.1

3. L’Ecosistema OpenAI: I GPTs (Slide 13-20)

3.1 I Custom GPTs come Prototipo di Agente Enterprise

Nell’ecosistema attuale, i Custom GPTs di OpenAI rappresentano il primo passo maturo, standardizzato e accessibile verso i sistemi agentici per l’uso enterprise.1 Non sono semplici interfacce conversazionali: sono “capsule” di intelligenza configurata che incapsulano istruzioni, conoscenza specifica e capacità operative, offrendo quella stabilità e riproducibilità necessarie per l’integrazione nei processi aziendali.

L’evoluzione tecnologica sottostante, in particolare il passaggio da GPT-3.5 a GPT-4 e verso GPT-5, è stata fondamentale per abilitare questa fase. I modelli più recenti hanno dimostrato una capacità nettamente superiore nella comprensione di istruzioni complesse (nuance) e, soprattutto, una maggiore affidabilità nel seguire le regole imposte (policy compliance).1

Questo riduce drasticamente il rischio che l’agente “esca dal personaggio”, ignori i vincoli di sicurezza o fallisca nel completare task multi-step, rendendo possibile l’affidamento di task semi-autonomi.2

I GPTs si distinguono per l’integrazione nativa di tre “motori” fondamentali che trasformano il modello da semplice oracolo conversazionale a lavoratore digitale 1: RAG, Tools e Actions.

3.2 I Tre Motori dei GPTs

3.2.1 RAG (Retrieval-Augmented Generation): Separare Intelligenza e Conoscenza

Il RAG rappresenta un principio architetturale cruciale che risolve il problema dell’obsolescenza e delle allucinazioni: il disaccoppiamento tra l’intelligenza (il modello di ragionamento) e la conoscenza (i dati).1

Nei modelli tradizionali, la conoscenza era “congelata” nei pesi della rete neurale al momento del training (conoscenza parametrica). Questo rendeva il modello obsoleto il giorno dopo il rilascio e incline ad allucinare fatti che non conosceva o ricordava male.2

Con il RAG, il modello agisce come un motore di elaborazione che attinge a una “memoria esterna controllata”.2

Quando l’utente pone una domanda specifica su un progetto aziendale, il sistema non cerca la risposta nel suo “cervello” pre-addestrato, ma recupera i documenti rilevanti dalla knowledge base aziendale (vettorizzata e indicizzata) e li usa come contesto per generare la risposta.1

I vantaggi strutturali sono triplici:

Fonti Verificabili e Tracciabili: Il sistema può citare esattamente quale documento, pagina o paragrafo ha usato per rispondere, aumentando la fiducia dell’utente (audit trail).
Aggiornabilità Dinamica: Basta caricare un nuovo PDF o aggiornare un record nella knowledge base perché l’agente “impari” le nuove procedure istantaneamente, senza costosi e lenti riaddestramenti del modello (fine-tuning).2
Riduzione delle Invenzioni: Vincolando il modello a rispondere “basandosi solo ed esclusivamente sui documenti forniti” (grounding), si abbattono drasticamente le allucinazioni, costringendo il modello ad ammettere l’ignoranza se l’informazione non è presente.1

3.2.2 Tools: Le Protesi Cognitive

Se il RAG fornisce la memoria, i Tools forniscono le capacità analitiche e computazionali.

Vengono definiti efficacemente nel documento come “protesi cognitive”.1 Un LLM, per sua natura, è un modello linguistico probabilistico, non una calcolatrice o un interprete di codice. Non è intrinsecamente bravo a fare calcoli matematici precisi o ad analizzare file binari complessi.2

I Tools (come Code Interpreter o Advanced Data Analysis) permettono al modello di delegare questi compiti specifici a strumenti deterministici. Il modello decide autonomamente quando usarli in base alla richiesta dell’utente.1 Se gli chiediamo “Qual è la radice quadrata di 4567 moltiplicata per il fatturato del Q3 estratto dal file Excel?”, il modello:

Capisce che serve un calcolo preciso e un’analisi dati.
Scrive ed esegue un pezzo di codice Python in un ambiente sandbox sicuro per estrarre il dato ed eseguire l’operazione.
Usa il risultato numerico esatto del codice per formulare la risposta verbale finale.
In questo modo, i tool aiutano il modello a pensare meglio, estendendo le sue capacità native e garantendo precisione laddove il linguaggio naturale fallisce.2

3.2.3 Actions: Agire sul Mondo Reale

Le Actions sono il ponte verso l’esterno, il meccanismo che conferisce “agenzialità”. Mentre i Tools operano spesso in un ambiente sandbox interno (es. per analizzare un file caricato), le Actions permettono al GPT di collegarsi a qualsiasi software terzo o servizio web tramite API standard.

È qui che avviene il passaggio fondamentale da “pensiero” a “impatto reale”.

Un GPT configurato con le giuste Actions può:

Consultare la disponibilità reale su Google Calendar.
Inviare un messaggio su Slack a un canale specifico.
Creare, aggiornare o chiudere un ticket su Jira o Trello.
Interrogare un database SQL di produzione o un CRM come Salesforce.

L’Action definisce lo schema di comunicazione (spesso tramite specifiche OpenAPI/Swagger), ma è l’LLM a compilare i parametri della chiamata API basandosi sulla richiesta dell’utente in linguaggio naturale.

Questo rende l’integrazione fluida: l’utente dice “Prenota una riunione con Marco per martedì”, e l’LLM traduce l’intento in una chiamata POST /calendar/events con i parametri JSON corretti (data, ora, partecipanti).1

3.3 Il Futuro: MCP (Model Context Protocol)

Nonostante la potenza dei GPTs, l’ecosistema attuale soffre di una grave frammentazione: ogni integrazione è spesso un “silos” isolato, difficile da mantenere e replicare su diversi agenti.

Per superare questo limite e scalare verso sistemi complessi e interoperabili, sta emergendo lo standard MCP (Model Context Protocol).1

L’MCP mira a standardizzare il modo in cui l’AI accede ai dati e agli strumenti, creando un protocollo universale simile a quello che l’USB è stato per le periferiche hardware.2

Invece di costruire integrazioni custom “hard-coded” per ogni singolo agente (Actions specifiche per un solo GPT), l’MCP permette di creare “building blocks” riutilizzabili.

Un server MCP che fornisce accesso al database aziendale può essere collegato a qualsiasi client AI (Claude, GPT, IDE come Cursor, ecc.) in modo uniforme, senza dover riscrivere il codice di integrazione.1

Questo protocollo abilita quattro caratteristiche chiave per il futuro degli agenti, trasformando l’architettura da monolitica a modulare:

Accesso Standardizzato: Un’interfaccia uniforme per tool, dati e servizi, indipendentemente dal fornitore.
Disaccoppiamento: Il modello è indipendente dall’ambiente operativo; posso cambiare modello (da GPT-4 a Claude 3.5) mantenendo gli stessi strumenti e accessi ai dati.
Componibilità: Posso assemblare agenti complessi combinando blocchi MCP esistenti (es. Blocco Google Drive + Blocco Slack + Blocco Analisi Dati) come se fossero mattoncini LEGO.
Ecosistema Integrato: Si passa da singoli GPT isolati a una rete di intelligenze connesse che condividono contesto e capacità, creando un vero tessuto connettivo per l’intelligence aziendale.1

La scelta tra usare semplici Actions o adottare MCP non è binaria ma evolutiva: le Actions rimangono perfette per integrazioni semplici, rapide e puntuali, mentre MCP diventa essenziale quando l’architettura AI dell’azienda cresce in complessità e necessita di governance, scalabilità e riuso sistematico delle capacità.2

4. L’Approccio Google: I Gems (Slide 21-24)

4.1 Filosofia Workflow-Driven vs Engineering-Driven

Nel panorama degli assistenti AI personalizzabili, emerge una chiara distinzione filosofica tra i due principali attori. Mentre OpenAI con i suoi GPTs persegue un approccio che possiamo definire “engineering-driven” (orientato alla costruzione di sistemi complessi, altamente personalizzabili, strutturati e ricchi di tool esterni), Google con i suoi Gems adotta una filosofia distinta: “workflow-driven”.1

L’obiettivo primario dei Gems non è tanto permettere agli sviluppatori di costruire architetture elaborate con azioni API complesse verso terze parti, quanto ridurre l’attrito cognitivo nel lavoro quotidiano dell’utente medio.2 Si punta alla semplicità di configurazione e all’immediatezza d’uso, democratizzando la creazione di assistenti.

Caratteristica	OpenAI GPTs	Google Gems
Filosofia	Engineering-driven (Costruire sistemi)	Workflow-driven (Migliorare flussi)
Target	Sviluppatori, Power Users	Utenti Workspace, Office Workers
Personalizzazione	Alta (Actions, API, Auth)	Focalizzata (Istruzioni, Stile)
Integrazione	Esterna (tramite Actions/API)	Nativa (Ecosistema Google)
Focus	“App” AI autonome	Produttività quotidiana integrata

Questa differenza filosofica si riflette nell’esperienza utente: i Gems sono pensati per essere assistenti contestuali che si inseriscono nel flusso di lavoro esistente senza richiedere setup tecnici onerosi.

Non si tratta di “costruire sistemi”, ma di potenziare la produttività individuale, permettendo all’utente di lavorare meglio ogni giorno senza dover “programmare” un agente.2

4.2 Integrazione Nativa con l’Ecosistema Google Workspace

Il vero vantaggio competitivo (il “moat” strategico) dei Gems risiede nella loro integrazione nativa, profonda e senza soluzione di continuità con l’ecosistema Google Workspace.1

Mentre un GPT richiede configurazioni di Actions, gestione di chiavi API e autenticazioni OAuth complesse per accedere a file esterni, un Gem in ambiente Google ha accesso diretto, sicuro e immediato ai dati dell’utente aziendale:

Google Drive: Per il recupero contestuale di file, PDF, fogli di calcolo e knowledge base personale o di team.
Google Docs: Per leggere, analizzare e generare documenti direttamente nell’editor, mantenendo la formattazione.
Gmail: Per gestire la posta, sintetizzare thread lunghi, estrarre action item e bozzare risposte nello stile dell’utente.
Google Calendar: Per gestire l’agenda, trovare slot liberi e comprendere il contesto temporale dell’utente.2

Questa integrazione elimina le barriere tecniche all’adozione.

Un utente non tecnico può creare un Gem “Project Manager” semplicemente istruendolo a “leggere tutti i documenti nella cartella ‘Progetto X’ su Drive e monitorare le mail relative da quel cliente”, senza scrivere una riga di codice o configurare server.1

La continuità fluida tra i dati e l’intelligenza è il valore chiave: i dati sono sempre accessibili, il contesto è preservato e le attività quotidiane sono integrate in un unico flusso operativo privo di frizioni.2

5. La Frontiera: I Veri Agenti Autonomi (Slide 25-29)

5.1 Oltre i GPTs e i Gems: Agenti in Potenza

Nonostante i notevoli progressi descritti nelle sezioni precedenti, è fondamentale mantenere una lucidità tecnica e distinguere tra gli strumenti attuali e la visione futura: GPTs e Gems, allo stato attuale dell’arte (Gennaio 2026), sono definibili come “agenti in potenza”, ma mancano ancora di piena autonomia operativa.1

Rappresentano le fondamenta infrastrutturali necessarie (stabilità comportamentale, contesto persistente, integrazione con tool), ma soffrono ancora di limiti operativi significativi che li distinguono dai veri Agenti AI autonomi che rappresentano la prossima frontiera:

Pianificazione Limitata: Non sono ancora in grado di scomporre autonomamente e affidabilmente obiettivi macroscopici complessi in piani articolati multi-step a lungo termine senza una guida umana significativa o prompt molto strutturati.2 Faticano a gestire dipendenze temporali complesse tra task.
Mancanza di Feedback Loop Continuo: Operano tipicamente in modalità “one-shot” o conversazionale (turn-based). Eseguono un comando e si fermano in attesa del prossimo input o approvazione. Non hanno un ciclo di vita autonomo che prosegue indefinitamente finché l’obiettivo non è raggiunto.2
Reattività vs Proattività: Sono sistemi reattivi: reagiscono agli stimoli dell’utente ma raramente anticipano i bisogni, monitorano l’ambiente in background o ottimizzano le loro strategie nel tempo basandosi sull’esperienza passata (apprendimento intra-sessione limitato).2

5.2 Il Loop Operativo (Il Ciclo di Feedback)

Ciò che distingue ontologicamente un vero Agente AI da un chatbot avanzato o da uno script di automazione è il suo Loop Operativo (o Ciclo di Feedback).1

Un sistema tradizionale lineare esegue una sequenza predeterminata: Input -> Elaborazione -> Output -> Stop.

Un Agente AI opera in un ciclo ricorsivo continuo che ricorda il ciclo OODA (Observe-Orient-Decide-Act) 2:

Comprensione (Perception/Understanding): L’agente analizza l’obiettivo di alto livello fornito dall’utente e il contesto attuale. Non si limita a leggere il prompt, ma “guarda” lo stato del sistema, le variabili ambientali e le risorse disponibili.2
Pianificazione (Reasoning/Planning): Prima di agire, l’agente sviluppa una strategia. Scompone il problema complesso in sotto-task gestibili (Decomposition) e ordina le azioni in una sequenza logica (Chain of Thought), anticipando potenziali ostacoli.1
Azione (Execution): L’agente esegue il primo passo pianificato utilizzando gli strumenti a sua disposizione (Tools/Actions). Muove il cursore, invia la mail, esegue la query SQL, chiama l’API.2
Osservazione (Observation): Questa è la fase critica spesso assente nei sistemi semplici. L’agente “legge” il risultato della sua azione. La mail è partita? Il database ha restituito un errore? Il file è stato creato correttamente? Il sito web è cambiato?.1
Correzione e Iterazione (Reflection/Correction): L’agente valuta se il risultato ottenuto lo ha avvicinato all’obiettivo finale.

Successo: Procede al passo successivo del piano.
Fallimento: Non si blocca e non chiede subito aiuto all’umano (a meno che non sia critico). Modifica la strategia, prova un tool diverso, riformula la query, debugga il suo stesso codice e riprova (Self-Correction).2

Questo ciclo iterativo è ciò che permette l’apprendimento e l’adattamento continuo all’interno della sessione di lavoro. Trasforma l’AI da assistente passivo, che richiede micro-management passo dopo passo, a collaboratore proattivo orientato al risultato (outcome-oriented), capace di gestire l’incertezza e gli imprevisti.1

5.3 Il Ciclo Continuo di Sviluppo di un Sistema Agentico

Costruire questi sistemi richiede un approccio iterativo anche lato sviluppo, definendo una nuova disciplina: l’AI System Engineering. Il ciclo di sviluppo non finisce con il deployment, ma è continuo 2:

Build Rapido: Prototipare velocemente l’agente, definendo il prompt di sistema (System Prompt) e i suoi tool.
Osservazione (Tracing): Raccogliere tracce reali (traces) delle esecuzioni dell’agente. Non basta guardare l’output finale; bisogna ispezionare il “pensiero” intermedio (Chain of Thought) per capire dove fallisce il ragionamento o l’uso del tool.
Error Analysis: Categorizzare i fallimenti in modo sistematico (es. il modello non ha capito il tool? Il tool ha dato errore tecnico? Il piano era sbagliato logicamente? Il contesto era insufficiente?).
Eval (Valutazione): Costruire metriche automatiche per misurare l’affidabilità (reliability). Non ci si può basare sul “sembra funzionare”; serve sapere se “funziona nel 95% dei casi” su un dataset di test (Golden Set).
Ottimizzazione: Raffinare il prompt di sistema, migliorare le descrizioni dei tool per renderli più comprensibili al modello, pulire la knowledge base RAG, o passare a un modello più performante.2

6. Appendice: Casi d’Uso e Prompt Engineering Avanzato (Slide 30-40)

L’analisi teorica trova la sua validazione nell’applicazione pratica.

Nella lezione del corso vengono analizzati cinque casi d’uso reali, che dimostrano come configurare (prompt engineering) e strutturare questi sistemi per compiti specifici, spaziando dall’educazione all’ingegneria pesante. Questi esempi illustrano come la combinazione di istruzioni, knowledge base e tool crei valore specifico.

Nota Conclusiva:

Il percorso delineato in questo documento, dagli LLM iniziali agli Agenti AI, non rappresenta solo un’evoluzione tecnologica, ma un cambio di paradigma fondamentale nel modo in cui concepiamo, costruiamo e utilizziamo il software.

Stiamo passando da strumenti che usiamo a collaboratori digitali che deleghiamo.

La comprensione profonda di questa architettura (Modello + RAG + Tools + Loop Agentico) e delle sue implicazioni (nuovi paradigmi di programmazione, sfide di sicurezza, necessità di governance) costituisce oggi la competenza fondamentale per chiunque voglia operare con successo nell’era del “Software 3.0”.

Il documento qui presentato, basato rigorosamente sui materiali del corso TOPForGrowth del 7 Gennaio 2026, fornisce la mappa concettuale, tecnica e pratica per navigare questa transizione epocale.

Bibliografia

Dall’LLM all’Agente AI
Corso-AI-Alfabetizzazione-7-Gennaio-2026.pdf