Perché gli agenti orchestrati valgono più per l'infrastruttura che per il solo modello

Google cambia il motore di un suo managed agent senza chiedere modifiche al codice: l’agente antigravity-preview-05-2026 passa a Gemini 3.6 Flash alla prossima chiamata. L’API espone anche la scelta esplicita del modello e introduce environment hooks e free tier. Il messaggio è operativo: contano orchestrazione e controllo, non solo il modello di turno. La tesi: l’utilità reale degli agenti orchestrati dipende dalla regia, dalla memoria persistente e da dove girano, in cloud o sul dispositivo.

1) La nuova priorità: configurazione e orchestration come leva operativa

Google aggiunge tre leve alla Gemini Interactions API: environment hooks, selezione del modello con agent_config.model e accesso al free tier. I Managed Agents eseguono in una singola chiamata ragionamento, codice, installazione di pacchetti, gestione file e recupero web, dentro un sandbox cloud isolato. L’unità operativa non è più la risposta del modello. È un lavoro composto che vive in un ambiente controllato.

La selezione del modello si sposta a configurazione. Puoi fissarla alla creazione dell’interazione o del managed agent. Google cita un’opzione a costo inferiore e consente di bloccare un modello specifico se serve stabilità. In parallelo cambia un default sensibile: l’agente antigravity-preview-05-2026 adotterà Gemini 3.6 Flash. La transizione è automatica e scatta alla prossima interazione. Nessuna modifica al codice esistente.

Gli environment hooks si aggiungono a tasselli già introdotti, come i background tasks e l’integrazione con server MCP remoti. L’obiettivo resta l’orchestrazione di attività in ambienti controllati e riutilizzabili. La leva non è “quale modello usare” in astratto. È “come lo incastri in un flusso durevole e governabile”.

2) Separare regia e decisione per evitare blocchi di stato

AWS spinge la stessa idea da un altro angolo: separare orchestrazione e ragionamento. Propone LangGraph per governare il flusso e Strands per le decisioni locali, su AgentCore. Il problema è pratico: processi lunghi, variabili, con molti passaggi. Servono ruoli distinti, come riconoscere pattern di trading, indagare anomalie, redigere report. Serve ripartire dopo un errore. I modelli a singolo agente faticano a reggere questi vincoli in produzione.

Il disegno introduce un accoppiamento a due livelli. LangGraph definisce il grafo di esecuzione. Coordina gli specialisti. Mantiene uno stato condiviso e persistente. Consente passaggi di contesto affidabili tra agenti e ripartenze controllate in caso di fallimento di un nodo o di un passaggio. Strands alimenta il ragionamento degli agenti. Fornisce il livello decisionale che varia caso per caso e resta confinato dove serve, senza confondersi con il controllo del flusso.

Questo separa responsabilità e riduce la pressione sullo stato. Il “chi decide cosa” non si mescola con il “quando e come passare il testimone”. La qualità del modello conta. Ma senza uno stato persistente e una regia riavviabile, i workflow lunghi si inceppano.

3) La working memory dell’orchestrator come criterio per delegare

“The Orchestrator’s Tax” mette un nome alla frizione che molti vedono nel lavoro quotidiano: il costo cognitivo dell’orchestrator. L’articolo nasce da un episodio concreto con quattro subagent su una response-pipeline, risultati fuori ordine e una sessione più difficile da seguire del codice. La tesi sposta il fuoco. Il valore dei subagent non è il parallelismo o i minuti risparmiati. È quanto tengono fuori dal contesto dell’orchestrator. Ogni token nel contesto compete per attenzione. La risorsa scarsa è la sua working memory.

Conseguenza pratica: progettare i subagent come filtri di carico cognitivo. Delegare il ragionamento che l’orchestrator non deve trattenere. Far rientrare in regia solo risultati sintetici e minimali. Questa prospettiva rende esplicite due decisioni: quando delegare e con quale scopo. Non sono effetti collaterali dell’ottimizzazione delle prestazioni. Sono scelte di gestione della memoria.

Incrociata con la separazione di regia e decisione, la tesi diventa un criterio di design. L’orchestratore conserva lo stato utile e l’ordine del flusso. I subagent producono decisioni locali e riducono il rumore nel contesto. Si paga meno “tassa” di orchestrazione.

4) Distribuzione cloud↔endpoint: quando dare all’agente accesso al computer dell’utente

Perplexity porta “Personal Computer” su Windows. L’agente gira in locale, accede ai file salvati sul disco e interagisce con le applicazioni installate. Crea documenti e aggiorna fogli di calcolo. Non opera più solo via integrazioni. Opera dentro il sistema operativo. Il lancio segue due tappe: debutto su macOS in aprile, integrazioni con Microsoft 365 e con Teams in maggio. Ora presenza nativa su Windows con accesso ai contenuti locali.

La guida aggiornata di Ethan Mollick, segnalata da Simon Willison, suggerisce il quadro decisionale. Sposta il focus dai chatbot ai “sistemi agentici” capaci di svolgere “l’equivalente di molte ore di lavoro umano in un colpo solo”. Una scelta diventa centrale: “dare all’AI un computer”. Ci sono due strade. Usare i computer forniti dal provider. Oppure dare accesso al proprio dispositivo, indicata come via più potente nella guida. In entrambi i casi bisogna impostare la modalità corretta nelle app di ChatGPT o di Claude. Le etichette divergono tra prodotti. Willison cita Work e Codex in ChatGPT, Cowork e Code in Claude.

Qui la regia incontra l’endpoint. L’esecuzione locale apre accesso a dati e applicazioni. L’orchestrazione cloud offre coordinamento, stato persistente e ripartenze controllate. La decisione su dove far girare cosa diventa parte del disegno dell’agente.

5) Implicazioni pratiche per chi progetta agenti orchestrati

Le mosse di Google rendono il modello una scelta operativa. agent_config.model sposta la selezione fuori dal codice. L’opzione a costo inferiore citata introduce un asse costo‑prestazioni esplicito. Il cambio di default dell’agente antigravity-preview-05-2026 a Gemini 3.6 Flash mostra che la piattaforma può aggiornare senza toccare l’integrazione. La transizione avviene alla prossima chiamata. Il free tier amplia le modalità di accesso.

La proposta di AWS dà una traccia per i workflow lunghi. Investire in una regia che mantenga stato condiviso e persistente, come un grafo di esecuzione riavviabile, riduce fallimenti e semplifica le ripartenze. Tenere il ragionamento locale confinato in componenti dedicati limita la deriva del contesto e le interferenze tra scopi.

La “tassa dell’orchestrator” offre un metro di misura. Definire subagent con confini chiari. Pretendere output sintetici. Ridurre i token che l’orchestratore deve ricordare. La metrica è la protezione della sua working memory, non la lunghezza della coda di job.

La distribuzione tra cloud ed endpoint completa il quadro. L’esecuzione locale, come nel caso di Perplexity su Windows, abilita automazioni su file e applicazioni del PC. Richiede scelte esplicite su controllo e reintegro dei risultati nel flusso centrale. La guida di Mollick aiuta a formalizzare la decisione: provider o dispositivo proprio, con attenzione alle modalità effettive esposte dai prodotti, che usano etichette diverse.

Il filo che lega i casi è chiaro: orchestrazione, gestione del contesto e placement del lavoro contano quanto la scelta del modello. Se questi tre elementi reggono, la piattaforma può cambiare motore senza fermare la marcia.