L’ANALISI
Agent Compute Engine e Agent Substrate: cosa è disponibile davvero per Hermes
Google separa due livelli per l’esecuzione degli agenti: un servizio microVM gestito ancora in arrivo e un runtime Kubernetes open source già ispezionabile, compatibile con Hermes ma pre-1.0.
In breve: Oggi si può scaricare, ispezionare e provare Agent Substrate su Kubernetes; non si può ancora valutare liberamente il servizio gestito Agent Compute Engine, la cui preview è annunciata per i prossimi mesi. La citazione di Hermes documenta compatibilità del runtime e utilizzo dell’architettura da parte di Nous Research, non una partnership esclusiva né una validazione indipendente delle prestazioni.
Due prodotti, due stati di disponibilità
Agent Compute Engine è il servizio Google Cloud che assegna a ogni sessione agente una microVM isolata, con persistenza, rete mediata e credenziali mantenute fuori dal sandbox. Google indica una preview nei prossimi mesi. Agent Substrate è invece il runtime open source già pubblicato per portare lo stesso modello operativo su cluster Kubernetes.
Perché la citazione di Hermes è rilevante
La pagina Google elenca Hermes tra gli harness compatibili e afferma che Nous Research usa questa architettura per distribuire agenti multi-tenant nell’infrastruttura esistente dei clienti. Il punto pratico è il confine di deployment: il runtime mira a mantenere isolamento, identità e controllo di rete nel cluster del cliente, senza trasformare Hermes in un servizio Google gestito.
Il modello di sicurezza dichiarato
Agent Substrate tratta ogni workload come non fidato, usa sandbox gVisor o microVM e assegna identità crittografiche per agente. Le credenziali vengono iniettate da un gateway esterno soltanto sulle richieste consentite. È una separazione utile contro prompt injection ed esfiltrazione, ma la sicurezza effettiva dipende dalla configurazione del cluster, dalle policy e dalla verifica della supply chain.
Che cosa offre il repository
Il progetto è distribuito con licenza Apache 2.0, gira su Kubernetes e distingue il runtime dall’SDK che costruisce l’agente. Documenta quickstart, threat model, egress controllato, snapshot e benchmark. Il rilascio stabile più recente osservato è v0.6.0 del 22 ottobre, quindi il progetto resta esplicitamente pre-1.0.
Come leggere i benchmark
Google e il repository dichiarano alta densità, ripresa sub-secondo e test su grandi quantità di agenti. Questi dati descrivono le condizioni scelte dal produttore e non dimostrano automaticamente costo, latenza o isolamento nel cluster di un cliente. Servono misure ripetibili con lo stesso harness, identiche policy di rete e carichi realistici.
Condizioni e limitazioni
Agent Compute Engine non è ancora disponibile per una prova pubblica e non va confuso con Agent Substrate. Il runtime open source è pre-1.0, non garantisce retrocompatibilità e i numeri di densità, attivazione e scala pubblicati sono benchmark del progetto, non risultati riprodotti da Francesco.
Checklist pratica
- Fissare tag o commit di Agent Substrate e conservare checksum e manifest.
- Usare un cluster di laboratorio separato, senza dati o credenziali di produzione.
- Verificare versioni Kubernetes supportate, runtime gVisor o microVM e requisiti beta del cluster.
- Applicare policy egress deny-by-default e controllare dove avviene l’iniezione delle credenziali.
- Provare un solo harness con task controllati e output non sensibili.
- Misurare cold start, resume, densità, memoria, errori e costo per task riuscito.
- Eseguire test di isolamento tra tenant e tentativi di esfiltrazione simulati.
- Trattare Agent Compute Engine come non disponibile finché la preview non è realmente accessibile.