Google Antigravity: cómo migrar trabajos locales antes del 5 de octubre
Google Antigravity cierra el agente de mayo el 5 de octubre. Descubre qué trabajos solo cambian de ID y cuáles requieren adaptar sus herramientas locales.

Los trabajos de Google Antigravity basados en el agente que Google lanzó en mayo tienen apenas 18 días para migrar. Google publicó antigravity-preview-09-2026 el 17 de septiembre de 2026 y, según su calendario de retirada, antigravity-preview-05-2026 dejará de funcionar el 5 de octubre. Si el trabajo ejecuta herramientas en local o lee pasos function_call, no basta con cambiar la versión en una línea: hay que adaptar la integración.
Qué cambia realmente en Google Antigravity
El cambio afecta al agente gestionado Antigravity de la API de Gemini. No es una actualización del IDE Antigravity que se instala en una computadora.
Ambos productos comparten las bases de su entorno de ejecución, de ahí que tengan el mismo nombre. Aquí cambia el ID de agente que la aplicación envía a la API Interactions de Google y, en algunas integraciones, las llamadas a herramientas integradas que debe procesar la propia aplicación. Actualizar el IDE no modifica ese contrato de API.
El nuevo agente es antigravity-preview-09-2026. Su modelo de razonamiento predeterminado es Gemini 3.8 Flash, aunque la guía del agente Antigravity explica cómo seleccionar otro modelo compatible mediante agent_config. El artículo anterior sobre agentes gestionados de Gemini detalla el espacio de trabajo alojado, los trabajos en segundo plano y el ciclo de herramientas. Esta migración ocurre una capa más abajo: determina si esos trabajos podrán seguir iniciándose y si sus llamadas a herramientas continuarán ejecutándose.
Google dividió la migración en dos rutas en la nota de la versión del 17 de septiembre:
- Un trabajo en un entorno aislado remoto que solo lee
output_textomodel_outputcambia la cadena del agente. - Un trabajo que usa
local_environmento interpreta pasosfunction_calltambién debe actualizar su adaptador de herramientas.
Esa distinción define toda la decisión. Un adaptador es el pequeño componente de la aplicación que recibe el nombre y los argumentos de una herramienta, los valida, ejecuta la acción local y devuelve el resultado.
El contrato de herramientas locales cambió en cinco puntos
El agente anterior trataba la mayoría de las operaciones con archivos como lecturas y escrituras generales. El agente de septiembre asigna nombres y argumentos más específicos a esas operaciones. Además, cambia las claves de los argumentos de snake_case a PascalCase.
Cambiaron cinco familias de capacidades relacionadas con archivos y búsquedas. Otras dos herramientas integradas de la lista no cambiaron. Por eso, un controlador genérico construido alrededor de write_file puede fallar aunque el nuevo ID de agente sea correcto.
El nuevo contrato de edición también es más preciso. En vez de devolver un archivo completo para aplicar un cambio pequeño, el agente indica un intervalo de líneas, el texto que espera encontrar y su sustituto. El adaptador debe rechazar la llamada si TargetContent ya no coincide con el archivo. De lo contrario, un trabajo demorado podría sobrescribir una edición humana más reciente.
Qué trabajos requieren una migración de verdad

