Agenti AI in produzione: la sindrome del proof of concept (e come uscirne)

Ho fatto una lunga chiacchierata con Raffaele Gaito per il suo podcast What's Next, e abbiamo toccato un numero di temi che normalmente avrei distribuito su tre o quattro articoli diversi.

Siamo partiti dalla domanda più scomoda di tutte, quella che chiunque lavori con l'AI dovrebbe porsi più spesso: quanto è ampia, oggi, la distanza tra quello che si racconta sugli agenti AI e quello che succede davvero quando li si porta in produzione, dentro un'azienda vera, con dati veri e budget veri? Da lì abbiamo aperto il cofano, punto per punto:

• perché "solidità" è la parola giusta per parlare di agenti, e cosa prova a risolvere Web MCP, la proposta di Google (e Microsoft) per costruire siti pensati anche per essere "letti" dagli agenti;
• perché il prompt engineering non è affatto morto, anzi con modelli più performanti ha più senso che mai investirci tempo, e cos'è il metaprompting;
• quanto contano ancora le competenze verticali (di chi programma, scrive, fotografa) quando tutti hanno accesso agli stessi strumenti;
• a che punto siamo con i modelli visivi, tra controllo, replicabilità e nuove frontiere multimodali;
• perché, se lo strumento è lo stesso per tutti, il vero vantaggio competitivo diventa l'idea;
• le tecniche molto concrete con cui abbiamo tagliato del 90% i costi di un sistema agentico, usando lo stesso identico modello;
• la cosiddetta "frontiera irregolare" dell'AI, e perché non tutto va risolto con un prompt;
• e per finire, come sempre in questi casi, una domanda che mi mette sempre un po' in difficoltà: qual è il valore umano, il mio valore, in un mondo che accelera così in fretta?

Qui sotto trovi il video integrale della chiacchierata. In questo articolo ho riorganizzato, approfondito e verificato i concetti principali che abbiamo toccato, con qualche aggiunta e qualche link per chi vuole andare oltre.

Agenti AI in produzione: la sindrome del proof of concept

Alla domanda diretta, quanto è ampia oggi la distanza tra la narrazione sugli agenti AI e quello che succede davvero quando li si porta in produzione, la mia risposta è secca: è ampia. E credo si possa misurare lungo due assi.

Il primo è la potenzialità: cosa questi sistemi ci permettono di fare. Il secondo, molto più scomodo, è l'affidabilità.

È bellissimo costruire un agente, magari un sistema multi-agente connesso a decine di tool e server MCP (Model Context Protocol), che risolve un task complesso in 30 secondi. Cambia completamente musica quando quel task deve essere svolto decine di migliaia di volte al giorno, tutti i giorni, senza intervento umano. A quel punto non stiamo più parlando dello stesso problema: è un problema di ingegneria completamente diverso da quello della demo.

Quando inizi ad "aprire il cofano" di un sistema agentico reale, scopri quasi sempre la stessa cosa: la maggior parte dell'effort non è nella costruzione dell'agente né nell'uso del modello. Aprire il playground di un provider e mettere in piedi un agente, oggi, è questione di minuti: è più che sufficiente per una demo. Il vero lavoro è nel layer applicativo: capire quali dati servono all'agente per compiere le operazioni, come si integrano i flussi, come si progetta l'osservabilità, come si tiene sotto controllo la scalabilità e, soprattutto, i costi.

È proprio questo scarto che mi piace chiamare la sindrome del proof of concept che funziona. Il proof of concept è, per definizione, un'idea che funziona in condizioni controllate. Ma l'execution, quella che trasforma l'idea in un'applicazione reale, è un mestiere a parte, e nessuno lo racconta nelle demo.

Il problema non risparmia nessuno, nemmeno le grandi aziende che ci vendono questi strumenti: nelle presentazioni di chi vende soluzioni AI tutto sembra sempre perfetto, tutto "wow". Il salto che manca è chiedersi: questa cosa, se la metto in un'azienda vera con problemi veri, sopravvive al terzo giorno senza "scassarsi"? E soprattutto: quanto costa? Perché quando si parla del costo di un singolo prompt si parla sempre di centesimi: costi bassissimi, quasi trascurabili. Ma moltiplicati per migliaia di interazioni al giorno, quei centesimi si trasformano in migliaia di euro con estrema facilità.

