Otto mesi fa, una notte di settembre 2025, un agente che avevamo messo in produzione su un prototipo interno ha fatto una cosa molto interessante. Ha mandato un'email di conferma a un cliente test, ha letto la risposta, ha interpretato "Va bene, conferma!" come "esegui tutto", e ha cancellato un'intera tabella di configurazione.
Non era un cliente vero. Non era una tabella di produzione. Ma era abbastanza vicino al vero da convincerci, la mattina dopo, a sederci attorno a un tavolo e fare una lista molto onesta di tutto quello che avevamo sbagliato.
Quella lista è cresciuta nei sette mesi successivi. Nel frattempo abbiamo messo in produzione Tuken — la piattaforma di gestione eventi e parcheggi — e abbiamo iniziato a costruire BP (l'assistente per business plan, in arrivo nei prossimi mesi). Ognuno di questi prodotti ha aggiunto un capitolo a quella lista.
Oggi ve la passiamo. Sono quattro errori. Non sono i più sexy. Sono i più frequenti, i meno raccontati, e quelli che fanno davvero la differenza tra un agente che gira bene e un agente che produce disastri silenziosi.
Errore #1 — Dargli troppi poteri perché "tanto poi gestiamo"
Il primo agente che metti in produzione, qualunque framework usi, ti viene da configurarlo con permessi larghi. Lettura ovunque, scrittura quasi ovunque, accesso a tre o quattro API esterne, possibilità di mandare email, capacità di chiamare strumenti di pagamento in "modalità test che però è la stessa di produzione".
La logica suona ragionevole: "Vediamo cosa è capace di fare, poi restringiamo."
Non vedi mai. Non restringi mai.
Quello che succede davvero è che dopo due settimane sei abituato a vederlo funzionare con quei poteri, hai costruito flussi che li danno per scontati, e a quel punto restringerli significa romperli. Quindi non li restringi. E un mese dopo l'agente ha accesso a metà del sistema, nessuno ricorda esattamente quale metà, e l'unica persona che lo sapeva si è dimessa.
Il principio che applichiamo adesso, su tutti gli agenti, su Tuken come su BP:
L'agente parte con il minimo indispensabile per non fare il suo lavoro. Sì, hai letto bene: deve fallire la prima volta che lo provi. Poi gli concedi un permesso, lo provi, e solo se serve davvero glielo lasci. Ogni nuovo permesso ha una data di scadenza scritta in chiaro: se a quella data nessuno ricorda perché ce l'ha, glielo togli.
È fastidioso. Ti costa una giornata di lavoro in più per ogni agente. Ti salva da un numero di disastri che è difficile quantificare perché — bellezza degli incidenti evitati — non avvengono.
Errore #2 — Nessuno sa cosa è cambiato nel prompt dell'altroieri
I prompt non sono codice. Lo sai. Lo so. Ce lo siamo detti.
Ma poi cosa succede. Un collega cambia una riga nel system prompt di un agente perché "rispondeva male alla domanda di un cliente specifico". Funziona meglio per quel cliente. Funziona peggio per gli altri cinque. Nessuno se ne accorge per tre giorni. Quando ce ne accorgiamo, nessuno ricorda esattamente cosa è cambiato, quando, e perché.
Il bug più sottile di tutti i tempi è il bug che non sai esistere, ed è esattamente quello che producono i prompt non versionati. Nel frattempo: il modello dietro le quinte è cambiato (il fornitore aggiorna senza dirtelo), il contesto è cambiato (nuovi documenti indicizzati, vecchi rimossi), un parametro di temperatura è stato toccato. Cinque cose si muovono insieme. Le metriche peggiorano in maniera oscura.
Quello che facciamo adesso:
Ogni prompt è in repository git, ha un changelog, una versione, un commit message che spiega perché è stato cambiato. Le modifiche passano da pull request come qualunque altro codice — anche quando "è solo una virgola". Quando rilasciamo una nuova versione, gira automaticamente una batteria di test (un set di domande/risposte attese) che ci dice subito se qualcosa è regredito.
È una pratica che la comunità chiama prompt-ops o, più seriamente, LLM-ops. È la cosa che ci ha cambiato la vita su BP, dove un singolo prompt sbagliato può produrre un piano finanziario che assomiglia a uno vero ma con numeri inventati. Lì non puoi permettertelo.
Errore #3 — Pagare per l'inferenza, non misurare i retry
Questo è il più subdolo, perché si maschera bene.
Quando metti in produzione un agente, la prima metrica che guardi è il costo per chiamata API. Ti viene proposto in dashboard, è facile da grafare, è quello di cui parlano tutti. Quindi lo monitori. Quanto ci costa al mese OpenAI, quanto Anthropic, quanto Mistral.
Quel numero, da solo, mente.
La verità economica di un agente in produzione è: quante volte un utente reale deve riprovare un'azione prima di ottenere quello che voleva? Chiamatelo cost-of-retry, chiamatelo abandonment rate, chiamatelo come volete. Quel numero contiene quasi tutto.
Esempio reale, su un'iterazione di Tuken. Un agente assistente aiutava il gestore di un evento a configurare i pacchetti tariffari. Costo di inferenza: bassissimo, una frazione di centesimo per richiesta. Costo reale: il gestore doveva chiedere in media 4 volte la stessa cosa prima di ottenere la configurazione giusta. Il costo vero era il tempo del gestore (tantissimo) e la sua fiducia nello strumento (che crollava). L'inferenza era irrilevante.
Il rimedio non era cambiare modello né scrivere prompt più lunghi. Era misurare il retry. Una volta misurato, le decisioni di prodotto si sono allineate da sole: meno spazio al free-text, più scelte guidate dove servivano, fallback "fammi parlare con un umano" dove l'agente non era affidabile.
Il KPI: ogni interazione critica deve poter rispondere a "questo utente è arrivato dove voleva?". Se non lo sai, stai pagando un costo che non vedi.
Errore #4 — Misurare l'agente, non il prodotto
Veniamo al peggiore di tutti, perché è il più seducente.
Quando lavori su un agente IA, vuoi misurarlo. È giusto. Costruisci dashboard che ti dicono: latenza media, token consumati, accuratezza dei tool call, success rate del modello su una batteria di test, percentuale di risposte fluide. Sono numeri buoni. Ti danno la sensazione di avere il controllo.
E sono quasi sempre la misura sbagliata.
L'agente non è il prodotto. È dentro il prodotto. Quello che conta non è "il modello ha risposto bene". Quello che conta è "l'utente ha completato il flusso che era venuto a fare". Sono due cose diverse, e la seconda è molto più difficile da misurare, per cui spesso non la misuriamo. Misuriamo la prima, ci compiacciamo, e poi un giorno notiamo che gli utenti non rinnovano e non sappiamo perché.
Su Tuken siamo cascati esattamente in questa trappola per le prime sei settimane. Avevamo dashboard meravigliose sull'agente: accuratezza, latency, distribuzione delle intent riconosciute. Tutto verde. Nel frattempo la metrica "il gestore ha pubblicato l'evento dopo la conversazione con l'agente?" — quella che davvero ci diceva se lo strumento serviva — la guardavamo una volta a settimana.
Adesso la guardiamo prima di tutte le altre. Le metriche dell'agente sono secondarie alle metriche di prodotto. Se l'agente è un modello da Nobel ma gli utenti non finiscono il flusso, l'agente è da rifare. Se l'agente è mediocre ma gli utenti chiudono il flusso, l'agente va benissimo.
Tradotto in regola operativa: definisci la metrica di prodotto prima di iniziare a costruire l'agente. Non dopo. Non in parallelo. Prima. Se non riesci a definire una metrica di prodotto chiara, probabilmente non ti serve un agente IA — ti serve una conversazione più dura con il tuo team su cosa stai costruendo davvero.
La checklist, distillata
Per chi va di fretta. Quattro domande da farsi prima di mettere un agente in produzione.
- Permessi. L'agente parte dal minimo? Ogni permesso ha una scadenza?
- Versioning. Ogni prompt è in git? Ogni modifica passa da una PR? Esiste una batteria di test che gira a ogni rilascio?
- Cost-of-retry. Sappiamo quante volte un utente reale deve riprovare? Lo misuriamo? Lo grafichiamo?
- KPI di prodotto. La metrica che conta è quella dell'utente che completa il flusso, non quella dell'agente che risponde bene. L'abbiamo definita prima di iniziare?
Se la risposta a una sola di queste quattro domande è "non ancora", stai facendo l'errore più caro del 2026: tenere in produzione un sistema che sembra funzionare ma che ti sta costando in modi che non vedi.
Una piccola anticipazione
L'errore numero due — il prompt versionato — è solo metà della storia. L'altra metà è che il prompt, anche perfetto, vale poco se il contesto che gli passi è sbagliato. Cosa metti nel contesto, da dove viene, con che freschezza, con che permessi: è quella che chiamiamo context engineering, ed è la disciplina vera del 2026.
Ne parleremo l'11 giugno in un pezzo dedicato. Per ora, fermiamoci qui.
Lunedì 1° giugno torniamo invece sul versante startup, con un pezzo che ci frulla in testa da tempo: Founder mode è morto. Lunga vita al founder mode. Due anni dopo il saggio famoso di Paul Graham, cosa ne resta nelle startup italiane che sono sopravvissute al 2025.
A lunedì.
Avete un agente IA che funziona ma di cui non vi fidate ancora del tutto? Il nostro servizio di intelligenza artificiale per il business include audit operativi su agenti già in produzione. Mezza giornata, output operativo, niente diapositive da PowerPoint. Parliamone.