How Antigravity Works

Google Antigravity is an agent-first dev platform: the editor, terminal, and browser live inside the agent, and you supervise several agents like an architect. Launched in public preview 18 Nov 2025 with Gemini 3, built by the Windsurf team; a modified VS Code fork.

The inversion

• Traditional AI IDE: model embedded in a surface (completion, chat panel).
• Agent-first: surfaces embedded in the agent; agents plan, execute, and verify across editor, terminal, and browser.
• Two modes: Editor View (familiar AI IDE) and Manager Surface (agent-first console to spawn/supervise agents).
• The human’s job shifts from typing to reviewing.

   AI IDE:  Editor --> AI plugin (sidebar)
Antigravity: Agent --> Editor + Terminal + Browser

Agent Manager (mission control)

• Spawn, orchestrate, and observe multiple agents working asynchronously across workspaces.
• Workspace = bounded context (directory, repo, project). One agent per workspace; multiple agents in one directory interfere.
• Inbox = single queue consolidating all agents’ notifications and approval requests.
• Run modes: Local Mode (active folder) or New Worktree Mode (isolated Git worktree); both inside project folder boundaries.
• “Up to 5 agents” is reported, not official.
• Fan-out is only useful if a human can supervise without drowning: Inbox (one queue) + worktrees (no collisions).

Artifacts (the unit of trust)

• Artifact = structured deliverable the agent creates to do its task and communicate progress/thinking.
• Types: Implementation Plans (Markdown), task lists, walkthroughs, code diffs, architecture diagrams, screenshots, browser recordings.
• Review high-level deliverables at milestones instead of raw logs; Artifacts act as reviewable receipts.
• Google-Docs-style inline feedback; agent incorporates it mid-execution.
• “Asks for Review” pauses the agent at that milestone until you approve.

Three surfaces and self-verification

• Agents operate across editor, terminal, and browser at once. The browser is the differentiator.
• Browser Subagent (browser_subagent tool): opens/reads/actuates a local Chrome, navigates URLs, uses multiple tabs, captures screenshots and action videos as Artifacts.
• Verify loop: write code → npm run dev → open in browser → click flow → catch defect → patch → re-verify, attaching the recording as proof.
• The screenshot is the ground-truth signal that closes the loop; one mechanism verifies and proves.

Autonomy dial and models

• Slash commands: /goal runs to completion, /grill-me asks clarifying questions first, /schedule runs on a timer/recurring. Review gating is per-Artifact (“Asks for Review”).
• Four tenets: Trust, Autonomy, Feedback, Self-improvement (agents keep a knowledge base of “knowledge items”).
• Posture: autonomy is a dial, not a switch. Start review-required; keep destructive terminal ops gated.
• Models: generous limits on Gemini 3 Pro (flagship, 1M-token context, 54.2% Terminal-Bench 2.0, top of WebDev Arena), plus Claude Sonnet 4.5 and GPT-OSS.

Evidence tags

The security edge (same feature, both jobs)

• The browser subagent that verifies your app is the same capability used within a week of launch to demonstrate data exfiltration.
• Documented attack: poisoned page with hidden 1-point-font instructions → agent uses run_command to cat a .env → browser navigates to webhook.site (on the default allowlist) with AWS creds in the URL → secrets leaked.
• This is indirect prompt injection: no built-in wall between content the agent reads and instructions it follows. Prompt-level mitigations are not controls.
• Real controls are structural: keep credentials out of the agent’s reach, tighten the network allowlist, gate destructive shell commands behind human review. Isolation primitives: separate Chrome profile, allowlist/denylist, worktrees, folder boundaries.
• Gotcha: the exfiltration worked because a broad default allowlist left the egress leg open. Remove the capability; don’t ask the model nicely.