Google substitui o Antigravity Agent 05-2026: o que pode falhar antes da desativação prevista para 5 de outubro

O que o Google anunciou e qual é a data a acompanhar

A documentação da Gemini API registra o lançamento de `antigravity-preview-09-2026` em 17 de setembro de 2026 e o apresenta como substituto de `antigravity-preview-05-2026`, que passa a estar marcado para retirada. A mudança importa sobretudo para equipes que constroem agentes com execução de ferramentas, e não apenas para quem solicita uma resposta textual ao modelo.

A tabela de retiradas do Google aponta 5 de outubro de 2026 como a data mais cedo para a desativação de `antigravity-preview-05-2026` e recomenda a migração para `antigravity-preview-09-2026`. A redação é relevante: a tabela não equivale necessariamente a uma confirmação da hora exata em que a versão deixará de estar disponível para cada conta ou ambiente. O Google indica que comunicará a data exata antecipadamente.

Portanto, a leitura operacional não deve ser que há tempo garantido até o fim daquele dia, mas sim que os testes devem ser concluídos antes dessa referência. Também é recomendável verificar o estado atual da documentação de retiradas imediatamente antes da implantação, caso exista uma atualização, um adiamento ou esclarecimentos de disponibilidade que não constem das informações analisadas.

A substituição, por si só, não demonstra melhoria de qualidade, segurança, custo, latência ou autonomia. As fontes descrevem uma mudança de versão e alterações na interface de ferramentas; elas não fornecem uma comparação experimental entre as duas versões nesses aspectos. Essa distinção evita transformar uma migração de compatibilidade em uma alegação de desempenho não verificada.

Duas rotas de migração conforme a forma de consumir a resposta

O Google diferencia explicitamente um caso de transição simples: um fluxo executado em sandbox remoto que consome apenas `output_text` ou `model_output`. Nessa hipótese, a documentação indica que pode bastar alterar a string que identifica o agente. É uma condição delimitada: ela pressupõe que a aplicação não interprete nem execute por conta própria as chamadas de ferramentas que surjam durante a interação.

O segundo caso reúne as integrações com maior risco de incompatibilidade: agentes que trabalham em um ambiente local, aplicações que recebem ou processam `function_call`, sistemas que reconstroem uma trilha de ações ou plataformas que validam argumentos antes de autorizar uma operação. Nelas, o identificador da versão é apenas uma parte da migração. O consumidor precisa aceitar o contrato de ferramentas da nova versão.

Há também situações intermediárias. Um serviço pode usar ambiente remoto e, ainda assim, armazenar eventos para auditoria, gerar métricas por nome de ferramenta, aplicar políticas de permissões ou executar testes com respostas simuladas. Se algum desses componentes depender de nomes ou argumentos anteriores, ele deve ser tratado como uma integração sensível à trilha, mesmo que o produto final exiba principalmente texto.

Antes de classificar um caso como simples, a equipe deve localizar onde são lidos `output_text`, `model_output`, chamadas de função e resultados de ferramentas. Essa revisão deve incluir adaptadores de SDK, filas de eventos, registros, avaliadores automáticos e painéis internos. A ausência de erros na interface conversacional não comprova que não existam dependências em serviços auxiliares.

Quais mudanças de contrato podem quebrar uma integração

A nota de lançamento descreve mudanças nas ferramentas de sistema de arquivos. Entre elas estão alterações de nome e uma convenção PascalCase para os argumentos documentados. Para um consumidor que compara literais, desserializa com base em um esquema estrito ou deriva permissões a partir dos nomes dos campos, essa modificação pode provocar rejeições mesmo que a solicitação ao agente continue válida.

A edição de arquivos é um ponto específico de quebra. A documentação da nova versão descreve substituições por intervalos de linhas, enquanto a versão anterior utilizava regravações completas. Um executor local que espere receber todo o conteúdo de substituição pode não saber aplicar uma edição delimitada. Por outro lado, transformar uma edição por intervalo em uma regravação total sem controles pode sobrescrever alterações concorrentes ou modificar finais de linha.