Un fundador independiente con un trabajo remoto de informes
Pensemos en un trabajo nocturno que pide a Antigravity recopilar datos en el entorno aislado de Google, guardar un informe y devolver el texto final. La aplicación lee output_text y nunca examina los pasos intermedios.
Esta es la migración sencilla. Se cambia antigravity-preview-05-2026 por antigravity-preview-09-2026, se ejecuta un informe representativo en paralelo con el trabajo anterior, se compara el resultado final y después se traslada la programación. No tiene sentido reconstruir un distribuidor de herramientas locales que no existe en esa integración.
Un equipo de plataforma que ejecuta herramientas en sus propias máquinas
Ahora pensemos en un proceso que trabaja sobre un repositorio y cuyas llamadas a herramientas se ejecutan dentro de un runner propio. Lee archivos, busca código, edita configuraciones y devuelve los resultados de las herramientas a la interacción.
Ese equipo afronta la migración más amplia. El distribuidor debe reconocer los nombres nuevos, validar los argumentos en PascalCase, aplicar las políticas de rutas y comandos, realizar de forma segura las ediciones por intervalo de líneas y devolver el resultado en el formato que espera la interacción. El beneficio es la continuidad: las revisiones de código, la generación de informes y los trabajos de mantenimiento seguirán funcionando cuando desaparezca el endpoint de mayo.
Un equipo de observabilidad que consume todos los pasos
Algunas aplicaciones ejecutan todo de forma remota, pero copian los pasos function_call a un registro de auditoría, una interfaz de progreso, una cola de aprobaciones o un panel de costos. Esos equipos no son simples consumidores de la salida.
Aunque Google ejecute la acción integrada sobre el sistema de archivos, el analizador puede seguir esperando write_file, path y content. Hay que actualizar su lista de elementos permitidos y sus fixtures para evitar que el panel marque una edición real como desconocida, descarte sus argumentos o la envíe a una política de aprobación incorrecta.
Un responsable de operaciones con activadores desatendidos
Los activadores programados son el caso de mayor riesgo porque nadie está mirando cuando se realiza la llamada. Un activador vincula un agente, un entorno, un prompt y una programación cron. Si la interacción guardada aún apunta al agente de mayo, la programación puede aparecer sin errores aunque la ejecución que hay detrás falle después del cierre.
Conviene inventariar el ID de agente dentro de cada definición de activador, no solo en la llamada del SDK de la aplicación principal. Después, hay que ejecutar en paralelo un trabajo de cada patrón de herramientas distinto. Un trabajo de informes y otro de reparación de repositorios no constituyen la misma prueba de migración por el mero hecho de usar Antigravity.
Una prueba pequeña para el contrato de edición de archivos
La prueba inicial más segura no requiere credenciales de producción. Basta con pasar al adaptador un fixture con la forma de una llamada capturada, editar un archivo desechable y comprobar que solo cambió la línea prevista.
Ejecuté el siguiente código con Node usando el nombre replace_file_content publicado por Google y campos en PascalCase. Es una prueba local del adaptador, no una llamada real a la API de Gemini.
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");La prueba pasó. Y, lo que es más importante, si se cambia TargetContent en el fixture, se detiene en lugar de editar contenido obsoleto.
Clasificar la integración
Anote si cada trabajo solo consume la salida, interpreta pasos, ejecuta herramientas locales o combina varias de estas funciones. Hágalo por familia de trabajos, no por repositorio.
Capturar fixtures reales
Ejecute el agente de septiembre en una ruta que no sea de producción y guarde pasos
function_callrepresentativos para crear, editar, leer, listar y buscar archivos. Confirme con esas llamadas capturadas la numeración real de las líneas y la estructura de la respuesta antes de llevar la prueba local a producción.Probar la ruta de rechazo
Cambie
TargetContent, dirija una llamada fuera del espacio de trabajo permitido e indique el nombre de una herramienta desconocida. Cada caso debe cerrarse de forma segura y generar un registro de auditoría.Ejecutar en paralelo un trabajo completo
Use el nuevo ID de agente, el adaptador actualizado y un entorno desechable. Antes de cambiar la programación, compare con el trabajo actual el resultado final, la traza de herramientas, las aprobaciones, el tiempo de ejecución y el uso de tokens.
La ecuación de negocio: costo de migrar frente al trabajo perdido
Google no anunció un nuevo precio por token junto con esta migración del agente. La partida presupuestaria que sí cambió es el tiempo de ingeniería y operaciones.
Use dos fórmulas sencillas:
Costo de migración = tiempo de ingeniería del adaptador + gasto de API de las ejecuciones en paralelo + tiempo de supervisión
Exposición a una interrupción = ejecuciones programadas perdidas × valor de una ejecución + trabajo de reparación
En un trabajo remoto que solo consume la salida, el componente de ingeniería puede reducirse a cambiar la cadena del agente y hacer una ejecución en paralelo. Para una integración con herramientas locales, hay que presupuestar cinco familias de capacidades modificadas, fixtures del analizador, pruebas de seguridad y una ejecución completa por cada tipo de flujo de trabajo.
No conviene convertirlo en una estimación universal de horas que no sería real. Un generador de informes de alcance limitado y un agente de programación local no tienen la misma cobertura de herramientas, lógica de aprobación ni costo de fallo. Al introducir en las fórmulas el costo total de la hora de ingeniería y el valor de negocio de cada ejecución, finanzas obtiene una decisión real en lugar de una lista de funciones del proveedor.
La parte que conviene decir sin rodeos
La prueba local anterior demuestra que el fixture y el adaptador coinciden. No demuestra qué emitirá un agente real con cada prompt. Esta ejecución no tenía una credencial de la API de Gemini, así que no fingí ejecutar el agente alojado. La comprobación final debe ser una llamada capturada del agente de septiembre en un entorno desechable.
Tampoco todos los usuarios de Antigravity tienen que hacer el mismo trabajo:
- Actúe esta semana si un trabajo de producción apunta a
antigravity-preview-05-2026, usalocal_environment, interpreta pasosfunction_callo se ejecuta sin supervisión según una programación. - Siga la ruta sencilla si el trabajo se ejecuta en un entorno aislado remoto y solo consume
output_textomodel_output. Cambie el ID y haga una ejecución en paralelo. - Empiece directamente con el ID nuevo si todavía está evaluando la API y no tiene trabajos del agente de mayo en producción.
- Ignore esta migración si solo usa el IDE Antigravity y no llama al agente gestionado mediante la API de Gemini.
Qué hacer el lunes
Asigne a una persona la responsabilidad del inventario. Busque en la configuración desplegada, las definiciones de activadores, las variables de entorno, los paneles y los fixtures tanto el ID del agente de mayo como los nombres antiguos de las herramientas. Divida los resultados en dos listas —trabajos que solo consumen la salida y trabajos que requieren adaptar la integración— antes de que alguien empiece a cambiar código.
Después, migre un trabajo representativo de cada lista. Mantenga la programación anterior en pausa, pero disponible, mientras revisa la ejecución de septiembre; traslade el resto de los trabajos por familia de flujo y configure una alerta para llamadas a herramientas desconocidas hasta el 5 de octubre. El resultado del lunes no es una presentación: es un inventario con responsables, una ejecución en paralelo aprobada y una fecha para cada trabajo pendiente.
Para recibir más notas operativas en lenguaje claro sobre cambios capaces de romper flujos de trabajo reales, suscríbase al boletín.
- Última actualización
- 18 sept 2026
- Categoría
- Explained