C'è poi un tema che riguarda proprio come si valuta la solidità di una soluzione prima ancora di metterla in produzione: non fidarsi mai dei benchmark che arrivano insieme al prodotto. Che il numero arrivi da Google, OpenAI, Anthropic o Microsoft, lascia un po' il tempo che trova: c'è sempre una componente di marketing in quei numeri. L'unico benchmark davvero utile è quello che si costruisce internamente, su dati e casi reali della propria organizzazione: testare su piccoli insiemi di dati prima di scalare, e portare la soluzione in produzione gradualmente, un pezzo alla volta, proprio per imparare a conoscere uno strumento che, a differenza del software che sviluppiamo internamente, non abbiamo progettato noi.

Web MCP: verso i siti pensati (anche) per gli agenti

Il tema della solidità torna in un contesto molto specifico: quello dell'agentic browsing. Oggi, quando un sistema come ChatGPT o Gemini viene messo in modalità agentica per navigare il web, cosa succede davvero? Il sistema usa un browser interno, naviga tra le pagine e usa la visione artificiale per interpretare cosa c'è sullo schermo: capisce, in base al task che gli abbiamo dato, che quel pulsante serve ad aprire la scheda prodotto, quell'altro a metterlo nel carrello, e così via.

Descritta così, il problema si vede subito: c'è un ampio margine di interpretazione. L'agente deve dedurre il significato degli elementi della pagina, un po' come farebbe una persona che la visita per la prima volta. Basta un configuratore di prodotto un po' complesso, dove un'azione carica dinamicamente altre opzioni, perché il comportamento dell'agente diventi imprevedibile, perché fatica a "leggere" correttamente cosa è cambiato nell'interfaccia.

È esattamente questo il problema che Web MCP cerca di risolvere. Attenzione: a oggi non è ancora un protocollo formale, ma una proposta: pubblicata da Google insieme a Microsoft e portata avanti in un community group del W3C, con una prima origin trial già attiva su Chrome. L'idea di fondo, però, è già molto chiara: quando un agente arriva su una pagina costruita con Web MCP, non deve più usare la visione artificiale per interpretarne gli elementi, perché il front-end espone in modo esplicito delle funzioni, delle vere e proprie API, pensate apposta per essere chiamate da un agente. L'agente, a quel punto, non ha più spazio per l'interpretazione: sa che può eseguire un numero definito di operazioni, e per ciascuna userà la funzione corrispondente.

L'interazione diventa, in altre parole, molto più programmatica che interpretativa: è come se l'agente lavorasse dietro le quinte, invece di dover "cliccare" fisicamente sul bottone. Le funzionalità disponibili per una persona e per un agente restano le stesse, ma il modo in cui vengono percepite ed eseguite cambia del tutto: se sei un essere umano vedi (e clicchi) l'interfaccia; se sei un agente, chiami direttamente la funzione.

Qualche anno fa, quando l'agentic mode ha iniziato a diffondersi, si parlava genericamente della necessità di creare "pagine per gli agenti". Con Web MCP il concetto si affina: la pagina resta quella pensata per le persone, ma le si affianca uno strato applicativo aggiuntivo, dedicato a chi la visita non con gli occhi ma con delle chiamate di funzione. Per chi lavora nell'e-commerce questo significa un livello in più da progettare e mantenere, ma anche una solidità dell'interazione che oggi, con la sola visione artificiale, semplicemente non c'è.

Il prompt engineering non è morto: si è solo evoluto

Girando per conferenze e aule, sento spesso ripetere una frase diventata quasi uno slogan: "il prompt engineering è morto". È una delle narrazioni tipiche del web: ogni volta che arriva un'innovazione, deve morire qualcosa. E in effetti anche io, quando vedo persone insistere su approcci datati, uso spesso una provocazione simile per stimolare la riflessione: dico scherzosamente che si stanno comportando come se fosse ancora il 2025.

