Agenti AI in produzione: il modello non è più il collo di bottiglia.

Partiamo da un dato scomodo. Il MIT, nel report State of AI in Business 2025, scrive che a fronte di 30-40 miliardi di dollari investiti in GenAI il 95% delle organizzazioni non vede alcun ritorno[1]. La frase che conta è un’altra: questo divario non dipende dalla qualità del modello, ma dall’approccio. McKinsey arriva allo stesso punto da un’altra strada, la riprogettazione dei workflow è la leva con l’effetto maggiore sull’impatto economico dell’AI[5]. E lo studio MAST, analizzando oltre 1.600 tracce di sistemi multi-agente, conclude che i fallimenti sono di design, non di capacità del modello[2].

Tradotto: il modello è ormai una commodity straordinariamente potente. Il collo di bottiglia si è spostato su due cose profondamente umane. La comunicazione con chi conosce il dominio, e la capacità di ridisegnare un processo nato per gli esseri umani in uno pensato per lavorare con gli agenti.

Per questo stare sempre aggiornati sullo stato dell’arte è diventato un prerequisito, non un vantaggio. Conoscere MCP, le skill, i flussi agentici a orizzonte lungo serve a una cosa sola: smettere di pensare alla tecnologia. Quando l’implementazione non è più il problema, tutta l’attenzione va su come dovrebbe essere fatto il lavoro.

È un paradosso solo in apparenza. Più sei tecnico, meno la tecnologia è il tuo lavoro.

L’esperto di dominio è la persona più preziosa nella stanza e, quasi sempre, quella che fatica di più a cambiare modello mentale. Non perché sia chiuso: i suoi standard sono sedimentati in anni di lavoro, e quegli standard sono la sua garanzia di qualità. Ora deve trasferire gli stessi anni di competenza in pochi giorni, con la stessa qualità di sempre, attraverso un modo di lavorare diverso.

Da qui il primo errore prevedibile: l’esperto chiede le funzionalità che pensa di volere, di solito automatizzare ciò che già vede. Il vero tesoro è quello che non racconta, perché è così abituato al vecchio sistema da non immaginare che si possa toccare. Le parti più bisognose di AI sono spesso quelle che l’esperto non si rende nemmeno conto di fare in modo sub-ottimale.

La domanda che faccio sempre, al primo tavolo, è questa: qual è la cosa che ti cambierebbe la vita e che non abbiamo nemmeno nominato, perché la diamo per impossibile? È così che si scopre ciò che la persona ritiene irrealizzabile e di cui ha disperatamente bisogno.

Poi la comunicazione va nutrita di feedback onesti da entrambe le parti. La fiducia è la condizione tecnica, non un di più. Le paure comuni sono due, «perderò il lavoro» e «lavorerò di più con scadenze più strette», ed entrambe nascono da un’AI usata male: apre un buco di token nel budget, allontana le persone e manca il punto.

Quando la comunicazione regge, il lavoro tecnico comincia dai dati. a16z lo ha messo nero su bianco: gli agenti enterprise spesso non funzionano per mancanza di contesto, perché «revenue è una definizione di business, non è hard-coded in un data warehouse». I dati aziendali vivono sparsi, e un LLM calato su dati frammentati allucina. In un nostro progetto su dati patrimoniali, un modello arrivò a dire che una holding possedeva il 257% di sé stessa. Non era colpa del modello, ma di come i dati gli arrivavano.[3]

Collegare le fonti livella il campo, e non è banale. Bisogna capire quali dati collegare, come modellarli perché l’LLM continui a performare, dove tenere la fonte unica di verità (SSoT) e come trasformarli per costruire, col tempo, dataset proprietari. Qui c’è un vantaggio competitivo che si accumula: ogni dato che porti dentro e modelli bene è un mattone che resta tuo.

C’è un errore ricorrente, soprattutto nelle agenzie: gli esperti usano già piattaforme potenti nel modo «umano» di sempre e quasi mai si accorgono che quegli stessi fornitori hanno già rilasciato funzioni AI o MCP che cambierebbero le carte in tavola. Mi è capitato spesso di scoprire che la feature di cui avevamo bisogno era già dentro uno strumento che l’azienda pagava da anni. Connettere i sistemi nel modo giusto vale più che costruirne uno nuovo nel modo sbagliato.

Vale anche per gli strumenti dell’agente. Un tool va progettato per l’agente, non come wrapper sottile di un’API, e l’interfaccia agente-computer merita la stessa cura di quelle per gli umani. Presentando i server MCP come codice da richiamare invece che come chiamate, Anthropic ha documentato un workflow passato da 150.000 a 2.000 token. È un numero del fornitore, lo dico per onestà, ma la direzione è quella giusta.[4]

A questo punto si progetta il flusso. Il modo che preferisco lo chiamo «ignorante», con affetto: ignora il sistema tradizionale esistente e prova a ricostruirlo da zero, forzando un vincolo, «questo deve poterlo fare una sola persona, con questi strumenti AI». Un pensiero AI-native sviluppa in modo naturale un workflow centrato sull’AI che sostituisce quello centrato sull’uomo. Con l’aiuto dell’esperto, il risultato è migliore, più veloce e davvero più economico.