A atualização também incorpora ferramentas de busca de arquivos. A presença delas não obriga todas as aplicações a utilizá-las, mas pode afetar listas de ferramentas permitidas, mecanismos de autorização e mocks que contemplem somente as operações existentes na versão anterior. Um sistema que negue por padrão uma ferramenta desconhecida pode interromper uma tarefa que antes era concluída com outra sequência de ações.

Os nomes exatos e a capitalização não devem ser inferidos a partir de exemplos antigos nem normalizados sem teste. O guia técnico atual apresenta as ferramentas de filesystem como chamadas de função. Em uma integração local, o contrato deve ser revisado de ponta a ponta: evento recebido, validação, autorização, execução, serialização do resultado e retomada da interação.

Testes para detectar falhas que uma resposta textual não revela

O teste mais útil não é perguntar ao agente se ele consegue realizar uma tarefa, mas executar tarefas representativas e revisar cada etapa. Uma suíte mínima deve conter criação de arquivos, leitura de conteúdo, listagem de diretórios, edição localizada e busca. Se o produto permitir modificações, acrescente casos de permissões insuficientes, caminhos inválidos, arquivos ausentes e conflitos de edição. Os resultados esperados devem abranger tanto a saída para o usuário quanto os eventos e o estado final do ambiente.

Capture trilhas de uma amostra equivalente com as duas versões, quando o ambiente de testes permitir. Não se trata de exigir que a sequência seja idêntica: as novas ferramentas podem fazer com que ela mude. O objetivo é verificar se o adaptador consegue interpretar e executar toda chamada autorizada, se os resultados retornam ao agente no formato esperado e se a tarefa chega a um estado correto.

Os mocks merecem uma revisão separada. Eles costumam codificar o contrato anterior de forma implícita: nomes de função, maiúsculas e minúsculas dos campos, estrutura dos argumentos ou o conteúdo completo de um arquivo. Um mock que ainda aceite somente o contrato antigo pode ocultar falhas; um mock permissivo demais pode aprovar chamadas que o executor real rejeitará. É recomendável derivar as simulações de trilhas capturadas e manter casos negativos.

A instrumentação deve registrar a versão solicitada, o tipo de ambiente, as chamadas recebidas, a decisão de autorização e o resultado da execução, evitando armazenar conteúdo sensível desnecessariamente. Essas informações permitem distinguir um problema de contrato de uma negação de permissão, uma falha do ambiente ou uma resposta inesperada do modelo.

Custo, disponibilidade e limites do que se pode concluir

A documentação de preços da Gemini Developer API indica que o Antigravity Agent cobra pela inferência, incluindo os tokens intermediários dos loops agênticos, de acordo com as tarifas padrão do Gemini. Também informa que, durante a prévia, a computação do ambiente não é cobrada. Isso não permite calcular o custo de uma carga de trabalho específica: ele dependerá dos modelos, do volume de tokens, da duração e do comportamento efetivo das tarefas.

Também não se deve extrapolar essas informações para canais de acesso que as fontes fornecidas não descrevem como equivalentes. As informações analisadas se referem à Gemini API e não demonstram que disponibilidade, cotas, condições de uso ou cronograma sejam idênticos no Vertex AI ou em outras vias. Equipes com uma camada de abstração multicanal devem confirmar o provedor real de cada implantação antes de aplicar esta notícia como regra geral.

A documentação analisada permite concluir que existe uma rota de mudança simples para um caso remoto muito específico e que há modificações de interface relevantes para consumidores de ferramentas. Ela não permite concluir que todos os agentes remotos sejam imunes à mudança, que uma migração local seja mecânica ou que as duas versões forneçam resultados funcionalmente equivalentes em todas as tarefas.

Como medida de serviço, a prioridade é tratar essa substituição como uma migração de contrato. Alterar o nome da versão pode ser suficiente quando se consome somente a saída textual no cenário remoto descrito pelo Google. Em qualquer integração que observe, valide ou execute ferramentas, a decisão deve se basear em trilhas e testes de regressão, não na aparente continuidade da conversa.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.