Ma dietro alla frase "il prompt engineering è morto" c'è, dal mio punto di vista, un forte equivoco. Il ragionamento di chi la sostiene è più o meno questo: i modelli sono sempre più performanti, quindi non ha più senso investire tempo nella costruzione di un buon prompt. Io la vedo diversamente, e la vedo così perché tengo aperti due canali di osservazione in parallelo.

È vero che i modelli sono sempre più performanti. Ma "più performante" non significa che il modello sia più in grado di leggerci nella mente, di estrapolare quello che non abbiamo scritto nelle istruzioni: su questo, prima o poi, ci si scotta tutti. "Più performante" significa, piuttosto, che il modello è più in grado di cogliere ogni dettaglio delle istruzioni che gli diamo. Cambia quindi il modo di fare prompting, ma cambia nella direzione opposta a quella che molti immaginano: se prima l'effort andava nel tentativo di compensare un modello poco performante, oggi ha più senso investire quello stesso effort nel dettagliare, sapendo che un modello più capace ci seguirà fedelmente in ogni sfumatura.

Non è un caso, e non lo dico per autocelebrazione ma perché è un dato di fatto, che le metodologie di prompting che ho messo a punto negli anni non abbiano quasi mai avuto bisogno di essere riviste in profondità. Se costruisci una struttura, un metodo per creare prompt strutturati, dettagliati e precisi, quello diventa un asset che nel tempo si trasforma in un ingranaggio del flusso aziendale, perché quelle stesse istruzioni, opportunamente adattate, diventano poi il system prompt degli agenti. Nella parte agentica il prompt engineering conta persino di più, perché lì possiamo davvero esercitare un controllo superiore rispetto alle generazioni precedenti di modelli, a patto di dare istruzioni strutturate, dettagliate e controllate.

C'è un secondo livello, complementare al primo, che riguarda le domande che il sistema fa a noi prima di eseguire un task. È un'abitudine che consiglio spesso: qualsiasi cosa si stia chiedendo a un sistema come un coding agent, vale la pena chiedergli sempre, prima di procedere, di farci qualche domanda di chiarimento. Capita continuamente di dimenticare un dettaglio importante, e un sistema che chiede "questo processo lo vuoi così o così?" evita di scoprirlo solo alla fine, sull'output sbagliato.

Lo stesso principio, applicato prima ancora di scrivere il prompt, si chiama metaprompting: usare l'AI stessa per analizzare un prompt, trovarne le lacune, e farsi aiutare a correggerlo direttamente in quella sede. È un approccio che diventa ancora più utile per i contenuti visuali, dove essere oggettivi nella descrizione di un'idea è molto più difficile che con il testo. Per questo, negli anni, ho costruito un paio di strumenti interni dedicati proprio a questo, pensati nello specifico per i modelli visivi: un "Direttore Artistico" digitale e un "Regista" digitale, che trasformano un'idea descritta in poche parole in un prompt professionale, strutturato e pronto da usare su qualsiasi modello. Non generano nulla in automatico: fanno le domande giuste per far emergere le informazioni che, nella richiesta iniziale, avevamo omesso.

C'è infine una considerazione che vale soprattutto per chi lavora con strumenti come Claude Code o Codex: oggi il prompt non è più l'unica leva su cui possiamo intervenire. Un buon lavoro di contesto, un buon file di istruzioni persistenti, una buona gestione della memoria: il prompt diventa parte di una galassia più ampia, di un ecosistema in cui abbiamo diversi elementi su cui agire. Ma anche su questi sistemi vale sempre lo stesso consiglio: investire il doppio del tempo nella costruzione delle istruzioni rispetto a quanto si farebbe istintivamente, perché, a patto di avere le competenze per indirizzare precisamente ciò che si vuole ottenere, ogni minuto investito lì si traduce in molte meno interazioni correttive dopo.

