Antigravity Agent 09-2026: migrate local tool schemas before October 5

Quick answer

Google released antigravity-preview-09-2026 on September 17, replacing and deprecating antigravity-preview-05-2026. The older preview is scheduled to shut down on October 5, 2026. If your client uses a remote sandbox and reads only output_text or model_output, Google's release notes say changing the agent string is sufficient. If you execute tools through local_environment or parse function_call steps, changing the ID alone is unsafe: built-in tool names, argument casing, and file-edit semantics changed.

This is an agent preview migration, not an announcement that a new Gemini foundation model or the Antigravity Agent has reached general availability. The practical task is to classify your integration, adapt the actual tool contract where needed, and run file-operation canaries before the shutdown.

Who this is for

This guide is for developers using Google's Antigravity managed agent through the Gemini Interactions API, especially teams that host tools locally, record function calls, or transform agent steps into their own event format. If you merely display remote-sandbox output, start with the short path below. If a gateway, logger, replay harness, or approval layer looks inside function_call, treat it as a parser even if execution remains remote.

Our earlier Gemini 3.8 Flash and Antigravity cost checklist covers agent-selection and cost controls. This page is specifically about the September tool-schema break and October 5 cutoff.

What changed—and what did not

Google's September 17 release notes distinguish the remote-output-only case from local tool hosts and step parsers. In the latter two cases, the new built-in tools use PascalCase argument names. File editing shifts from rewriting a whole file to replacing a line range. A byte-offset read in the old integration must not be blindly translated into line numbers.

Task	Old 05-2026 contract	New 09-2026 contract	Adapter check
Create file	write_file(path, content)	write_to_file(TargetFile, CodeContent, Overwrite, Description)	Explicitly decide overwrite behavior
Edit file	write_file(path, content); full rewrite	replace_file_content(TargetFile, StartLine, EndLine, TargetContent, ReplacementContent)	Validate range and expected target before mutation
Read file	read_file(path, offset, limit); byte offsets	view_file(AbsolutePath, StartLine, EndLine, ContentOffset)	Recheck Unicode, line endings, and offsets
List directory	list_files(path)	list_dir(DirectoryPath)	Map the path key and result parser
Find or search	Previously shell-based	find_by_name(...), grep_search(...)	Allow and log new built-in names
Shell or web	code_execution, google_search	Names unchanged	Confirm they still pass through policy

The exact parameter lists above come from Google's release notes. The “adapter check” column is our proposed validation, not a promise about how your application behaves. Consult the Antigravity Agent guide for current request and response examples before editing production code.

Pick the smallest migration path

1. Remote sandbox; output-only reader. Confirm environment: "remote" and that your code consumes only output_text or model_output. Change the agent ID, then run a representative task and compare the returned output. Do not claim this shortcut if analytics or middleware also parses tool steps.
2. Remote sandbox; step parser. Keep remote execution, but update the parser and any stored event schema for new function_call names and PascalCase arguments. Test a recorded create, read, and edit sequence. A UI that renders final text correctly can still hide a broken audit trail.
3. Local tool host. Add or update dispatch handlers for the new names and arguments. Keep tool permission checks and human approval on the new dispatch path. Do not alias every new edit to the old full-file writer: that discards the line-range precondition that now matters.
4. Mixed or uncertain. Search code and logs for local_environment, function_call, write_file, read_file, and list_files. Classify each caller. If you cannot establish that every consumer is output-only, use the parser/local checklist rather than assuming the short path.

Five canaries before cutover

Use disposable files in a sandbox or test repository; the following is a test design, not a claim that IndieSeek ran a live Antigravity API evaluation.

Canary	Fixture and expected evidence
Create	Ask the agent to create a new file. Capture write_to_file arguments and confirm the intended path, content, overwrite policy, and final file diff.
Targeted edit	Seed a file with lines above and below the edit. Confirm replace_file_content changes only the intended range; reject a stale target or unexpected diff.
Read	Include multibyte characters and mixed line endings. Confirm view_file returns the expected region; do not reuse old byte offsets as line numbers.
Discover	Ask for one filename and one text match. Verify find_by_name and grep_search are permitted, recorded, and correctly rendered.
Unchanged controls	Run a benign shell operation and a web-search task where your policy allows them. Confirm code_execution and google_search still follow the same approval boundary.

For each canary, save the requested agent ID, environment mode, observed function name and arguments, approval decision, file diff or returned data, and pass/fail result. Promote only when both the final answer and the tool trace satisfy your acceptance criteria. If the new preview fails a critical fixture, hold the workflow and investigate before October 5; do not assume the old preview remains available afterward.

Copyable migration receipt

checked_at: 2026-09-__
old_agent: antigravity-preview-05-2026
new_agent: antigravity-preview-09-2026
environment: remote | local_environment
output_only: yes | no
function_call_consumers: 
dispatch_and_policy_updated: yes | no | not_applicable
create_edit_read_discover_controls: pass | fail | not_used
unexpected_file_diff: yes | no
decision: promote | hold
owner: 

Common mistakes

• Treating a successful final response as proof that local tool dispatch, approvals, and logs still work.
• Renaming write_file but retaining full-file rewrite behavior for an edit that now carries range and target fields.
• Converting byte offsets to line numbers without checking Unicode and line-ending behavior.
• Calling the new preview “GA,” or confusing the agent ID with a Gemini model ID.
• Waiting until October 5 to test rollback and then assuming the deprecated preview can still be called.

Building something? Turn your product page into a show people want to watch with PromoFast—hosted, embeddable, and ready to export.

FAQ

Do remote-sandbox clients need a tool adapter?

Not if they truly read only output_text or model_output; Google's release notes say the agent-string update is enough for that case. Any client parsing function_call belongs on the fuller migration path.

Is October 5 the retirement date for the new preview?

No. Google's deprecations page schedules antigravity-preview-05-2026 to shut down October 5. The replacement is antigravity-preview-09-2026.

Can I use the old file writer as a compatibility shim?

Only after a deliberate safety review. The new edit contract includes line-range and target-content fields; blindly converting it to a full rewrite can overwrite unrelated changes. Validate the exact target and diff instead.

Sources

• Google Gemini API release notes, September 17, 2026
• Google Antigravity Agent guide
• Google Gemini deprecations

Originally published on IndieSeek.