Google Antigravity: migre os jobs locais até 5 de outubro

O que muda no Google Antigravity

A mudança afeta o agente gerenciado Antigravity da Gemini API. Não se trata de uma atualização do IDE Antigravity instalado no computador.

Os dois produtos compartilham a mesma base de runtime, daí a sobreposição no nome. O que muda aqui é o ID de agente enviado pela aplicação à Interactions API do Google e, em algumas integrações, as chamadas de ferramentas nativas tratadas pela aplicação. Atualizar o IDE não altera esse contrato de API.

O novo agente é o antigravity-preview-09-2026. Seu modelo de raciocínio padrão é o Gemini 3.8 Flash, embora o guia do Antigravity Agent mostre como selecionar outro modelo compatível por meio de agent_config. O artigo anterior sobre Gemini Managed Agents explica o workspace hospedado, os jobs em segundo plano e o loop de ferramentas. Esta migração acontece uma camada abaixo: ela determina se esses jobs ainda conseguem iniciar e se suas chamadas de ferramentas continuam funcionando.

Na nota de versão de 17 de setembro, o Google separou a migração em dois caminhos:

• Um job em sandbox remota que lê apenas output_text ou model_output precisa trocar a string do agente.
• Um job que usa local_environment ou processa etapas function_call também precisa atualizar o adaptador de ferramentas.

Essa distinção define todo o trabalho. O adaptador é a pequena camada de código da aplicação que recebe o nome e os argumentos de uma ferramenta, faz as validações, executa a ação local e devolve o resultado.

O contrato das ferramentas locais mudou em cinco pontos

O agente antigo tratava grande parte das operações com arquivos como leituras e gravações amplas. O agente de setembro adota nomes e argumentos mais específicos. As chaves dos argumentos também deixam snake_case e passam a PascalCase.

Cinco famílias de recursos de arquivos e busca mudaram. Duas ferramentas nativas da lista permaneceram iguais. Por isso, um handler genérico montado em torno de write_file pode falhar mesmo quando o novo ID do agente está correto.

O novo contrato de edição também é mais preciso. Em vez de devolver o arquivo inteiro para uma pequena alteração, o agente informa o intervalo de linhas, o texto que espera encontrar e o conteúdo substituto. O adaptador deve recusar a chamada quando TargetContent já não corresponder ao arquivo. Caso contrário, um job atrasado pode sobrescrever uma edição humana mais recente.

Quais jobs realmente exigem uma migração

Um fundador solo com um job remoto de relatório

Imagine um job noturno que pede ao Antigravity para coletar dados na sandbox do Google, salvar um relatório e devolver o texto final. A aplicação lê output_text e não inspeciona as etapas internas.

Esse é o caminho curto. Troque antigravity-preview-05-2026 por antigravity-preview-09-2026, execute um relatório representativo em paralelo ao job antigo, compare o artefato final e só então mova o agendamento. Não há motivo para reconstruir um dispatcher de ferramentas locais que não existe nessa integração.

Uma equipe de plataforma que executa ferramentas na própria infraestrutura

Agora pense em um worker de repositório cujas chamadas de ferramentas rodam no runner da própria equipe. Ele lê arquivos, pesquisa código, edita configurações e envia os resultados das ferramentas de volta à interação.

Essa equipe é responsável pela migração maior. O dispatcher precisa reconhecer os novos nomes, validar os argumentos em PascalCase, aplicar as políticas de caminhos e comandos, executar edições por intervalo de linhas com segurança e devolver o resultado no formato esperado pela interação. O benefício é a continuidade: revisões de código, geração de relatórios e jobs de manutenção continuam funcionando depois que o endpoint de maio desaparecer.

Uma equipe de observabilidade que consome todas as etapas

Algumas aplicações executam tudo remotamente, mas ainda copiam as etapas function_call para um log de auditoria, uma interface de progresso, uma fila de aprovação ou um painel de custos. Essas equipes não são consumidoras apenas da saída.

Mesmo quando o Google executa a ação nativa no sistema de arquivos, o parser pode continuar pressupondo write_file, path e content. Atualize a lista de permissões e as fixtures para que o painel não marque uma edição real como desconhecida, descarte seus argumentos ou a encaminhe para a política de aprovação errada.