Le competenze restano il vero moltiplicatore

Il tema delle competenze si lega direttamente a un altro fronte su cui vale la pena spendere due parole. C'è un filo che unisce ospiti molto diversi tra loro, che lavorano in settori completamente differenti: chi programma dice di riuscire a produrre sviluppi di un certo livello perché sa di cosa parla; chi scrive testi dice la stessa cosa sulla scrittura; un fotografo, sulla fotografia. È un punto che va parzialmente in controtendenza rispetto a una narrazione, un po' magica, secondo cui con questi strumenti basta "scrivere due parole" e il sistema fa tutto da solo. Le competenze, in realtà, continuano a fare una differenza enorme.

Prendiamo i modelli visivi, perché sono il caso più immediato da capire. Oggi qualsiasi modello, che sia Nano Banana Pro di Google, GPT Image di OpenAI o un altro, è in grado di generare un'immagine bella. Se chiedo l'immagine di un cane che corre sulla spiaggia, non otterrò mai un'immagine brutta: sarà sempre esteticamente valida. Il problema è che "bella" è lontanissimo da "esattamente quello che avevo in mente". Ed è lì che entra in scena la competenza: un fotografo che conosce il linguaggio tecnico del proprio mestiere, come il tipo di obiettivo, di luce, di inquadratura o la grana della pellicola, saprà descrivere con precisione quello che vuole ottenere. Io, che non ho quella terminologia né quell'esperienza, al massimo scriverò "cane sulla spiaggia al tramonto": il risultato si fermerà esattamente lì.

Sull'estremo opposto, molto meno immediato da vedere ma altrettanto vero, c'è il coding. Si può aprire un sistema agentico per la scrittura di codice e scrivere semplicemente "crea un'app che fa ...": il sistema, probabilmente, la creerà. Ma quanto controllo si ha davvero su quello che è successo "dentro"? Se invece si è competenti, si possono indicare esattamente le operazioni da compiere, perché sono quelle che si farebbero in prima persona; si possono indicare le librerie da usare, perché si conoscono le convenzioni delle proprie repository. In quel caso si investe un po' più di tempo a scrivere istruzioni dettagliate, ma il risultato è un'applicazione che si conosce davvero, dove sarà facile fare gli step successivi. Il prompt "basic", al contrario, genera una black box: non si sa cosa c'è dentro, e non si sa come intervenire in seguito. Non c'è nulla di male nel vibe coding per esplorare velocemente un'idea, ma va detto con chiarezza a chi pensa di essere diventato programmatore solo perché ha scritto due prompt: fare davvero il programmatore è un altro mestiere.

Modelli visivi: controllo, replicabilità e i nuovi confini del possibile

Per molto tempo si è parlato della difficoltà di ottenere, dai modelli visivi, output controllabili e replicabili. Con il testo ci siamo arrivati da tempo: oggi possiamo lavorare su un testo generato con la stessa precisione con cui lavoreremmo su un testo scritto da noi. Su immagini e video, invece, il tema è sempre stato più delicato.

Con gli ultimi rilasci di modelli, sia per le immagini che per i video, ci stiamo avvicinando molto a un livello di output realmente usabile, controllabile e replicabile. Per controllo intendo la capacità di riprodurre esattamente ciò che si ha in mente; per replicabilità, la possibilità di ottenere, con lo stesso prompt e qualche variazione, un'immagine coerente ma con un soggetto o un contesto diverso. Ho condotto diversi test di coerenza su questo fronte, con risultati che definirei buoni, anche se l'operazione che rende tutto questo davvero fattibile non è ancora del tutto semplice.

Il punto di partenza, ancora una volta, è lo stesso di sempre: i deficit sono quasi sempre nelle informazioni che diamo in input al modello. Un prompt ben strutturato, con la terminologia corretta, è già oggi in grado di riprodurre fedelmente ciò che si ha in testa: lo stesso vale per la replicabilità, dove un prompt iper-dettagliato, se ri-eseguito, produce un'immagine molto simile. Nei miei test, questa coerenza si è mantenuta anche passando da un modello all'altro: un prompt iper-strutturato produce risultati coerenti anche su modelli generativi diversi.