In Intarget questo passaggio ha un nome che abbiamo scelto di pronunciare ad alta voce, in una lezione alla Bocconi: Fullstack AI Company. Un’azienda ricostruita attorno all’AI, non un’azienda che usa l’AI.

Lo stesso vale per come si costruisce. Personalmente non scrivo più codice riga per riga: scrivo architettura, vincoli, criteri di accettazione. L’AI scrive il codice, io rivedo, itero, rilascio. Quello che prima richiedeva mesi passa a settimane, e poi a giorni.

Un caso reale, istruttivo perché è fallito tre volte prima di riuscire. In Intarget la conoscenza strategica sui clienti più importanti viveva nelle teste delle persone: ogni incontro con un C-level richiedeva ore per ricostruire il contesto, e quando qualcuno se ne andava la memoria se ne andava con lui. Tre tentativi su PowerPoint compilati a mano erano morti per lo stesso motivo: nessun rituale di aggiornamento, nessun proprietario, un formato non mantenibile. La versione AI-native ha ribaltato il vincolo: il Business Partner non compila un dossier, risponde a delle domande, e il sistema mantiene viva da solo una base di conoscenza strutturata (un company brain alimentato dal CRM e dalle fonti pubbliche). Il deliverable non è più un file. È un sistema che si nutre da sé.

Qui arrivo alla parte che separa il lavoro serio dall’AI slop. Un LLM potente, ben guidato e con i dati giusti, fa quasi tutto. Ma ciò che distingue una consegna riproducibile dal vincere alla lotteria del token è la firma di un esperto che sa più del modello e sorveglia standard, output e aggiornamento continuo. Un modello bravissimo ti dice come si fanno le cose in base ai suoi dati di training. La salsa segreta te la dà solo chi quel mestiere lo fa.

Perché funzioni, la qualità va resa prevedibile, non controllata solo all’output. Lo strumento si chiama eval: insiemi di test che misurano l’affidabilità del sistema su scenari reali.

L’esempio più chiaro di firma operativa è un nostro agente che fa da controllo qualità sulle creatività pubblicitarie prima della messa online.

C’è un dettaglio che amo particolarmente. Quando un nostro orchestratore ha prodotto una presentazione coordinando sei agenti specialisti, ogni slide riportava la firma dell’agente che l’aveva scritta. Trasparenza radicale: ogni pezzo ha un responsabile, e la qualità si può tracciare.

La teoria diventa pratica quando attacchi un compito molto specifico. Scegli un deliverable che oggi richiede più persone, settimane di lavoro manuale e di ricerca, che va validato con cura e produce un valore alto. Parti da lì con il flusso AI-native, in modo ignorante, e fallo in giorni. Sorveglia la qualità e prepara gli eval, così resta prevedibilmente alta nel tempo.

Per scegliere il deliverable giusto torna utile la matrice del primo articolo della serie: incroci quanto conta per il business con quanto è già standardizzato. In alto a destra, processi ad alto impatto e già standardizzati, c’è il «parti da qui».

Un caso, anonimizzato, dall’Innovation Hub di Intarget: un pitch strategico da settanta pagine per un grande brief del settore education, con analisi competitiva, personas, insight. Normalmente lo fa un team di sei-otto persone in diverse settimane. L’abbiamo costruito in due persone, con un orchestratore di content strategy, risparmiando il 50-60% del tempo rispetto alla baseline storica. E qui la cosa importante: la qualità è salita, non scesa. Il commento del senior è stato «insight che il team non avrebbe potuto generare da solo». L’AI non ha tolto valore al lavoro. Gli ha tolto la parte meccanica.

L’errore più grande è trattare l’AI come un modo per fare le stesse cose un po’ più in fretta e limare qualche punto di margine. Andrej Karpathy lo dice bene: l’AI sblocca ciò che non eri mai stato in grado di fare, e pensare che possa solo copiare-incollare ciò che già fai fa perdere il suo vero valore. Se punti solo all’efficienza, è più facile che l’AI ti mangi il margine invece di aumentarlo. McKinsey nota infatti che chi ottiene di più aggiunge obiettivi di crescita e innovazione, non solo di risparmio.

Se invece punti all’«impossibile prima, facile ora», i ritorni possono decollare, e il collo di bottiglia successivo diventa il go-to-market. La produzione smette di essere il limite, e lo diventano marketing e vendite.

Per questo torno alla frase del collega, quella delle scadenze «strutturalmente impossibili» diventate gestibili. Non descrive un risparmio: descrive una soglia che si sposta. L’AI non ha reso la consulenza meno umana, l’ha resa meno meccanica.

Mettere gli agenti in produzione, in modo efficace, è meno una questione di modello e più una questione di metodo. Stai sempre aggiornato sullo stato dell’arte, così da mettere al primo posto la comunicazione e la competenza di dominio. Conquista la fiducia degli esperti e scova ciò che ritengono impossibile. Collega i dati e possiedi le tue fonti di verità. Riprogetta il workflow in modo ignorante. Rendi la qualità prevedibile con eval e con la firma di chi sa. Parti da un deliverable che vale, e fallo in giorni.

Resta un capitolo che merita un articolo a parte: come si cattura davvero il valore dell’AI prima che una cattiva governance se lo mangi. Lo affronterò un’altra volta. Per ora basti il principio che usiamo come bussola: usare l’AI come un sistema, non come una sessione.