Um responsável por operações com gatilhos autônomos

Gatilhos agendados representam o maior risco porque ninguém acompanha a chamada no momento da execução. Um gatilho vincula agente, ambiente, prompt e agendamento cron. Se a interação armazenada ainda apontar para o agente de maio, o agendamento pode parecer saudável enquanto a execução por trás dele falha após o desligamento.

Faça o inventário do ID do agente dentro de cada definição de gatilho, não apenas na chamada do SDK da aplicação principal. Depois, execute em paralelo um job de cada padrão de ferramentas. Um job de relatórios e outro de reparo de repositório não constituem o mesmo teste de migração só porque ambos usam o Antigravity.

Um teste enxuto para o contrato de edição de arquivos

O primeiro teste mais seguro não depende de credenciais de produção. Envie ao adaptador uma fixture capturada no formato de uma chamada, edite um arquivo descartável e confirme que somente a linha pretendida mudou.

Executei o código abaixo com Node usando o nome replace_file_content publicado pelo Google e os campos em PascalCase. É um teste local do adaptador, não uma chamada ativa à 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");

O teste passou. Mais importante: ao alterar o TargetContent da fixture, ele interrompe a execução em vez de editar conteúdo desatualizado.

A conta de negócio compara o trabalho de migração com as execuções perdidas

O Google não anunciou um novo preço por token com esta migração de agente. A linha do orçamento que mudou é o tempo de engenharia e operações.

Use duas fórmulas simples:

Para um job remoto que consome apenas a saída, o esforço de engenharia pode se resumir à troca da string do agente e a uma execução em paralelo. Em uma integração com ferramentas locais, reserve orçamento para as cinco famílias de recursos alteradas, as fixtures do parser, os testes de segurança e uma execução completa de cada formato distinto de workflow.

Não transforme isso em uma estimativa universal de horas sem fundamento. Um gerador de relatórios enxuto e um agente de programação local têm coberturas de ferramentas, lógicas de aprovação e custos de falha diferentes. Aplique às fórmulas a taxa integral da sua equipe de engenharia e o valor de negócio de cada execução. Assim, a área financeira recebe uma decisão concreta, não uma lista de recursos do fornecedor.

A parte que precisa ser dita com clareza

O teste local acima comprova que a fixture e o adaptador estão de acordo. Ele não demonstra o que um agente ativo emitirá para todos os prompts. Esta apuração não tinha uma credencial da Gemini API, portanto não simulou a execução do agente hospedado. A validação final deve usar uma chamada capturada do agente de setembro em um ambiente descartável.

Nem todo usuário do Antigravity precisa fazer o mesmo trabalho diante dessa mudança:

• Aja nesta semana se um job de produção aponta para antigravity-preview-05-2026, usa local_environment, processa etapas function_call ou roda de forma autônoma em um agendamento.
• Siga o caminho curto se o job roda em uma sandbox remota e consome apenas output_text ou model_output. Troque o ID e faça uma execução em paralelo.
• Comece direto no novo ID se a API ainda está em avaliação e não há jobs do agente de maio em produção.
• Ignore esta migração se você usa apenas o IDE Antigravity e não chama o agente gerenciado pela Gemini API.

O que fazer na segunda-feira

Dê a uma pessoa a responsabilidade pelo inventário. Procure o ID do agente de maio e os nomes antigos das ferramentas nas configurações implantadas, definições de gatilhos, variáveis de ambiente, painéis e fixtures. Separe os resultados em duas listas — apenas saída e adaptador obrigatório — antes de qualquer alteração no código.

Depois, migre um job representativo de cada lista. Mantenha o agendamento antigo pausado, mas disponível, enquanto analisa a execução de setembro; mova os jobs restantes por família de workflow; e configure um alerta para chamadas de ferramentas desconhecidas até 5 de outubro. A entrega de segunda-feira não é uma apresentação. É um inventário com responsáveis, uma execução paralela aprovada e uma data para cada job restante.

Para receber mais análises operacionais, em linguagem direta, sobre mudanças que podem interromper workflows reais, assine a newsletter.