C'è però un principio che ripeto spesso, ed è probabilmente il punto più controintuitivo di tutta la faccenda: bisogna lavorare per ottimizzare il prompt, non le singole interazioni con il modello di generazione visuale. Se genero un'immagine e qualcosa non è preciso, l'istinto è correggere direttamente nella conversazione: "aggiungi questo", "togli quest'altro". Ma quelle iterazioni, una volta ottenuto il risultato voluto, sono inutilizzabili: non si può riprodurre la stessa conversazione una seconda volta. Il prompt, invece, resta un asset: se il deficit viene risolto lì, il problema è risolto per sempre, ed è riutilizzabile su richiesta.

Un fronte molto interessante, in questo momento, è quello dei prompt multimodali: si passa al modello direttamente lo storyboard di tutto ciò che deve accadere in un video, con istruzioni testuali annesse. Ho fatto diversi test con Seedance di ByteDance, e i risultati in termini di aderenza allo storyboard e di coerenza tra le diverse scene sono davvero notevoli: al punto che, con le versioni più recenti, ByteDance ha reso lo storyboard testuale un riferimento diretto per la generazione stessa.

Mi viene in mente un parallelo con la storia recente della generazione video: per tanto tempo si è parlato del "problema delle mani con sei dita" come prova che un video fosse generato dall'AI. Quel problema, ormai, è superato. Poi si è passato a parlare di coerenza dei personaggi e delle scene, e anche qui, senza volerla dare per definitivamente risolta, ci stiamo arrivando molto vicino. L'ultima frontiera aperta, dal mio punto di vista, è il rispetto delle leggi fisiche: qui ci sarà ancora un margine di evoluzione importante, magari anche grazie a componenti simboliche che affianchino il controllo puramente neurale della generazione.

Su questo fronte c'è un paper di Netflix che vale davvero la pena leggere: si chiama VOID (Video Object and Interaction Deletion), e propone un modello che non si limita a rimuovere un oggetto da un video, cosa che i modelli di editing sanno già fare abbastanza bene, ma ricalcola l'intera scena come se quell'oggetto non fosse mai esistito, tenendo conto delle interazioni fisiche che avrebbe generato. L'esempio più citato è quello di una persona che tiene in mano una chitarra: i modelli di editing "classici" rimuovono la persona ma lasciano la chitarra a fluttuare a mezz'aria, mentre VOID capisce che, senza la persona, la chitarra dovrebbe cadere per gravità. È un segnale chiaro della direzione verso cui si sta andando: non più semplice "riempimento" di pixel, ma simulazione causale di una scena.

Considerando quanto velocemente si stia evolvendo, mese dopo mese, anche il tema della coerenza generale, resta un principio che vale sempre: si lavora sul prompt, non sulla conversazione.

Se lo strumento è di tutti, il vantaggio competitivo è l'idea

Il ragionamento sui modelli visivi apre a una domanda più ampia, che vale la pena porsi ad alta voce: se oggi, pagando lo stesso abbonamento, io, tu e chiunque altro abbiamo accesso esattamente allo stesso strumento e alla stessa tecnologia, dove si sposta il vantaggio competitivo?

Non è la prima volta che succede: è sempre accaduto, anche con le tecnologie precedenti. Oggi, però, l'accelerazione e la potenza degli strumenti sono molto più alte, e proprio per questo il fattore che fa davvero la differenza è tutto quello che sta dietro e prima dell'utilizzo del modello. L'idea, in particolare, è probabilmente l'asset più prezioso quando si parla di creazione visiva: gli strumenti sono a disposizione di tutti, ma è l'idea che genera una differenza reale, ad esempio nelle campagne pubblicitarie. E se a quell'idea si aggiunge un team con le competenze giuste (torniamo sempre lì) e una tecnologia dirompente come quella di oggi, si ottiene quella che mi piace chiamare la tempesta perfetta.

