Approfondimento
Agenti AI: dai modelli alle piattaforme operative tra microVM, session endpoints e harness dinamici
Testo scritto con l’intelligenza artificiale a partire da 5 fonti citate, senza revisione umana prima della pubblicazione.
La ricerca sugli agenti AI sta spostando l'attenzione dal solo modello alle piattaforme operative: runtime in microVM, endpoint di sessione realtime e harness adattivi rendono possibile portare agenti esecutivi dal prototipo alla produzione, con implicazioni su latenza, sicurezza e governance.
Apri un URL autenticato e vedi la web app che l’agente sta costruendo aggiornarsi in pochi secondi. Niente deploy intermedio, niente attese. Amazon mostra i Session Endpoints di Bedrock AgentCore e lega il browser all’app che gira nella microVM della sessione1. Gli agenti escono dalla sola sfera del modello e diventano piattaforme operative con runtime isolati, collegamenti di sessione in tempo reale e configurazioni adattive.
Runtime isolati e collegamento diretto con il browser
Bedrock AgentCore isola ogni sessione in una microVM. Per ciascuna espone un Session Endpoint: un URL autenticato che collega il browser all’app in esecuzione dentro quell’ambiente1. Il percorso del traffico è definito: l’endpoint inoltra metodo HTTP, path, query string e body verso l’app della sessione. Inoltra anche le connessioni WebSocket. Le richieste raggiungono solo le porte autorizzate per quella sessione1.
Ne nasce un ciclo stretto: usi l’app, chiedi una modifica, verifichi il risultato. L’app resta nell’ambiente dove l’agente scrive e salva. Il browser vede gli effetti senza passaggi esterni1. L’agente espone un prototipo funzionante che puoi validare a colpo d’occhio.
La conseguenza è pratica. Il runtime non esegue solo codice. Definisce confini di esecuzione e di rete, con regole su cosa può attraversare la sessione. Per chi testa agenti di coding, il tempo di feedback dipende da questo collegamento di sessione, non da una pipeline di distribuzione.
Densità, avvio rapido e isolamento hardware come prerequisiti operativi
Google Cloud introduce Agent Compute Engine con sandbox in microVM e isolamento hardware. Promette avvio sotto il secondo e alta densità grazie alla memoria copy-on-write3. Accanto ci sono Agent Gateway e Agent Registry. Il pacchetto riunisce esecuzione e governance nello stesso ambito, con gestione dell’identità e osservabilità cross-cloud3.
Il target sono carichi agentici che si accendono spesso e in parallelo. Avvio rapido, densità elevata, isolamento forte. Uso efficiente delle risorse e controllo centralizzato su sicurezza e identità in ambienti eterogenei3. Gli autori non presentano un riuso generico. Descrivono una risposta a requisiti specifici di agenti autonomi3.
Qui la convergenza con Bedrock è evidente: microVM e confini di rete precisi. Google aggiunge il ciclo di vita su larga scala. Lancia componenti per orchestrare, non solo per eseguire. Per chi opera, la scelta del runtime non si esaurisce nella velocità del modello. Contano il tempo di accensione della sessione, la densità per nodo, il piano di identità, l’osservabilità.
Harness dinamici: adattare la configurazione dell’agente al compito
Google Research parte da un dato: sullo stesso compito, cambiare harness cambia il vincitore. Claude Code regge su codice e fogli di calcolo. Codex si prende i compiti web5. Da qui nasce Harness², un metodo che adatta in tempo reale prompt, strumenti, memoria e regole di esecuzione al task corrente. Non aggiunge capacità al modello. Cambia come lavora durante il test5.
Molti errori non nascono dal modello, ma dal contesto operativo: istruzioni vaghe, strumenti male scelti, memoria fragile, controllo dei passi incerto. Il harness governa questi elementi. Modificarlo modifica gli esiti, spesso più di un refresh del modello5. Harness² mostra che la configurazione può seguire il compito, anche su task non previsti in fase di design, dove i preset rigidi perdono colpi5.
Se runtime e collegamenti di sessione abilitano il ciclo di feedback, il harness decide se l’agente lo usa bene. Per chi integra agenti in flussi reali, l’ordine delle priorità cambia: prima si ottimizza il setup operativo, poi si cambia modello.
Esecuzione locale e scenari offline: esempi pratici
Due progetti GhostShell AI su GitHub portano l’agente in locale. Uno vive nel terminale. L’utente digita un comando, per esempio git status. GhostShell analizza l’input e usa un modello in locale per generare una risposta “spettrale”, con una breve spiegazione. Tre personalità danno voce al sistema: Whispering Ghost, Angry Poltergeist, Ancient Programmer4. La demo mostra esecuzione in locale, cambio di personalità e risposte al volo. Codice e materiali sono nel repository indicato4.
La seconda variante adotta una web app scura. L’assistente risponde a domande generiche, spiega comandi Git e offre aiuto di base. Funziona offline, senza servizi cloud4.
Questi esempi affiancano le microVM cloud. Mostrano l’agente come unità esecutiva concreta, ancorata a un confine controllato. In un caso è la microVM con Session Endpoint. Nell’altro è il terminale o una web app locale.
Valutare i modelli nel contesto dell’operatività
La qualità del modello va letta dentro procedure chiare di esecuzione e test. Real Python ha eseguito lo script turtle generato da GPT-6.1 Terra. Obiettivo: disegnare un pitone che legge un libro. Partito al primo colpo, senza errori. Stesse regole per tutti i modelli del confronto informale. Nessun system prompt. Stesso set di prompt. Esecuzione del codice così come prodotto, niente ritocchi. In questo caso, esito positivo2.
La stessa overview del benchmark affianca a ogni modello il punteggio “Python feature” e l’anno di rilascio, e invita a evitare letture semplicistiche. Un modello può usare feature recenti e ottenere un punteggio più basso. Le metriche vanno lette nel contesto delle singole run2.
Qui torna Harness²: valutare senza curare harness e condizioni di esecuzione porta a conclusioni fragili. Un modello affidabile su turtle con parametri espliciti non garantisce risultati su compiti diversi se cambiano strumenti, memoria e regole operative.
Cosa cambia per chi costruisce e gestisce agenti
I fatti puntano nella stessa direzione. Per portare agenti dal prototipo alla produzione servono tre pilastri coordinati.
- Un runtime isolato che si accende in fretta. MicroVM con percorsi di rete controllati, come nei Session Endpoints di Bedrock1, o sandbox con avvio sotto il secondo e densità copy-on-write, come in Agent Compute Engine con Gateway e Registry3.
- Un collegamento di sessione sicuro verso l’interfaccia utente. Browser che parla con l’app nella stessa sessione, con inoltro HTTP e WebSocket e porte autorizzate definite1.
- Un harness che si adatta al compito. Prompt, strumenti, memoria e regole che cambiano al volo senza toccare il modello, come suggerisce Harness²5.
La scelta tra cloud e locale resta aperta. GhostShell mostra che alcuni scenari vivono offline, dentro un terminale o una web app senza servizi esterni4. In altri casi serve accendere molte sessioni in parallelo con identità e osservabilità centralizzate3. Nel riepilogo del lancio, gli autori collocano queste capacità tra le iniziative per mettere in sicurezza e scalare agenti con componenti di esecuzione e di governance nello stesso perimetro3.
Fonti
- Amazon mostra le web app degli agenti Bedrock in esecuzione
- GPT-6.1 Terra disegna un pitone che legge un libro con turtle
- Google Cloud lancia Agent Compute Engine per agenti autonomi
- GhostShell AI trasforma il terminale in un «fantasma» che risponde localmente
- Google Research presenta Harness² per adattare al volo i harness degli agenti AI
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici
Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:
- Rilettura. Un passaggio toglie i tic della prosa generata da un modello, come i contrasti costruiti e le frasi che annunciano invece di informare, senza toccare fatti e fonti.
- Fedeltà alle fonti. Un passaggio dedicato toglie ogni affermazione che le fonti non sostengono. Valutazione su questo pezzo: 9/10.
- Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale: superato.
- Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica. Questo articolo ha preso 8,2/10.
I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.
Per vedere Millebit nelle notizie principali di Google, aggiungilo alle tue fonti preferite. Oppure segui l’edizione di oggi, il feed RSS o La Sintesi.