Dagli LLM agli agenti: runtime, adattamento e controlli per metterli in produzione

Google Cloud annuncia Agent Compute Engine con microVM, avvio sotto il secondo e memoria copy‑on‑write, accanto ad Agent Gateway e Agent Registry. Obiettivo: mettere in sicurezza e scalare agenti che si accendono spesso e in parallelo, con governance nello stesso perimetro di esecuzione¹. La tesi: il passo avanti sugli agenti non è nel modello, ma nel sistema operativo che li regge.

Perché serve un ecosistema operativo per agenti

Gli errori degli agenti spesso non nascono dal modello. Vengono dal contesto: istruzioni vaghe, strumenti scelti male, memoria fragile, regole di esecuzione poco chiare². In produzione, a questo si sommano vincoli concreti: avviare istanze in fretta, isolarle a livello hardware, tenere traccia di identità e azioni con osservabilità cross‑cloud. Qui conta la pila, non solo il parametro¹.

Tre mosse diverse mostrano la direzione. Google Cloud mette il runtime in microVM e unifica governance ed esecuzione¹. Google Research lavora sul “come” dell’agente, adattando al volo prompt, strumenti e memoria, senza toccare il modello². Samaya pubblica un agente verticale sulla finanza che dichiara un rapporto qualità prezzo migliore di un generalista più costoso³. Infine, quattro modifiche a Claude Code inseriscono controlli automatici su segreti, piani e qualità del codice con overhead contenuto⁴. Insieme, compongono l’ossatura di un ambiente operativo.

Runtime: microVM, avvio sotto il secondo e densità per carichi agentici

Agent Compute Engine esegue agenti in microVM con isolamento hardware. Promette attivazione in sotto‑secondo e alta densità grazie alla condivisione della memoria con copy‑on‑write. Si affianca ad Agent Gateway e Agent Registry. Integra gestione dell’identità e osservabilità cross‑cloud. Il tutto è presentato nel riepilogo “What’s new in AI infrastructure and orchestration in October” firmato da Alex Barrett e Dave Bartoletti¹.

Il messaggio è chiaro: gli agenti richiedono carichi brevi, frequenti e paralleli. L’avvio rapido evita tempi morti. Il copy‑on‑write riduce l’uso di memoria per istanza. L’isolamento hardware separa le esecuzioni. Gateway e Registry aggiungono controllo centralizzato su sicurezza e identità, nello stesso perimetro del runtime¹. Non è un riuso generico di componenti, ma una risposta ai pattern degli agenti, come scrivono gli autori¹.

Questa struttura abilita carichi paralleli e controllati. Avviare in fretta, impacchettare in densità, osservare in modo coerente tra cloud diversi sono leve operative, non di modello. Creano lo spazio dove intervenire su comportamento e governance¹.

Adattare il comportamento senza readdestrare: il ruolo del harness

Google Research introduce Harness², un metodo che non aggiunge capacità al modello. Cambia il “come” durante l’esecuzione. Il harness governa prompt, strumenti, memoria, regole. Modificarlo modifica gli esiti. Nei test citati, cambiare harness, a parità di compito, ha scambiato il vincitore tra sistemi: Claude Code regge su codice e fogli di calcolo, Codex vince su compiti web².

Harness² adatta questa configurazione in tempo reale. Riorganizza il setup, seleziona strumenti diversi, snellisce o rafforza le istruzioni. Mira ad allineare ciò che il modello già sa al compito corrente. Funziona anche su task non previsti a design, dove i preset rigidi perdono colpi².

Il nesso con il runtime è diretto. Un motore che accende microVM sotto il secondo consente a un orchestratore di provare varianti di harness senza pagare penali di startup. L’agente può cambiare strumenti o memoria tra invocazioni ravvicinate. L’osservabilità cross‑cloud collega il comportamento adattivo a metriche gestite nello stesso perimetro di governance^1,2.

Agenti specialistici e tradeoff costo qualità