Un esempio che ho trovato particolarmente convincente è lo spot "Satellite of Love" di Mercedes-Benz per il lancio della nuova CLA completamente elettrica: un cortometraggio dichiaratamente generato con l'AI, con al centro una storia d'amore tra l'auto e un satellite in orbita.

Quando l'ho condiviso, tra i commenti non è mancato chi ha fatto notare che "questo effetto si poteva ottenere anche prima, con gli strumenti tradizionali". È un'osservazione parzialmente vera, ma che manca il punto: il tema non è se un determinato output fosse teoricamente raggiungibile anche in passato. Il tema è che oggi, per arrivare a quell'output, si possono fare decine di test quasi a costo zero, mentre con la tecnologia precedente lo stesso numero di iterazioni sarebbe stato economicamente improponibile. Mercedes, del resto, ha raccontato apertamente parte della propria metodologia: una pipeline ibrida che combina generazione AI e CGI, con modelli addestrati apposta per mantenere coerente l'aspetto dell'auto in ogni scena. Non è stato "un prompt e un click su esporta", ma un processo creativo con un grado di cura piuttosto alto: solo distribuito su un numero di iterazioni che prima sarebbe stato impensabile.

È esattamente questo il punto che spesso si sottovaluta: non conta solo cosa si riesce a fare oggi che non si poteva fare prima, ma quanti test si possono permettersi per arrivare al risultato finale. Vale per le immagini, per i testi, per il codice: per qualsiasi output creativo. Prima di arrivare al risultato che si sceglie come artefatto definitivo, si può sperimentare molto di più, e quella sperimentazione, prima, era spesso difficile, costosissima o semplicemente troppo lenta. Penso a quante idee sono rimaste nel cassetto di qualcuno perché il pilota necessario per convincere chi doveva decidere non è mai stato realizzato.

Un esempio molto più quotidiano, raccontato da un designer di interni con cui ho parlato proprio in questi giorni: per le bozze veloci da mostrare ai clienti, dove basta far vedere dove va posizionato un divano o una TV, prima riusciva a portarne tre; oggi ne porta dieci, usando l'AI per la visualizzazione rapida di un'idea. Sul progetto finale continuerà a lavorare con la cura di sempre, ma nel frattempo arriva dal cliente con dieci strade diverse da mostrare, invece di tre.

Come abbiamo ridotto del 90% i costi di un sistema agentico (con lo stesso modello)

Questo è probabilmente il tema più operativo di tutta la chiacchierata, quindi vale la pena entrare nel dettaglio tecnico. Di recente, con il mio team, abbiamo condotto alcune sperimentazioni che ci hanno permesso di ottenere risparmi di consumo di token, quindi di costo, davvero significativi su alcuni agenti, arrivando fino al 90%. Il punto centrale è che questo risparmio non arriva cambiando modello (quello sarebbe stato facile, e anche piuttosto scontato), ma ottimizzando il layer applicativo che sta dietro all'agente, usando esattamente lo stesso modello di partenza. Ecco i punti cardine.

1. Separare l'estrazione dei dati dal ciclo di ragionamento dell'agente. Quando costruiamo un agente, dovremmo sempre chiederci: tutto quello che portiamo dentro al ciclo agentico, tipicamente via MCP, serve davvero al modello per prendere decisioni, o stiamo semplicemente estraendo dati da elaborare in un secondo momento? Se la risposta è la seconda, quella parte può uscire dal ciclo agentico e diventare un flusso lineare e programmatico: si estraggono i dati via API, si puliscono, e si passano già elaborati all'agente. In un progetto reale, ad esempio, un MCP usato per estrarre dati sui post social riportava indietro una quantità di dati impressionante: dati che non servivano affatto per prendere decisioni, ma solo per l'elaborazione finale. Abbiamo quindi portato quell'estrazione fuori dal loop, costruito un sistema che pulisce e ordina i dati via API, e usato un modello molto più piccolo (quindi a costo quasi nullo) per estrarne gli insight. Solo quegli insight, non i dati grezzi, diventano l'input per il modello principale.

