Agenti AI in produzione: cosa funziona davvero (e cosa è ancora demo)

Ciao a tutti,

Ben arrivati su WikiLuc.

questo articolo nasce da una frustrazione che si accumula di review in review: troppi progetti “agentic” che in demo sembrano magia e in produzione si trasformano in problemi di governabilità dei costi ed efficacia rispetto alle aspettative. Ho voluto mettere per iscritto quello che ho imparato — non come osservatore, ma come persona che si trova a valutare queste architetture prima di avviarne lo sviluppo.

Di cosa parliamo oggi:

• una definizione operativa di cosa è (e cosa non è) un agente AI

• i pattern che stanno effettivamente reggendo in produzione, con esempi documentati

• i punti di attenzione che nessuno ti dice in fase di pitch

• tre notizie da tenere d’occhio nel 2026

Iniziamo

Agenti AI: la realtà dopo l’hype

Cosa intendiamo per “agente”

Il termine è diventato così inflazionato da perdere significato. Vale la pena stabilire una definizione operativa, perché da essa dipende tutto il ragionamento successivo.

Un agente AI è un sistema in cui un LLM (Large Language Model) non si limita a generare testo, ma decide quali azioni intraprendere, le esegue attraverso tool call verso sistemi esterni (API, database, filesystem, browser) e itera in base ai risultati ottenuti, in un loop che può durare secondi o ore.

La differenza rispetto a un workflow LLM classico non è estetica, è strutturale. In un workflow, il percorso è determinato a priori dallo sviluppatore: se X allora chiama API Y, poi passa il risultato al modello. In un sistema agentico, è il modello a decidere quale strumento usare, in quale ordine, e se è il caso di riprovare. Questo aumenta esponenzialmente lo spazio delle azioni possibili — con tutto ciò che ne consegue in termini di robustezza, costo e imprevedibilità.

Anthropic, nel suo documento tecnico sulle best practice per gli agenti, descrive questa distinzione con una metafora utile: la differenza tra un copilota che ti suggerisce la rotta e un pilota automatico che la esegue autonomamente. Il secondo è più potente, ma richiede molta più ingegneria di sicurezza.

Se nel progetto che stai valutando non ci sono loop decisionali, non ci sono azioni conseguenti a tali decisioni, e il prompt è sempre lo stesso — stai guardando un workflow LLM con un nome più attraente. Non è un male di per sé, ma va dimensionato diversamente.

Pattern che funzionano in produzione

Il Stanford AI Index 2026 — il report annuale più autorevole sull’adozione globale dell’AI — segnala che i deployment agentic con i tassi di successo più alti condividono tre caratteristiche: dominio ristretto, validazione automatica dei risultati, human in the loop in fase di approvazione. Non è un caso. Vediamo i pattern principali.

1. Agenti di ricerca documentale interna (legal, compliance, supporto tecnico)

Questo è probabilmente il caso d’uso più maturo. L’agente riceve una query, decide quale documento consultare tra migliaia, estrae i passaggi rilevanti, li integra e produce una risposta strutturata — tutto in modo autonomo.

Un caso documentato: Morgan Stanley ha deployato un agente basato su GPT-4 per il supporto ai financial advisor, con accesso a oltre 100.000 documenti interni. Il sistema gestisce circa 200 query al giorno con un tasso di soddisfazione degli advisor superiore all’85% (fonte: OpenAI Case Studies). Il punto chiave è che l’agente non esegue operazioni finanziarie — recupera informazioni e propone risposte che un advisor umano poi valida e usa. Human in the loop preservato, spazio delle azioni limitato.

2. Coding agents su task ristretti

Il benchmark di riferimento qui è SWE-Bench, che misura la capacità dei modelli di risolvere issue reali su repository GitHub pubblici. I risultati mostrano un’evoluzione significativa: In tre anni, la capacità dei modelli AI di risolvere problemi reali di programmazione è passata dall'1,7% di GPT-4 al 70%+ dei sistemi multi-agente attuali — una crescita che non ha precedenti nella storia del software.

Cosa significano questi numeri in pratica? Che su task di refactoring di moduli, scrittura di test unitari o apertura di PR su codebase esistenti, i coding agent sono già operativi in produzione in team di engineering — non come sostituti dello sviluppatore, ma come acceleratori su task ripetitivi e ben definiti. GitHub Copilot Workspace, Cursor e Devin (Cognition AI) sono i deployment più diffusi in questo contesto.

La limitazione principale rimane la dimensione del contesto e la complessità delle dipendenze: più la codebase è grande e interconnessa, più l’errore composto cresce.

3. Operational copilot in SRE e cybersecurity

Il caso più interessante che ho visto recentemente viene da un paper di Google DeepMind sul sistema interno di triage degli alert (DeepMind Engineering Blog, 2025). L’agente riceve un alert, interroga i log, consulta i runbook esistenti e propone una diagnosi — con un livello di confidenza associato. Il team SRE interviene solo quando la confidenza è bassa o l’azione proposta è ad alto rischio. Il risultato riportato: riduzione del Mean Time to Investigate (MTTI) del 40% su un sottoinsieme di alert categorizzati.

In cybersecurity, Crowdstrike e Palo Alto Networks hanno entrambi annunciato agenti per il triage degli alert SIEM. Il pattern è identico: dominio ristretto (un tipo di alert), validazione automatica (confronto con regole note), escalation umana per i casi ambigui.

I punti di attenzione che nessuno ti dice

Agenti generalisti: il problema del tasso di successo composito

Lo Stanford AI Index 2026 riporta che, su benchmark realistici end-to-end (non task isolati), i sistemi agentic generalisti hanno ancora tassi di successo inferiori al 40%. Il problema non è che il modello sbagli un singolo passo — è che in una catena di 10 decisioni, un errore al passo 3 invalida spesso tutto ciò che viene dopo.

