Google just shipped Antigravity 2.0, and the naming makes it sound like a patch. It is not a patch. It is a separate desktop app on macOS, Linux, and Windows, rebuilt so agents are the product, not a panel bolted onto an IDE.
I've been waiting for someone to admit that "agent manager inside the editor" was a transitional UI. Antigravity 2.0 is Google saying that out loud.
What shipped
From Google's product blog and the I/O developer notes, here's the concrete feature set:
- Standalone desktop app: no IDE required. You talk to agents, review artifacts, steer outcomes.
- Dynamic subagents: the main agent spins up focused workers for parallel subtasks so it doesn't trash its own context window.
- Scheduled tasks: cron-style triggers that start agents in the background without you prompting every time.
- Projects, not just repos: a project can span multiple folders with its own settings and permissions.
- Voice with live transcription: speak prompts; text appears as you talk.
- Slash commands:
/goal,/grill-me,/schedule,/browserfor common control patterns. - JSON hooks: intercept and control agent behavior with simple hook configs.
- CLI + SDK: terminal surface and APIs to build/deploy custom agents.
- Ecosystem hooks: Google AI Studio export in one click, Workspace APIs, Android and Firebase integrations.
Powering a lot of this is Gemini 3.5 Flash (with later model drops into the same harness). Google's pitch is co-optimization: product, harness, and model trained as one stack.
| Role | Job |
|---|---|
| Main agent | Holds the goal, fans out work, merges artifacts |
| Subagent A | Focused research or docs/MCP pull |
| Subagent B | Scaffold or implement against a locked interface |
| Subagent C | Tests, snapshots, or review notes |
Parallelism without a shared spec is how you get four conflicting implementations of the same button.
Why Google split it from the IDE
When Antigravity IDE launched in late 2025, the Agent Manager was the interesting part. The code editor was familiar comfort food. Millions of developers tried the agent-first surface.
But Google hit three ceilings:
- Agent value expands past coding into knowledge work. An IDE-shaped shell scares non-engineers.
- Shipping agent UX and editor UX in one binary creates confusing mental models.
- The harness and Gemini models need to co-evolve without being tied to "repository" as the atomic unit.
So 2.0 is agent-first from scratch. The old Antigravity IDE still exists for now. Google recommends dual-wielding: Antigravity 2.0 for orchestration, your IDE of choice for hands-on editing. Eventually the Agent Manager leaves the IDE entirely.
That dual-wield advice is the honest part. Pure agent apps still need somewhere for humans to read diffs carefully.
How I'd use it on real work
If I were putting this on a client project tomorrow, I wouldn't start with "rewrite the whole app." I'd pick workflows where parallelism is obvious:
- Research + implement: one subagent reads docs/MCP sources while another scaffolds code against a locked interface.
- Nightly maintenance: scheduled tasks that open dependency PRs, regenerate snapshots, or re-run flaky eval suites.
- Multi-folder projects: marketing site + API + shared package under one project with scoped permissions.
- Grill-me before build:
/grill-meforces clarifying questions. That alone would save teams from vibe-coding half a spec.
The danger is the same as every multi-agent demo: five agents confidently doing the wrong thing in parallel. Parallelism amplifies bad specs. Spec quality becomes the bottleneck, which is why tools like GitHub Spec Kit are having a moment.
| Trigger | Agent action | Human gate |
|---|---|---|
Cron / /schedule | Start background agent on a project | Review artifacts before merge |
Manual /goal | Orchestrate live subagents | Steer when context drifts |
| Hook config | Intercept tool calls | Block writes outside scope |
What to test before you trust it
Skip the wow demos. Run these:
- Give a high-level goal that needs two independent subsystems. Watch whether subagents actually isolate context or just spam duplicate work.
- Schedule a task overnight on a throwaway repo. Check logs, permissions, and whether it waited for approval when it shouldn't have write access.
- Export a Google AI Studio prototype into Antigravity. Measure how much context survives the hop.
- Try
/grill-meon an ambiguous product ask. If it doesn't ask about auth, data ownership, and failure modes, the prompt pack needs work.
Also check enterprise controls. "Available to enterprises" is not the same as "ready for your SOC2 boundary." Hook configs and project permissions need a security review before production credentials enter the chat.
The market context
Cursor, Claude Code, Codex, Gemini CLI, and now Antigravity 2.0 are all converging on the same idea: one human director, many specialized workers, shared artifacts. The differentiator is shifting from "can the model write code" to "can the harness keep long jobs coherent without babysitting."
Google's edge is distribution plus Gemini co-training plus Workspace/Firebase gravity. Their risk is product sprawl. Desktop app, IDE, CLI, SDK, AI Studio, Managed Agents in the Gemini API. Teams will get lost choosing a surface.
My rule of thumb: pick one orchestration surface and one editing surface. Don't collect agent apps like sneakers.
Bottom line
Antigravity 2.0 is the clearest signal yet that agent UX is leaving the IDE. If you build applied AI systems, study the harness patterns: dynamic subagents, scheduled invocation, project-scoped permissions, human review of artifacts.
The model is important. The control plane is where products win or burn money.
If you're designing an agent workflow for ops or product and want help choosing the harness (and what not to automate yet), book a free discovery call.