Antigravity Local Jobs Need an October 5 Migration

What this change actually is

This is about the Antigravity managed agent in the Gemini API. It is not an update to the Antigravity IDE you install on a computer.

The products share runtime foundations, which explains the name overlap. The thing changing here is the agent ID your application sends to Google's Interactions API and, for some integrations, the built-in tool calls your application handles. Updating an IDE does not update that API contract for you.

The new agent is antigravity-preview-09-2026. Its default reasoning model is Gemini 3.8 Flash, though the Antigravity Agent guide shows how an application can select another supported model through agent_config. The earlier Gemini Managed Agents explainer covers the hosted workspace, background jobs, and tool loop. This migration sits one layer lower: it decides whether those jobs can still start and whether their tool calls can still execute.

Google split the migration into two paths in the September 17 release note:

• A remote sandbox job that reads only output_text or model_output changes the agent string.
• A job that uses local_environment or parses function_call steps must also update its tool adapter.

That split is the whole decision. An adapter is the small piece of application code that receives a tool name and arguments, validates them, runs the local action, and returns the result.

The local tool contract changed in five places

The old agent mostly treated file work as broad reads and writes. The September agent gives file operations narrower names and arguments. It also changes argument keys from snake_case to PascalCase.

Five file and search capability families changed. Two listed built-ins stayed the same. That is why a catch-all handler built around write_file can fail even when the new agent ID is correct.

The new edit contract is also more precise. Instead of sending an entire file back for a small change, the agent names a line range, the text it expects there, and the replacement. Your adapter should reject the call when TargetContent no longer matches the file. Otherwise, a delayed job can overwrite a newer human edit.

Which jobs need real migration work

A solo founder with a remote report job

Suppose a nightly job asks Antigravity to collect data in Google's sandbox, save a report, and return the final text. Your application reads output_text and never inspects the steps underneath.

That is the small migration. Change antigravity-preview-05-2026 to antigravity-preview-09-2026, run one representative report beside the old job, compare the final artifact, then move the schedule. There is no reason to rebuild a local tool dispatcher you do not have.

A platform team running tools on its own machines

Now take a repository worker whose tool calls execute inside your own runner. It reads files, searches code, edits configuration, and sends tool results back to the interaction.

That team owns the larger migration. The dispatcher must recognize the new names, validate PascalCase arguments, enforce path and command policy, apply line-range edits safely, and return the result format the interaction expects. The payoff is continuity: code reviews, report generation, and maintenance jobs keep running after the May endpoint disappears.

An observability team that consumes every step

Some applications run everything remotely but still copy function_call steps into an audit log, progress UI, approval queue, or cost dashboard. Those teams are not output-only consumers.

Even if Google executes the built-in filesystem action, your parser may still assume write_file, path, and content. Update its allowlist and fixtures so the dashboard does not label a real edit as unknown, drop its arguments, or route it to the wrong approval policy.

An operations owner with unattended triggers

Scheduled triggers are the highest-risk case because no person is watching when the call fires. A trigger binds an agent, environment, prompt, and cron schedule. If the stored interaction still names the May agent, the schedule can be healthy while the execution behind it fails after shutdown.

Inventory the agent ID inside every trigger definition, not just the SDK call in your main application. Then shadow-run one job from each distinct tool pattern. A reporting job and a repository repair job are not the same migration test just because both use Antigravity.

A small file-edit contract test

The safest first test does not need production credentials. Feed your adapter a captured call-shaped fixture, edit a disposable file, and assert that only the intended line changed.

I ran the following with Node using Google's published replace_file_content name and PascalCase fields. It is a local adapter test, not a live Gemini API call.

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");

The test passed. More important, changing the fixture's TargetContent makes it stop instead of editing stale content.

The business math is migration labor versus missed work

Google did not announce a new per-token price with this agent migration. The budget line that changed is engineering and operations time.

Use two plain formulas:

For an output-only remote job, the engineering term can be an agent-string change plus one shadow run. For a local-tool integration, budget for five changed capability families, parser fixtures, safety tests, and one complete run for each distinct workflow shape.

Do not turn that into a fake universal hour estimate. A narrow report generator and a local coding agent have different tool coverage, approval logic, and failure cost. Put your own loaded engineering rate and per-run business value into the formulas. That gives finance a real decision instead of a vendor feature list.

The honest part

The local test above proves the fixture and adapter agree. It does not prove what a live agent will emit for every prompt. This run did not have a Gemini API credential, so I did not pretend to execute the hosted agent. Your final gate is a captured September-agent call in a disposable environment.

This event also does not require every Antigravity user to do the same work:

• Act this week if a production job names antigravity-preview-05-2026, uses local_environment, parses function_call steps, or runs unattended on a schedule.
• Use the small path if the job runs in a remote sandbox and consumes only output_text or model_output. Change the ID and shadow-run it.
• Start clean on the new ID if you are still evaluating the API and have no May-agent jobs in production.
• Ignore this migration if you only use the Antigravity IDE and do not call the managed agent through the Gemini API.

Your Monday move

Give one person ownership of the inventory. Search deployed configuration, trigger definitions, environment variables, dashboards, and fixtures for the May agent ID and the old tool names. Split the results into output-only and adapter-required lists before anyone starts changing code.

Then migrate one representative job from each list. Keep the old schedule paused but available while you inspect the September run, move the remaining jobs by workflow family, and put an alert on unknown tool calls through October 5. The Monday deliverable is not a slide. It is an inventory with owners, a passing shadow run, and a date for every remaining job.

For more plain-English operator notes on changes that can break real workflows, join the newsletter.