Google Antigravity is not one thing for integration purposes.
Google documents a product family: Antigravity 2.0, Antigravity CLI, Antigravity SDK, Antigravity IDE, and the Gemini API Antigravity agent. Those surfaces share ideas, but they are not interchangeable contracts for AIWG.
AIWG now has experimental support for Google Antigravity CLI. The provider id is antigravity, and agy is accepted as the alias because agy is Google's CLI executable name.
That naming choice is deliberate. antigravity is the durable AIWG provider identity. agy is the executable and convenience selector. Receipts and persisted provider state should use antigravity.
What Google Antigravity is
Google introduced Antigravity as an agentic development platform for software development. The original launch post described an agent-first product form with browser control, asynchronous interaction patterns, artifacts, and multiple surfaces for planning, executing, and verifying software work.
The current docs split the family into several surfaces. Antigravity 2.0 is the desktop command center. Antigravity CLI is the terminal-first surface. Antigravity SDK is a programmatic Python framework. Antigravity IDE is the fully featured AI-powered developer environment. Google also publishes Gemini API docs for a managed Antigravity agent.
AIWG's first support point is narrower than that family. It targets Antigravity CLI: the agy command and the project-scoped resources the CLI can read.
The provider boundary
For AIWG, the useful announcement is not "Google has a new agent tool." The useful announcement is this:
AIWG can carry governed workflow material into Antigravity CLI without taking ownership of Antigravity installation, authentication, model selection, sandbox policy, permission settings, sessions, or runtime execution.
Preview before writing:
aiwg use sdlc --provider antigravity --dry-run
Then deploy and inspect:
aiwg use sdlc --provider antigravity
aiwg doctor --provider antigravity
aiwg steward capabilities --provider antigravity
The alias works too:
aiwg use sdlc --provider agy --dry-run
Use the full antigravity id in docs, receipts, and durable examples. Use agy when the point is the executable or a short selector.
What AIWG deploys
AIWG's Antigravity provider is project-scoped today.
The integration maps AIWG agent resources into .agents/agents/ and workspace skills into .agents/skills/. It creates or refreshes project context through the Antigravity-specific AGENTS.md template. MCP injection uses Antigravity's documented mcpServers structure and the remote serverUrl key.
The provider refuses undocumented global skill deployment. That is not a missing marketing bullet; it is the safer implementation choice. The local AIWG assessment found conflicting Google documentation for global skill paths, so initial support stays with workspace skills until that behavior is version-pinned and tested.
What AIWG does not do
AIWG does not install Google Antigravity. It does not sign in to the CLI. It does not write model credentials. It does not choose Gemini, Claude, GPT-OSS, or any other model inside Antigravity. It does not change Antigravity permission settings. It does not treat Google's sandbox decisions as AIWG settings.
Authenticated model execution has not been qualified for this provider announcement. The support claim is narrower: offline conformance is pinned to a local Antigravity CLI 1.1.26 observation, and normal CI uses sanitized fixtures for JSON and stream JSON behavior.
That boundary protects both sides. AIWG owns the provider adapter and its generated files. Google Antigravity owns its runtime, account, model, permission, and product behavior. The operator owns whether to install, authenticate, run, approve, and trust that environment.
Why the version note matters
Google's public docs are moving. During preparation, official docs navigation listed Antigravity CLI v1.1.25, while the local binary observed for AIWG qualification reported 1.1.26.
That is a normal kind of drift for a fast-moving tool, but it affects support language. The campaign should not say "latest" or imply universal runtime qualification. It should say exactly what was tested and when.
For now, the accurate statement is:
AIWG has an experimental Antigravity CLI provider integration. Offline conformance is pinned to local CLI 1.1.26 observation. Authenticated model execution is outside the current qualification claim.
Why this matters
Provider portability is usually hardest at the places that look small: file paths, selectors, permission defaults, MCP shape, session behavior, and which component owns execution.
Antigravity makes that especially important because Google's product family spans desktop, CLI, SDK, IDE, and API-hosted agent surfaces. A good adapter cannot collapse those into one vague "Google Antigravity" claim.
AIWG's job is to make the target explicit. For this launch, the target is Antigravity CLI. The resource deployment is project-scoped. The selector is antigravity, with agy as the executable alias. Global skills stay out of scope until the path conflict is resolved. Runtime auth and model execution stay operator-owned.
That is the value: useful portability with the support boundary still visible.
Connect and verify
Start with the Google Antigravity docs and the AIWG Antigravity provider guide once the release branch is public. Then run the dry-run:
aiwg use sdlc --provider antigravity --dry-run
If the provider plan looks right, deploy intentionally and verify:
aiwg use sdlc --provider antigravity
aiwg doctor --provider antigravity
aiwg steward capabilities --provider antigravity
Then tell us where the provider boundary needs the most pressure testing: workspace skills, custom agents, MCP injection, headless output parsing, or the handoff between Antigravity's own permissions and AIWG-owned resources.