È quello che in letteratura si chiama error compounding: se ogni step ha una accuracy del 90%, dopo 10 step la probabilità che tutto vada bene è 0.9^10 ≈ 35%. È matematicamente inevitabile in assenza di meccanismi di recovery robusti. Più ampio lo spazio delle azioni, più rapidamente questa curva scende.

Questo non vuol dire che i sistemi agentic generalisti siano inutili — vuol dire che richiedono un investimento in meccanismi di retry intelligente, validazione intermedia e fallback che raramente viene messo a budget in fase di proposta.

Il costo nascosto della retry — un esempio reale

Questo è il punto che mi ha fatto perdere più sonno in fase di review. Considera un agente che esegue un task di elaborazione documentale. In fase di PoC, il costo stimato è 0.10€/task. Sembra ottimo. Ma in produzione succedono tre cose:

1. Il tasso di successo al primo tentativo è più basso del previsto (diciamo 60% invece di 90%)

2. Il sistema ritenta automaticamente i task falliti — con prompt più lunghi, perché include il contesto dell’errore precedente

3. I task più complessi richiedono iterazioni multiple con tool call

Il risultato: un team di ingegneri con cui ho lavorato ha visto il costo/task passare da 0.10€ a 1.50€ in produzione, su un volume di 50.000 task/mese. L’economics del progetto reggeva a 0.10€. Non reggeva a 1.50€.

La ricerca di Andreessen Horowitz sui margini delle AI startup (2023, ancora attuale nella logica) mette in guardia esattamente su questo: il costo di inference non è quello del task “felice”, ma quello del task medio ponderato per tutte le iterazioni.

Come fare una stima consistente? Prima di fare budget, misura:

• Tasso di successo al primo tentativo su un campione reale (non sul dataset di test costruito per la demo)

• Lunghezza media del contesto nei retry

• Numero medio di tool call per task completato con successo

Come leggere un progetto agentic: tre domande che fanno la differenza

McKinsey, nel report The State of AI 2024, identifica la mancanza di metriche di successo chiare come il principale predittore di fallimento nei progetti AI in produzione. Non sorprende. Ecco le tre domande che uso in ogni review:

Qual è lo scope esatto delle azioni? Un agente che può fare “tutto su un documento” è diverso da un agente che può “estrarre entità e classificare il documento tra 12 categorie predefinite”. La seconda definizione è un progetto. La prima è una speranza.

Come misuriamo il successo? L’accuracy deve essere misurabile automaticamente, senza revisione umana di ogni output. Se la risposta è “lo valuta un esperto a campione”, il progetto non è scalabile — è un processo umano con un assistente AI a monte.

Quanto costa un task fallito? Non in termini economici soltanto. Un task fallito in un agente di supporto clienti è un cliente frustrato. In un agente di compliance, è un rischio legale. Il costo del fallimento deve essere esplicito nel design dell’architettura.

Risposte chiare a queste tre domande = progetto serio. Risposte nebulose = demo destinata a non scalare.

Notizie da tenere d’occhio

OpenAI rilascia “Agent Mode” nei piani Enterprise Non più solo nei consumer plan. OpenAI ha esteso le capacità agentiche (browsing, code execution, memory persistente) ai clienti enterprise. La pricing per uso intensivo è ancora da definire chiaramente. Perché importa: segnala che il mercato si sposta definitivamente dal modello chat al modello agentic anche nelle vendite enterprise. Le aziende che non hanno ancora una policy sull’uso degli agenti AI devono iniziare a scriverla adesso.

AI Act: prima multa significativa a una scaleup europea Il caso è ancora in corso, ma coinvolge un sistema di scoring automatizzato non dichiarato come “ad alto rischio” ai sensi dell’Art. 6 dell’AI Act. Perché importa: finita la luna di miele della compliance “best effort”. Chi vende o integra AI in prodotto sul mercato europeo dovrebbe leggere con attenzione gli articoli 50-60 del regolamento, in particolare gli obblighi di trasparenza e i requisiti per i sistemi ad alto rischio. La soglia di enforcement si è alzata.

Stanford AI Index 2026: il costo di inference è crollato Il report completo documenta una riduzione dell’80% del costo di inference per i modelli frontier negli ultimi 18 mesi. GPT-4 level performance costa oggi una frazione di quello che costava a fine 2023. Perché importa: cambia radicalmente il calcolo del TCO (Total Cost of Ownership) per chiunque integri AI in prodotto. Use case che non reggevano l’economics a 2023 possono essere rivalutati. Attenzione però: il costo di inference scende, ma il costo di orchestrazione, retry e validazione rimane — e spesso domina.

Qualcosa per approfondire

“Agents in Production” — Latent Space Podcast

Il deep-dive più onesto che ho letto sull’argomento negli ultimi mesi. Interviste con 8 team che hanno deployato agenti reali — non demo, non PoC, sistemi in produzione con utenti veri. Riportano numeri su accuracy, costo medio per task, tasso di retry e architetture adottate. Richiede 30-40 minuti ma vale ogni minuto, soprattutto se sei coinvolto in decisioni di budget su progetti AI.

Il 2026 è l’anno in cui smettiamo di parlare genericamente di “agenti” e iniziamo a parlare di “agenti per X in contesto Y con constraint Z”. Chi costruisce con questa precisione vince. Chi insegue l’AGI in PowerPoint sta sprecando tempo e soldi.

Grazie per aver letto questo articolo fammi sapere cosa ne pensi!

Ci vediamo presto qui su WikiLuc!