How the Antigravity browser actually works

A plan-execute-review loop, wrapped around a real Chromium engine and a real local workspace.

Antigravity is not a wrapper around a chat model. The product ships as a native desktop application that embeds a full Chromium engine, a local file workspace, and a task orchestrator capable of coordinating four or more windows at once. When you open the browser the agent is already loaded in a side rail. You describe the task in plain English and the agent produces a plan — a numbered list of steps with the URLs it will visit, the files it will touch, and the commands it will run. Nothing executes until you approve the plan.

Once you approve the plan, the agent begins working. You watch it click, type, scroll, and read — the same way a junior engineer would drive a browser during a demo — and the output stream shows you, line by line, what it is reasoning about. If it gets stuck, Antigravity pauses and surfaces a decision point: a small modal asks a clarifying question, you answer, and execution resumes. If the agent is confident, it plows through all the way to an artifact bundle at the end.

The artifact bundle is the feature most teams end up caring about. Every HTTP request, every file write, every console log, every screenshot, every test run is captured and stored as a single replay object. You can scrub the timeline, pin a step, annotate a decision, share the whole bundle with a reviewer, or re-run from any checkpoint. That is the part Google spent the longest on and it is the part that makes the product reviewable in a regulated environment. See the NIST AI guidance for a policy-level view on agentic-tool audit trails.

Why Google built a browser rather than another editor

Most engineering work now happens across a browser, not only inside an IDE.

The competing category is AI-native editors — Cursor, Windsurf, VS Code with its agent extensions. Those products live inside a code workspace and drive changes through a file tree. They are good at that job. But a great deal of modern engineering work no longer happens inside a code workspace. It happens in a pull request review, a dashboard, a runbook, a monitoring console, a ticket, an internal admin panel. All of those surfaces are browsers. An editor-based agent cannot click through a PR, open a monitoring graph, and correlate the graph with a log entry. A browser-based agent can.

Antigravity is Google's bet that the natural surface for an AI coding partner is the browser that already holds most of your work. The editor is embedded — there is a side-pane code editor with Gemini autocompletion and repo indexing — but the primary loop is a browser loop. The agent plans across tabs. The artifact store records across tabs. The review tools render across tabs. Engineers who spend most of their day in a browser rather than in a text editor have been the loudest adopters, which matches the thesis.

Multi-window orchestration in practice

One agent, four windows, one task — this is the layout engineers keep asking for.

The multi-window mode is the pattern that separates the browser from a chat session. You open a single task — say, "diagnose why the signup flow regressed last night" — and the agent splits the workspace into four panes. The first pane is the production dashboard with request-rate graphs. The second is the log viewer, pre-filtered to the signup service. The third is the git history of the services involved. The fourth is the editor with the relevant file already open. The agent keeps the panes in context; you can pin any of them, resize the grid, or hand the agent to take the next step based on what all four panes show.

Engineers used to do this manually — four Chrome tabs, four mental contexts, a notepad on the side. The browser is now the thing that holds the context, which means context does not evaporate when you close a window. Pin the grid, hand it off to a colleague, come back in the morning — the layout and the run history are still there, ready to keep going. Teams that run on-call have reported this pattern reducing mean-time-to-understand on regressions, because the first ten minutes of triage are already done by the time a human joins.

Where the name "Antigravity" comes from

A nod to the project's internal codename: "lift the dev loop off the ground."

Google has not published the full naming story, but the one leaked from the initial press briefing was that the internal codename for the project was Lift, then Liftoff, then Antigravity. The framing is that the repetitive mechanical parts of development — the form-filling, the log-hunting, the runbook-walking, the copy-between-windows — hold engineers down. A browser that automates those parts removes the gravity from the workflow. Whether that framing lands for you is a matter of taste, but it explains the upward-motion imagery across the product surface and the launch materials.

Naming confusion is real. "Antigravity" overlaps with older "anti gravity" physics terminology and with legacy Google experiments like the old Google Code hosting service. Each of those has its own deep-dive page on this reference site — the anti gravity AI primer and the Google Code naming page cover the adjacent terms. If you landed here searching for the Google developer product, this is the right site.