Google Antigravity: come migrare i job API entro il 5 ottobre

Google Antigravity: che cosa cambia davvero

Il cambiamento riguarda l’agente gestito Antigravity nella Gemini API. Non è un aggiornamento dell’IDE Antigravity installato sul computer.

I due prodotti condividono parte dell’infrastruttura di esecuzione, da qui la sovrapposizione dei nomi. In questo caso, però, cambia l’ID agente che l’applicazione invia alla Interactions API di Google e, per alcune integrazioni, cambiano anche le chiamate ai tool integrati gestite dall’applicazione. Aggiornare l’IDE non modifica automaticamente questo contratto API.

Il nuovo agente è antigravity-preview-09-2026. Il modello di ragionamento predefinito è Gemini 3.8 Flash, anche se la guida ad Antigravity Agent spiega come scegliere un altro modello supportato tramite agent_config. La precedente guida ai Gemini Managed Agents descrive workspace ospitato, job in background e ciclo dei tool. Questa migrazione avviene a un livello più basso: stabilisce se quei job possano ancora partire e se le relative chiamate ai tool possano ancora essere eseguite.

Nella nota di rilascio del 17 settembre, Google distingue due percorsi di migrazione:

• Un job eseguito in una sandbox remota che legge soltanto output_text o model_output deve cambiare la stringa dell’agente.
• Un job che usa local_environment o analizza i passaggi function_call deve aggiornare anche il proprio adapter dei tool.

È questa la distinzione decisiva. L’adapter è il piccolo componente dell’applicazione che riceve nome e argomenti di un tool, li convalida, esegue l’azione locale e restituisce il risultato.

Il contratto dei tool locali cambia in cinque punti

Il vecchio agente trattava gran parte delle operazioni sui file come letture e scritture generiche. L’agente di settembre assegna nomi e argomenti più specifici alle operazioni sui file. Inoltre, le chiavi degli argomenti passano da snake_case a PascalCase.

Sono cambiate cinque famiglie di funzioni per file e ricerca. Due dei tool integrati elencati sono rimasti invariati. Per questo un handler generico costruito attorno a write_file può fallire anche quando il nuovo ID agente è corretto.

Anche il nuovo contratto di modifica è più preciso. Invece di restituire un intero file per una piccola variazione, l’agente indica l’intervallo di righe, il testo che si aspetta di trovare e quello sostitutivo. L’adapter dovrebbe rifiutare la chiamata se TargetContent non corrisponde più al contenuto del file. Altrimenti, un job in ritardo potrebbe sovrascrivere una modifica umana più recente.

Quali job di Google Antigravity richiedono una vera migrazione

Un founder indipendente con un job remoto per i report

Immagina un job notturno che chiede ad Antigravity di raccogliere dati nella sandbox di Google, salvare un report e restituire il testo finale. L’applicazione legge output_text e non esamina i passaggi sottostanti.

Questa è la migrazione più semplice. Sostituisci antigravity-preview-05-2026 con antigravity-preview-09-2026, esegui un report rappresentativo in parallelo al vecchio job, confronta l’artefatto finale e poi sposta la pianificazione. Non serve ricostruire un dispatcher di tool locali che non esiste.

Un team di piattaforma che esegue tool sulle proprie macchine

Considera invece un worker di repository le cui chiamate ai tool vengono eseguite nel runner dell’azienda. Legge file, cerca nel codice, modifica la configurazione e restituisce i risultati dei tool all’interazione.

Questo team deve affrontare la migrazione più ampia. Il dispatcher deve riconoscere i nuovi nomi, convalidare gli argomenti in PascalCase, applicare le policy su percorsi e comandi, eseguire in sicurezza le modifiche per intervallo di righe e restituire il risultato nel formato atteso dall’interazione. Il vantaggio è la continuità operativa: revisioni del codice, generazione di report e job di manutenzione continueranno a funzionare dopo la scomparsa dell’endpoint di maggio.

Un team di osservabilità che acquisisce ogni passaggio

Alcune applicazioni eseguono tutto da remoto, ma copiano comunque i passaggi function_call in un audit log, un’interfaccia di avanzamento, una coda di approvazione o una dashboard dei costi. Questi team non utilizzano soltanto l’output.

Anche quando è Google a eseguire l’azione integrata sul file system, il parser potrebbe continuare a presupporre write_file, path e content. Aggiorna l’allowlist e le fixture, così la dashboard non contrassegnerà una modifica reale come sconosciuta, non ne perderà gli argomenti e non la invierà alla policy di approvazione sbagliata.

Un responsabile operativo con trigger non presidiati

I trigger pianificati sono il caso più rischioso, perché al momento dell’esecuzione non c’è nessuno a sorvegliarli. Un trigger associa agente, ambiente, prompt e pianificazione cron. Se l’interazione memorizzata indica ancora l’agente di maggio, la pianificazione può apparire integra mentre l’esecuzione sottostante fallisce dopo lo spegnimento.

Censisci l’ID agente in ogni definizione di trigger, non soltanto nella chiamata SDK dell’applicazione principale. Poi esegui in parallelo un job per ogni schema di utilizzo dei tool. Un job di reporting e uno di riparazione del repository non rappresentano lo stesso test di migrazione solo perché entrambi usano Antigravity.

