From Gemini to Antigravity: Package feature flag governance once, enforce it everywhere

Google just changed how its coding tools work, and the change matters more than the new name suggests. Antigravity was announced at Google I/O in May 2026 and it’s not another editor.

Its centerpiece is a desktop app that Google calls an “agent control tower,” where you launch and supervise many AI agents working in parallel from a single dashboard. Around that sit a terminal CLI running the same engine and managed agents that run in the cloud. Antigravity is the successor to Gemini CLI, it ships new versions almost every week, and for enterprises it arrives with a proper deployment path through the Gemini Enterprise Agent Platform.

The interesting question is not which model is fastest this quarter. It is this: when your developers each have a fleet of agents writing and running code, how do you keep the way those agents reach your systems consistent, and how do you keep what they ship under control?

Antigravity gives you strong answers to the first half. Feature flags give you the second. Together they let you move at agent speed without turning every merge into a gamble.

The shift from one assistant to many agents

Autocomplete raised the volume of code. Agents raise the volume of technical decisions. Antigravity’s desktop app makes this concrete with its Agent Manager, a dashboard where a developer launches several agents at once, each in its own isolated worktree, and can schedule agents to run in the background on a timer.

The output is no longer a stream of suggestions you accept one keystroke at a time. It is parallel work, some of it running while nobody is watching, that arrives faster than any one person can fully trace.

This is where the DORA research on AI-assisted development is worth keeping in mind. As AI usage goes up, delivery stability tends to go down. Teams ship more, and more of what they ship crosses the line before anyone has understood it end to end. The old assumption that a reviewer approving a pull request also understood every line gets weaker when the author was an agent, and weaker still when several agents contributed.

To its credit, Antigravity gives you real tools to shrink that gap. The desktop app records what each agent did as Artifacts: the plans, task lists, walkthroughs, and even browser recordings an agent produces as it works. So a reviewer can check the reasoning at a glance instead of reconstructing it from a diff. That genuinely helps. It is also optional by design: teams can let agents proceed without pausing for review, and on a busy day they will. Oversight you can switch off lowers risk without guaranteeing it, which is exactly why what reaches production needs a boundary nobody can skip.

None of this argues against agents. The productivity is real, and Antigravity’s orchestration is a good way to capture it. It argues for two things that have always mattered and now matter more: a consistent, governed way for agents to reach your systems, and a reliable way to contain what they produce.

Two problems, two boundaries

Think of governance here as two boundaries around agent work.

The first is at authoring time: how do agents reach your systems, and who decided that? If every developer wires up their own tools and credentials, you have no consistent surface to reason about and no way to say “only these integrations, configured this way, are allowed.” You want one vetted path that every agent uses, and you want it to be the only path.

The second boundary is at runtime: what happens when the code an agent wrote actually runs in production? Review helps, but review is imperfect for code no human fully authored, so you want every meaningful change to ship in a state you can control after the fact, where a bad change is a quiet non-event rather than an incident. Antigravity is built to give you the first boundary. Unleash gives you the second, and the rest of this post walks through how.

Package once: the plugin as a paved road

Antigravity’s unit of distribution is the plugin, the successor to Gemini CLI extensions. A plugin bundles the things an agent needs to work with an external system into one installable package: the connection to that system through the Model Context Protocol (MCP), the instructions that tell the agent how to behave, and the workflows that go with it.

That packaging is the first half of the governance story, and it is more useful than it looks. Instead of asking every developer to set up the Unleash integration by hand, and getting a slightly different result each time, a platform team publishes one “Unleash” plugin. It carries the MCP server that connects Antigravity to your feature flag system, the project instructions that encode your naming conventions and rollout rules, and the flag-management workflows your teams should follow. A developer installs it in a single step and is immediately working the way your organization intends.

Teams already using Gemini CLI or Claude can import their existing setups as a starting point, so adopting Antigravity does not have to begin from scratch.

The practical payoff is that setup drift disappears. When your flag conventions change, you update the plugin, and the paved road updates for everyone. There is one artifact to own, review, and version, rather than a hundred slightly different local configurations you can neither see nor control.

Enforce everywhere: governance in Google Cloud

Packaging makes the right path easy. It does not, on its own, make it the only path. That is the job of the enforcement layer, and for Antigravity it lives in Google Cloud.

Enterprises run Antigravity through the Gemini Enterprise Agent Platform. You connect the desktop app and the CLI to a Google Cloud project with a Cloud login, and from that point every agent runs inference inside your own cloud boundary. Your code and prompts stay within your project, with regional endpoints and Google Cloud’s standard data protections, which is exactly what a security review wants to hear before agents touch a private codebase.

The part that turns packaging into enforcement is identity and access management. MCP tool use in the Agent Platform is governed by IAM, the same access-control system your organization already uses for cloud resources. You decide which people and agents are allowed to call MCP tools, and you can allowlist specific tools while blocking the rest.