2. Sfoltire i tool MCP che non si usano davvero. Connettere un server MCP oggi è semplicissimo: basta un URL e un token di autenticazione. Il problema è che molti MCP portano con sé anche cento tool, e dopo un po' di test si scopre spesso che se ne usano realmente dieci. Tutti i tool inutilizzati, però, restano comunque nel contesto: la "firma" di ogni funzione è testo che serve all'agente per sapere che quella funzione esiste, e quindi occupa spazio anche se non viene mai chiamata. Rimuovere ciò che non serve è uno dei modi più semplici per alleggerire il contesto.

3. Insegnare all'agente a chiedere meno dati. Torniamo, ancora una volta, sul prompt engineering: attraverso il system prompt possiamo insegnare all'agente a fare chiamate ai tool esterni in modo più intelligente. Un esempio semplice: una funzione che di default estrae 100 righe di dati, quando in realtà per l'elaborazione ne bastano 10. Istruendo il modello a richiedere esplicitamente quella quantità, il payload che viaggia tra tool e agente si riduce drasticamente.

4. Trasformare le chiamate MCP in function calling su misura, che comprime l'output prima che arrivi all'agente. Questo è il punto che, personalmente, mi ha aperto di più la mente. Molte funzioni che colleghiamo agli agenti via MCP non sono ottimizzate per essere consumate da un agente: restituiscono la stessa, enorme quantità di dati che si otterrebbe chiamando l'API esternamente. La soluzione è costruire funzioni esterne che usano le stesse identiche API dell'MCP, ma intercettano l'output prima che arrivi all'agente, per pulirlo e comprimerlo. Il risultato, in termini di token risparmiati, è impressionante.

Se dovessi sintetizzare tutto in un unico principio, sarebbe questo: ci sono cose che vanno fatte prima di far arrivare l'informazione all'agente, perché l'agente non deve fare tutto internamente; ci sono cose che non vanno fatte tramite MCP, per evitare la classica sindrome del martello che vede ogni problema come un chiodo; e, sopra a tutto il resto, serve conoscere a fondo il processo che si sta automatizzando.

Per costruire un'auto di Formula 1 bisogna conoscere il processo nel dettaglio, altrimenti non si possono fare le micro-regolazioni necessarie a portarla in pista, e con gli agenti, dal punto di vista dell'ingegneria, non è affatto diverso.

La "frontiera irregolare" dell'AI (e perché non serve l'AI dappertutto)

Nel report AI Index 2026 di Stanford HAI c'è un passaggio che descrive bene un fenomeno che chi usa questi sistemi ogni giorno conosce fin troppo bene: i modelli raggiungono risultati straordinari su compiti avanzati, e poi falliscono su attività che per un essere umano sembrano elementari. Il report la chiama "jagged frontier", la frontiera irregolare, e uno degli esempi più citati è quasi comico, se non fosse anche un po' preoccupante: modelli capaci di ottenere una medaglia d'oro alle Olimpiadi Internazionali di Matematica leggono correttamente un orologio analogico solo in circa la metà dei casi, contro oltre il 90% di accuratezza umana.

Non è un dato che stupisce chi lavora quotidianamente su progetti agentici: abbiamo tutti in mente l'idea di un'AI generale, capace di eseguire qualsiasi compito, ma la realtà è ben diversa. Basta guardare le applicazioni che stanno realmente portando risultati concreti alle aziende, penso ad esempio ad AlphaFold o AlphaEvolve di Google DeepMind, per notare che sono tutte fortemente iper-specializzate, non generali. Forse, con il tempo, ci avvicineremo a un concetto più ampio di intelligenza generale; oggi, però, la realtà a cui dobbiamo progettare intorno è un'altra.

