Google Antigravity’s browser docs say its agent “will not share any of the cookies or sign-in information from your normal browsing profile,” because it runs in a separate Chrome profile—and then, one paragraph later, add the part most coverage will skip: sign-ins inside that isolated profile persist for future sessions.
That is the detail worth stealing.
The constraint is not about convenience
Most browser-agent demos get framed around autonomy: click buttons, fill forms, run workflows, watch the machine drive. The hard part in production is duller. You need the agent to touch authenticated systems without inheriting the blast radius of your everyday browser.
Antigravity’s docs handle that by splitting the environment in two. The agent uses your existing Chrome app, but not your existing Chrome profile. That means no ambient carryover from whatever is already open in your personal or work browser—no stray admin cookie, no shared session, no accidental piggybacking on a tab you authenticated six hours ago.
For an IT buyer at a 20-to-50 person firm, that matters more than another polished demo. If your stack is Google Workspace, HubSpot, Jira, and an internal staging app, the real question is not whether an agent can click through the workflow once. It is whether you can let it operate repeatedly without turning your main browser into part of the control plane.
The useful part is persisted isolation
The second buried detail is what makes the setup commercially viable: the isolated profile keeps its own sign-ins.
That is the difference between a toy and an operational tool. If every run forced your ops lead to log into the same SaaS stack from scratch, browser agents would collapse under their own ceremony. Antigravity’s approach keeps the boundary in place while preserving the working state of the automation environment.
In plain English: the agent does not get your normal cookies, but it also does not start over cold every morning.
For a solo dev running regression checks across a billing flow, a support portal, and an internal dashboard, that can remove a dumb amount of friction. If a senior operator costs roughly $120 per hour and a repeated login-and-context-reset cycle eats 20 minutes across a test pass, that is about $40 per run in avoidable labor before you count the cost of missed issues.
The workflow tradeoff is visible on the desktop
Antigravity’s docs are refreshingly explicit that this isolation changes the user experience. If your normal Chrome is already open, the agent profile appears as a separate dock icon and is treated like a separate application. If Chrome was not already open, it can look like the default profile until you quit and relaunch Chrome.
That sounds minor. It is not.
It means the product is choosing operational clarity over illusion. Instead of pretending browser automation is happening in the same trusted space as your normal work, it makes the boundary visible. That is good design for teams that have to explain tool behavior to nontechnical staff, auditors, or clients.
It also gives you a cleaner policy story. You can document one browser context for human work and one browser context for agent work. That is much easier to defend than “the AI uses Chrome too, but trust us, it is probably fine.”
Who should copy this pattern first
Agency owners and internal ops leads should pay closest attention here, especially if they are evaluating browser AI for repeated, authenticated work rather than one-off scraping.
If your likely use cases are QA on client portals, invoice reconciliation, form submissions, CMS edits, or customer-support triage, the separate-profile model is the minimum acceptable shape. Shared-cookie automation is faster to demo and worse to live with.
Buy the pattern, not the hype. Test browser agents only if they isolate credentials from your normal browser, persist their own authenticated workspace, and make that boundary obvious enough to document.
That constraint is doing more real work than the agent itself.