In practice this means an admin can make the vetted Unleash integration the approved way to manage feature flags and prevent an agent from reaching an unapproved server. Because it runs through IAM, it is centralized, auditable, and consistent with how you govern everything else in Google Cloud. This is a stronger enforcement position than a local config file, because a developer cannot opt out of it.

Local guardrails on the developer’s machine

The developer’s own machine adds a layer too. The Antigravity CLI gates each agent action behind an approval mode, can run with terminal restrictions turned on, and blocks agents from acting outside allowed directories or sending sensitive files to endpoints you have not approved. Those local controls are useful for individual safety. The Agent Platform controls are what give you org-wide assurance.

The developer’s own machine adds a layer too, especially hooks. A hook is a small script that Antigravity runs automatically at a set point in an agent’s work, such as the moment before a tool runs. It inspects what the agent is about to do and returns a verdict, allow, block, or pause for a human to confirm, and it fires every time regardless of what the agent decided or which approval mode is in effect. That makes it a deterministic guardrail rather than a matter of trusting the model. You can require that any change to a production flag stops for human sign-off, and no clever prompt or model quirk gets around it.

Alongside hooks, the CLI gates actions behind approval modes, can run with terminal restrictions on, and keeps agents from acting outside allowed directories or sending sensitive files to endpoints you have not approved.

Those local controls protect the individual developer, while the Agent Platform controls give you org-wide assurance. Between them they cover both which tools an agent may use and how it is allowed to use them.

The runtime boundary: what actually ships

Standardizing and constraining how agents reach your systems handles the authoring boundary. It does nothing about the code itself once it runs. That is where feature flags come in, and why they matter more in an agent world than they did before.

We built the Unleash MCP server so that flag management follows your rules automatically rather than being reinvented by each agent. When an agent works on a risky change, a payment path, an authentication flow, or a database migration, it does not just write the code. It evaluates whether the change warrants a flag, checks whether a suitable flag already exists so you do not accumulate duplicates, creates one with a name that matches your conventions, and wraps the new code so it ships disabled by default. The change can merge and deploy while the feature stays off.

From there you are in familiar progressive delivery territory. You turn the feature on for internal users first, expand to a small percentage, and watch. With Impact Metrics, the signals that decide a rollout, request rates, error counts, latency, come straight from your application and tie back to the flag, so a rollout can advance when the numbers stay healthy and pause automatically when they do not. If something goes wrong, you disable the flag and the change is gone from production instantly, with no redeploy and no rollback branch. For code an agent produced with limited supervision, that switch is the difference between a contained experiment and a 2 a.m. page.

Evaluation itself stays private. Flags are evaluated locally inside your applications through Unleash SDKs or Unleash Enterprise Edge, so no user data leaves your systems to make a decision, and the MCP server inherits only the permissions of the token it is given, so you can scope it tightly and protect production behind change requests.

Why the runtime boundary matters even more with managed agents

Antigravity can run managed agents server-side, each in its own isolated, network-restricted sandbox. This is powerful for parallel work, and it also makes the runtime boundary non-negotiable. A managed agent can produce a pull request you did not watch line by line. When the change is already wrapped in a flag, that unsupervised work merges in a safe, disabled state, and you decide when and how it goes live.

Those cloud sandboxes are network-isolated, so reaching your flag system from a managed agent uses the network-reachable remote Unleash MCP server rather than the local integration a developer runs on a laptop. The plumbing differs, but the takeaway is the same: the runtime boundary holds whether an agent runs locally or in the cloud, so autonomous work stays contained wherever it happens.

The bridge: Gemini is not going away

The move from Gemini CLI to Antigravity is a transition, not an overnight cutover, and your teams are probably spread across it. Google retired the free and consumer tiers in June 2026, but access under a paid Gemini Code Assist Standard or Enterprise license remains unchanged for now, so those teams can keep shipping with the same Unleash integration while you stand up the Antigravity plugin and Agent Platform governance.

The governance model is identical on both sides: package the integration, enforce the approved path, and flag what ships. Only the plumbing underneath changes as you cross over, so you can migrate when it suits your roadmap rather than under deadline pressure.

What this buys you

Put the pieces together and the outcome is the one you actually want from AI: more speed without more fear.

Your developers get Antigravity’s orchestration, several agents working in parallel, moving faster than any single assistant could. The platform team gets one packaged integration that puts every agent on the same paved road, and the ability to enforce that road through the same Google Cloud IAM you already trust. Your organization gets a runtime boundary that means no agent-written change reaches users until you decide it should, and can be pulled back the moment it misbehaves.

That combination is what makes agent velocity safe to adopt at scale. The agents write the code, your governance decides how they reach your systems, and feature flags decide what actually ships. If you want to see the mechanics, our documentation walks through connecting the Unleash MCP server to Antigravity and Gemini, and our post on automated FeatureOps shows how metrics turn a rollout into something that manages itself.

The tooling will keep changing. The two boundaries will not.