Samaya rilascia Sterling, un agente per ricerca finanziaria. Dichiara 58,9% su FrontierFinance in modalità standard e 60,6% in modalità ad alto sforzo. Il costo per domanda è 0,61 dollari. Claude Fable 5.1 si ferma al 55,9% e costa 6,89 dollari per domanda, secondo i numeri riportati da Samaya³. Sul terzo superiore per difficoltà, Sterling dichiara il 45,2%³.

Sterling nasce da Nemotron 3.5 Lightning di NVIDIA, un mixture of experts con 30 miliardi di parametri totali e 3 miliardi attivi per query. Samaya parla di post‑addestramento con LoRA mirato alla ricerca finanziaria agentica. Pianifica, usa strumenti, raccoglie evidenze³. Il modello base dichiara un contesto massimo di 1 milione di token. In BF16, con 256 mila token di contesto, entra su una H100 da 80 GB. Samaya non specifica il contesto usato in serving per Sterling, né l’hardware effettivo di serving³.

La lezione è pragmatica. Per alcuni domini, una specializzazione leggera con LoRA su un MoE può spostare il rapporto qualità prezzo rispetto a un generalista. Ma la valutazione per la produzione richiede trasparenza su contesto e hardware di serving, che qui non sono indicati. Un runtime con osservabilità e controllo centralizzato, come quello descritto da Google Cloud, aiuta a misurare e confrontare agenti verticali con metriche comparabili su carichi reali^1,3.

Governance automatica: proteggere segreti, tracciare piani e qualità del codice

Quattro modifiche per Claude Code mostrano come innestare controlli a basso costo nel ciclo di vita dell’agente. Bloccano la stampa di segreti, tracciano i piani, segnalano codice senza test, monitorano l’uso del contesto. L’autore riporta 135 test superati e fino a 100× meno overhead rispetto agli hook tradizionali⁴.

Il caso d’uso è concreto. Un workspace locale con file .env contiene chiavi API e password. Tra il 9 agosto e il 7 ottobre 2026, l’autore ha aperto 60 sessioni. In 20 ha chiesto esplicitamente a Claude di non stampare valori segreti. Ha poi scansionato tutte le sessioni e non ha trovato corrispondenze esatte con i valori .env. Rassicurante, ma dipendeva da promemoria manuali. I mod spostano quel controllo in automatico. Intercettano l’uscita prima che un valore sensibile finisca su schermo, nei log o nell’output del modello⁴.

Questi controlli, se collegati a un Agent Registry e a un runtime con identità e osservabilità, possono diventare policy applicate in modo coerente a più agenti e ambienti. Si possono far rispettare regole comuni su segreti, piani e qualità del codice, senza introdurre overhead rilevante. La catena governance, registry, runtime crea un circuito vicino all’esecuzione: definisci regole, le applichi dove girano gli agenti, le osservi in modo centralizzato^1,4.

Un filo unico: esecuzione, adattamento, specializzazione, controllo

I quattro tasselli disegnano una tendenza. Mettere in produzione agenti richiede:

• un runtime isolato e rapido, con capacità di densità, identità e osservabilità, come Agent Compute Engine con Agent Gateway e Agent Registry¹
• un meccanismo per adattare il comportamento senza readdestrare, come Harness² sul harness dell’agente²
• agenti specialistici quando il dominio lo premia, con attenzione a costo e trasparenza, come il caso Sterling su FrontierFinance³
• controlli automatici a basso overhead nel ciclo di sviluppo ed esecuzione, come i mod per Claude Code su segreti, piani e contesto⁴

La convergenza è operativa più che algoritmica. Non basta un modello migliore. Serve un sistema che accende istanze in fretta, le isola, le osserva, ne adatta il comportamento al volo e blocca in automatico ciò che non deve accadere. I pezzi nelle fonti indicano che questa pila è in costruzione. Per chi sviluppa e fa QA, il margine sta in come si combinano questi componenti più che nel nome del modello che li alimenta.