Un piccolo test del contratto di modifica dei file

Il primo test più sicuro non richiede credenziali di produzione. Fornisci all’adapter una fixture acquisita con la forma di una chiamata, modifica un file usa e getta e verifica che sia cambiata soltanto la riga prevista.

Ho eseguito il codice seguente con Node, usando il nome replace_file_content pubblicato da Google e i campi in PascalCase. È un test locale dell’adapter, non una chiamata reale alla Gemini API.

import assert from "node:assert/strict";
import { mkdtempSync, readFileSync, writeFileSync } from "node:fs";
import { tmpdir } from "node:os";
import { join } from "node:path";

function applyReplaceFileContent(call) {
  assert.equal(call.name, "replace_file_content");

  const {
    TargetFile,
    StartLine,
    EndLine,
    TargetContent,
    ReplacementContent,
  } = call.arguments;

  const lines = readFileSync(TargetFile, "utf8").split("\n");
  const current = lines.slice(StartLine - 1, EndLine).join("\n");
  assert.equal(current, TargetContent, "line window no longer matches");

  lines.splice(
    StartLine - 1,
    EndLine - StartLine + 1,
    ...ReplacementContent.split("\n"),
  );
  writeFileSync(TargetFile, lines.join("\n"));
}

const dir = mkdtempSync(join(tmpdir(), "antigravity-adapter-"));
const file = join(dir, "scheduled-job.env");
writeFileSync(file, "owner=ops\nstatus=old\nmode=scheduled\n");

applyReplaceFileContent({
  name: "replace_file_content",
  arguments: {
    TargetFile: file,
    StartLine: 2,
    EndLine: 2,
    TargetContent: "status=old",
    ReplacementContent: "status=ready",
  },
});

assert.equal(
  readFileSync(file, "utf8"),
  "owner=ops\nstatus=ready\nmode=scheduled\n",
);
console.log("PASS: line 2 changed from status=old to status=ready");

Il test è riuscito. Ancora più importante: se si modifica il valore TargetContent della fixture, il test si interrompe invece di intervenire su contenuto non più aggiornato.

Il conto economico: lavoro di migrazione contro attività perse

Google non ha annunciato un nuovo prezzo per token con questa migrazione dell’agente. La voce di budget che cambia riguarda il tempo di engineering e operations.

Usa due formule semplici:

Per un job remoto che usa soltanto l’output, la componente di sviluppo può ridursi alla sostituzione della stringa dell’agente e a un’esecuzione in parallelo. Per un’integrazione con tool locali, metti a budget cinque famiglie di funzioni modificate, le fixture del parser, i test di sicurezza e un’esecuzione completa per ogni diversa tipologia di workflow.

Non trasformare questi elementi in una stima oraria universale e artificiosa. Un generatore di report circoscritto e un agente di coding locale non hanno la stessa copertura dei tool, la stessa logica di approvazione o lo stesso costo di errore. Inserisci nelle formule il costo aziendale effettivo del personale tecnico e il valore di business di ogni esecuzione. In questo modo il team finanziario avrà una base decisionale concreta, non un elenco di funzioni del fornitore.

La parte meno comoda

Il test locale precedente dimostra che fixture e adapter sono coerenti. Non dimostra che un agente reale produrrà lo stesso output per ogni prompt. Per questa prova non erano disponibili credenziali della Gemini API, quindi non ho simulato l’esecuzione dell’agente ospitato. Il controllo finale deve essere una chiamata acquisita dall’agente di settembre in un ambiente usa e getta.

Questo cambiamento, inoltre, non impone lo stesso lavoro a tutti gli utenti di Antigravity:

• Intervieni questa settimana se un job di produzione indica antigravity-preview-05-2026, usa local_environment, analizza i passaggi function_call o viene eseguito senza supervisione secondo una pianificazione.
• Segui il percorso breve se il job viene eseguito in una sandbox remota e utilizza soltanto output_text o model_output. Cambia l’ID ed eseguilo in parallelo.
• Parti direttamente dal nuovo ID se stai ancora valutando l’API e non hai job dell’agente di maggio in produzione.
• Ignora questa migrazione se usi soltanto l’IDE Antigravity e non richiami l’agente gestito tramite la Gemini API.

La prima mossa di lunedì

Assegna a una persona la responsabilità del censimento. Cerca l’ID dell’agente di maggio e i vecchi nomi dei tool nelle configurazioni distribuite, nelle definizioni dei trigger, nelle variabili d’ambiente, nelle dashboard e nelle fixture. Dividi i risultati in due elenchi — solo output e adapter necessario — prima che qualcuno inizi a modificare il codice.

Poi migra un job rappresentativo per ciascun elenco. Mantieni la vecchia pianificazione in pausa ma disponibile mentre controlli l’esecuzione di settembre, sposta i job rimanenti per famiglia di workflow e configura un avviso per le chiamate a tool sconosciuti fino al 5 ottobre. Il risultato da consegnare lunedì non è una presentazione: è un inventario con i responsabili, un’esecuzione in parallelo superata e una data per ogni job ancora da migrare.

Per altre analisi operative in linguaggio semplice sui cambiamenti che possono interrompere workflow reali, iscriviti alla newsletter.