Con il lancio dei Managed Agents nella Gemini API, annunciato durante Google I/O, Google compie un passo che cambia il modo in cui si concepisce il deployment di un agente. Tutto ciò che fino a ieri richiedeva giorni di lavoro infrastrutturale (ad es. predisporre ambienti di esecuzione, gestire sandbox, cablare la tool call infrastructure, orchestrare i loop di esecuzione) viene compresso in una singola chiamata API. L’idea di fondo è semplice da enunciare e densa di conseguenze: il runtime dell’agente non vive più nell’infrastruttura del cliente, ma dentro la piattaforma del provider.
Ogni chiamata istanzia un agente che gira in un ambiente Linux isolato ed effimero, basato sull’harness Antigravity e ottimizzato su Gemini 3.5 Flash. L’agente è in grado di ragionare, pianificare, eseguire codice, navigare il web, leggere e scrivere file, mantenendo stato persistente attraverso le interazioni multi-turn. La superficie di esposizione è duplice: l’Interactions API per l’integrazione programmatica e Google AI Studio per la prototipazione tramite template personalizzati. Il developer interviene principalmente attraverso due parametri di configurazione, il system_instruction per modulare il comportamento per singola chiamata e il parametro tools per sovrascrivere il set predefinito, che include code_execution, google_search e url_context. In più, un file AGENTS.md consente di definire istruzioni persistenti che si compongono additivamente con quelle inline.
Il posizionamento rispetto agli altri player rende la mossa più leggibile. Anthropic con i suoi Managed Agents ha scelto di radicare l’orchestrazione al livello del modello, lasciando agli enterprise il controllo dello strato esecutivo; AWS, attraverso Bedrock AgentCore, fornisce harness gestiti che assemblano le componenti upfront del deployment ma rimangono un layer sopra il runtime del cliente. Google invece compie l’integrazione verticale completa: modello, harness e sandbox vengono co-ottimizzati e fatti girare interamente all’interno di ambienti gestiti da Google. Non è più un harness offerto come servizio, è l’intero ciclo di vita dell’esecuzione che viene assorbito nella piattaforma.
Il trade-off è esattamente quello che il design implica. Si guadagna velocità di iterazione enorme, il team può concentrarsi sul behavior dominio-specifico e sul prodotto, abbandonando la manutenzione dell’infrastruttura e si perde gradi di libertà sul layer di esecuzione. Non si configura il container, non si ispeziona la sandbox in tempo reale, non si applicano sistemi di monitoraggio custom sul compute sottostante. Per scenari in cui contano auditabilità, comportamento deterministico, conformità a framework regolatori specifici o tracciamento granulare delle azioni dell’agente, questa opacità è un fattore che va pesato con attenzione, soprattutto considerando che la dipendenza si estende anche a eventuali rate limit, deprecation o modifiche di comportamento decise unilateralmente dal provider.
L’aspetto strategicamente più interessante è la continuità con il resto dello stack. I Managed Agents si inseriscono in un disegno che comprende Antigravity 2.0 come desktop application per il prototyping locale, l’Antigravity CLI, l’integrazione con Vertex e con il Gemini Enterprise Agent Platform per i carichi enterprise dentro Google Cloud, e l’esportabilità diretta dei progetti da AI Studio verso Antigravity. Il percorso che si delinea è quello di un funnel che parte dall’esperimento in AI Studio e arriva alla deployment in produzione restando sempre dentro perimetri Google. La scelta della preview pubblica accompagnata da governance features suggerisce che il bilanciamento tra astrazione e controllo verrà rifinito prima della general availability, ma la direzione di marcia è netta: la piattaforma rivendica il possesso dell’execution layer, e chi costruisce sopra deve decidere quanto di quel possesso è disposto a cedere in cambio di rapidità e di un’esperienza di sviluppo radicalmente semplificata.