Agenti AI in produzione: strumenti operativi, costi e responsabilità

“Il numero di parametri ha senso solo insieme ad altri tre: quanti dati hai, dove spendi il compute e chi eseguirà il modello, in quali condizioni.” Con questa frase, Jie Tang sposta il giudizio sui modelli dal laboratorio alla sala macchine. E usa GLM 5.3 per indicare dove maturano i guadagni: reinforcement learning su ambienti a lungo orizzonte, progettati sui flussi reali di ingegneria. La tesi: se portiamo agenti in produzione, contano contesto operativo, controlli di runtime e metriche di qualità. Non il singolo numero.

1. Ridimensionare la metrica dei parametri: contesto operativo prima del numero

Tang aggancia la valutazione dei modelli a tre leve concrete. Dati. Strategia di calcolo. Condizioni d’uso. Non basta la taglia. Il riferimento a GLM 5.3 non serve a discutere architetture, ma a mostrare un metodo: investire nel reinforcement learning su compiti a molti passi. Qui il modello impara a “tenere il filo” su workflow reali. Il terreno sono ambienti che riflettono come si lavora davvero in ingegneria.

Il messaggio è operativo. Chi sceglie modelli per agenti deve guardare dove posare il compute e come alimentare il training con dati giusti. La dimensione resta un fattore, ma senza i tre vincoli non dice cosa il sistema farà in esercizio. È una rottura utile. Evita confronti fuorvianti tra modelli di classi diverse.

2. Lo scarto tra demo rapida e software enterprise

C’è un’altra frizione da chiarire. Una demo costruita in pochi giorni “gira” e conquista la sala. Da qui nasce la domanda: perché i team non vanno dieci volte più veloci? Il saggio “Citizens Build, Agents Execute, Experts Govern” mette a terra il fraintendimento. Un prototipo mostra una funzionalità in condizioni controllate. Un prodotto regge sicurezza, affidabilità, integrazioni, governance. Sta in piedi con on-call, audit, carico, cambi di requisito e convivenza con altri sistemi.

Il punto non è sminuire chi sperimenta. È fissare i confini tra esplorazione e produzione. Portare un agente oltre la demo implica scegliere fonti affidabili, garantire freschezza dei dati, gestire errori prevedibili e imprevisti. Significa anche accettare tempi diversi. Una giornata di hacking non sostituisce processi che assicurano tracciabilità e responsabilità in esercizio.

3. Filtri runtime e controllo delle fonti come requisito operativo

Amazon ha introdotto un controllo mirato nel connettore web-search 1.2.0 di AgentCore su Bedrock. Due filtri, attivabili in runtime per singola chiamata: domini ammessi e finestra temporale delle fonti. L’enforcement avviene lato server. Non serve orchestrazione esterna.

Il caso d’uso è chiaro. Un agente per i servizi finanziari non dovrebbe basarsi su un blog non verificato. Un agente che fornisce informazioni di prodotto non dovrebbe citare prezzi o inventari di tre anni fa quando l’utente chiede disponibilità attuale. I filtri riducono il rischio: restringono l’origine e impongono freschezza ai contenuti. Le regole di chiamata si combinano con policy amministrative di dominio. Ne nasce un filtraggio a più livelli: i limiti organizzativi fissano il perimetro, i filtri lo affinano in base alla richiesta.

Questo non è un dettaglio. È il passaggio da “l’agente cerca sul web” a “l’agente rispetta i confini dell’organizzazione”. La granularità per query consente compromessi locali: si apre a un dominio per un’indagine specifica, lo si richiude alla chiamata successiva. Si governa così la superficie d’attacco e si alza la qualità delle risposte dove conta, senza bloccare la sperimentazione.

4. Pattern architetturali per contenere i costi operativi

C’è un costo silenzioso nelle pipeline serverless che parlano con agenti. Ogni secondo di attesa si paga. Amazon consiglia di invocare gli agenti Bedrock AgentCore in modo asincrono per evitare compute in idle e tagliare la bolletta. Lo schema sincrono blocca funzioni come AWS Lambda fino alla risposta. La fatturazione scorre anche quando la funzione non lavora. Il pattern asincrono libera le risorse subito e riprende solo all’arrivo dell’output.

L’esempio riguarda la validazione documentale in un back office di finanziamento immobiliare. Un agente legge atti o contratti, verifica completezza e coerenza, sblocca lo step successivo. La latenza varia con prompt, modello e documento. Lo schema “chiamo e aspetto dentro una funzione” produce tempi imprevedibili e costi inefficienti. L’asincronia ammortizza la variabilità e riduce lo spreco.

5. Responsabilità e nuove metriche di produttività con agenti

Gli agenti di coding rimettono sul tavolo una metrica discussa: le linee di codice. Simon Willison offre un perimetro netto. Le linee contano solo se il codice resta “della stessa qualità”: manutenibile, testato, pronto per la produzione. Dentro questo perimetro, con agenti si può arrivare a “un migliaio di righe di codice già debugged” in un giorno. In passato, una giornata “incredibilmente buona” valeva 200 righe. La media stava tra 50 e 60 righe. Parole sue, al minuto 35:01 di Talking Postgres.

Il ragionamento risponde a un’obiezione diffusa: “misurare le linee non ha senso”. Willison “non è d’accordo”. Esiste “un limite duro” a quante righe di qualità si possono scrivere in un giorno senza aiuto. Se gli agenti alzano quel limite senza sacrificare la qualità, la quantità torna un segnale utile. Ma resta condizionata da test, manutenibilità e livello produzione.

Le organizzazioni devono quindi riallineare responsabilità. Chi decide le fonti e le finestre temporali per gli agenti? Chi impone l’asincronia nelle pipeline per evitare costi a vuoto? Chi valuta che “mille righe” rispettino standard e test? La linea tra “citizen”, “agent” ed “expert” si sposta sui confini operativi: scelta delle fonti, politiche di esecuzione, definizioni di qualità. Così i guadagni dei modelli si traducono in pratica, senza drogare i numeri e senza scaricare rischi sui team.

La traiettoria è chiara nelle fonti: meno culto del parametro, più attenzione a dati, compute e condizioni d’uso; meno demo, più controlli di runtime e pattern robusti; metriche vecchie rilette sotto vincoli di qualità. Il passaggio apre uno spazio concreto per chi fa ingegneria, QA e piattaforme: costruire checklist e strumenti che rendano default i filtri per chiamata, l’asincronia e la verifica della qualità del codice generato, prima che i numeri diventino obiettivi.