Cosa significa questo, in concreto, quando si sviluppano sistemi agentici? Che dobbiamo conoscere i limiti dei modelli, capire su quali task possono agire al meglio e, sui task dove non riescono, capire se possono farlo purché dotati degli strumenti giusti. Un esempio molto semplice: un large language model non è bravo a fare calcoli precisi. Bene: gli si dà a disposizione un ambiente in cui la parte di calcolo viene sviluppata (e poi eseguita) in Python. In questo modo non si è "sfruttato" il modello per fare qualcosa che non sa fare bene, ma gli si è affiancato uno strumento esterno che compensa esattamente quella mancanza.

C'è poi il tema dell'osservabilità, che considero uno dei pilastri più sottovalutati di tutta l'ingegneria agentica. Quando sviluppiamo sistemi basati su agenti, dobbiamo sapere esattamente cosa fa l'agente, quali tool sta usando, che tipo di ragionamento sta seguendo, quali sono gli step, e nei sistemi multi-agente quali sono gli scambi tra i diversi agenti. Non significa necessariamente assumere una persona che controlli manualmente ogni report: noi, ad esempio, usiamo dei grader, sistemi basati su modelli molto piccoli, addestrati per valutare gli output in diverse fasi del workflow, che intercettano le anomalie e le segnalano, in modo da poter ottimizzare progressivamente il sistema ed evitare che quel tipo di errore si ripeta.

E qui arriva un'ultima considerazione, forse la più semplice di tutte ma anche la più disattesa: non tutto va risolto con l'AI. Non serve dappertutto. Quando qualcuno mi chiede un'intelligenza artificiale per fare i volantini del suo ristorante, la risposta più onesta è: usa Canva. Esistono strumenti che fanno bene certe cose, le hanno sempre fatte bene, e non hanno bisogno di un modello generativo nel mezzo. È lo stesso rischio che si corre con piattaforme come n8n o Make da quando hanno introdotto i nodi AI: si finisce per "fare con l'AI" qualcosa che sarebbe stato più solido, più prevedibile e più economico risolvere con quattro righe di Python.

Il valore umano, in un mondo che accelera

Raffaele mi ha posto, come sempre in chiusura di queste chiacchierate, la domanda più difficile: in uno scenario in cui l'AI ha capacità sempre più incredibili e viaggia a una velocità impressionante, sembra ogni giorno in grado di fare cose che ieri non sapeva fare, qual è il mio ruolo? Qual è il mio valore?

Una cosa è certa: non lo vedo nei task puramente operativi. Ci sarà sempre qualcuno più bravo di me a svolgerli domani, e c'è già oggi un'AI capace di farli meglio in una frazione del tempo. Il valore, per me, si sposta altrove: in due direzioni precise.

La prima è la ricerca e sviluppo: sento una curiosità e una spinta verso l'innovazione che definirei bruciante, ed è quella spinta che trasformo, quando riesco, in qualcosa di concreto. Alcune delle applicazioni che stiamo portando in produzione oggi nascono da test e sperimentazioni fatte, non solo da me ma dal team, in periodi in cui nessuno pensava minimamente che sarebbero diventate un software vero. Credo in un principio molto semplice: chi aspetta il caso reale per iniziare a sperimentare è già in ritardo rispetto a chi ha sperimentato prima.

La seconda direzione è la condivisione: raccontare, divulgare, spiegare questi concetti a chi non li vive quotidianamente. La sento davvero come una missione, non solo come una passione legata alla sperimentazione: un piccolo contributo, nel mio ambito, per rendere la società un po' più consapevole di un mondo che sta cambiando concretamente sotto i nostri occhi.

E se devo trovare un filo che lega tutto quello di cui abbiamo parlato in questa chiacchierata, dagli agenti in produzione al prompt engineering, dal vantaggio competitivo dell'idea alla frontiera irregolare dei modelli, è probabilmente questo: la curiosità, oggi più che mai, è la caratteristica che fa davvero la differenza. Non basta da sola: unita a competenze solide, diventa la combinazione più efficace per orientarsi in un mondo che, semplicemente, va troppo veloce per stare fermi a guardare.

La vera combo vincente, oggi, non è l'accesso alla tecnologia più recente. È la curiosità di chi la usa, unita alle competenze per usarla davvero bene.