For engineering teams
Google Antigravity rollout: from private setups to a shared, governed configuration in your repo.
We start a Google Antigravity rollout with a one-team pilot: a shared configuration in the repo and a written go/no-go decision against criteria set upfront.
The offer: a pilot for one team in one repo, ending in a written go/no-go decision against criteria set down before kickoff. We agree time and cost in writing before we start.
- AGENTS.mdproject rules
- .agents/rules/triggered rules
- .agents/skills/team procedures
- .agents/agents/subagents
- .agents/hooks.jsonchecks that run on events
- .agents/mcp_config.jsonMCP servers
- .github/workflows/PR gate
When every developer uses Gemini tools their own way
Your developers already work with Gemini tools: some with Gemini Code Assist, others with Gemini CLI or Google Antigravity, each on their own settings. For new rollouts, Google now points to Google Antigravity in Gemini Enterprise (according to Google documentation, as of October 2026), including for teams on Gemini Code Assist. Teams moving off Gemini Code Assist have to rebuild part of their settings anyway. Better to do it once, together, in the repo.
- Different permissions
- One developer lets the agent run commands without asking. Another approves every command separately. The same task runs differently for each of them.
- Rules in home directories
- Project conventions, how to test, which areas are off limits: each developer writes these into their own agent settings, or not at all.
- Nobody knows what the agent may run
- There is no single place that shows which commands, files and MCP servers the agent can reach in a given repo.
- Security questions nobody can answer
- Your security team asks about data, permissions and change control, and nobody can answer for the whole team.
Why run a pilot when the documentation exists?
Google documentation explains what you can configure and how. In the pilot we do it in your repo, with your team, and finish with a written decision on whether to go further.
The pilot
From diagnosis to a written decision
We work with one team in one repo. Each step shows what Aurora AI does, what your team brings and what we check.
- Team
- One team that already works with Gemini tools
- Repo
- One repo, chosen together with you
- Ends with
- A written go/no-go decision against criteria set down before kickoff
- Time and cost
- Agreed in writing before kickoff
Diagnosis
Diagnosis and decision criteria
We look at how your developers work with Gemini tools today, pick the team and repo for the pilot, and write down the decision criteria.
- Aurora AI
- Talks to the developers, reviews their current settings whichever tool they use, and proposes the team, the repo and the go/no-go criteria.
- Your team
- The lead names the team, the repo and the person who will make the final decision. Developers show how they work with the agent today.
- We check
- The go/no-go criteria are written down, and the person who will decide accepted them before kickoff.
Configuration
A shared configuration in the repo
Working rules and the agent’s tools go into the repo: AGENTS.md, triggered rules, skills, subagents, hooks and the MCP configuration.
- Aurora AI
- Prepares the configuration from the diagnosis, carries over what already works in the current settings, and submits every change as a PR.
- Your team
- Developers review every PR and decide what goes into the repo and what needs rework.
- We check
- The configuration lives in the repo, and every change to it has passed team review in a PR.
Tasks
Real work from the backlog
The team works with Google Antigravity on real tasks from the current backlog.
- Aurora AI
- Pairs with developers and adjusts the configuration where it gets in the way or something is missing.
- Your team
- The team picks tasks from the current backlog and reports where the configuration helps and where it slows work down.
- We check
- Changes made with the agent get the same code review as all other work, and configuration fixes go through a PR.
Governance
Governance and security
On top of the rules in the repo, we add admin settings in Gemini Enterprise, a CI gate and answers for your security team.
- Aurora AI
- Proposes admin settings in Gemini Enterprise (an allowlist of MCP servers, whether third-party models are allowed, prompt and response logging), deny rules and the sandbox, sets up a PR gate for agent-made changes, and writes down answers to the security team’s questions.
- Your team
- Your admins apply the settings in Gemini Enterprise, and the security team asks its questions and assesses the answers. Licences stay on your own Gemini Enterprise subscription.
- We check
- A forbidden action is blocked, an unreviewed change does not reach the main branch, and the security team has its answers in writing.
Decision
Decision and handover
The pilot ends with a memo that assesses the result against the criteria written down at the start.
- Aurora AI
- Writes the memo with a go or no-go recommendation and hands over the configuration documentation.
- Your team
- The accountable person makes the decision, and the team takes over the configuration and keeps maintaining it as code.
- We check
- The decision is in writing and justified against the criteria. The configuration stays in the repo whatever the outcome.
What stays in your repo
The configuration is built in your repo and reviewed by your team. You keep it after a no-go decision too.
AGENTS.md / GEMINI.md
Shared project rules
Working rules the agent always follows, across the whole repo or in a chosen directory.
.agents/rules/
Triggered rules
Extra rules that switch on when the trigger described in the file header fires.
.agents/skills/
Team skills
Your team’s written procedures, which the agent loads only when a task needs them.
.agents/agents/
Subagents
Separate agents for selected tasks that inherit the parent agent’s limits: allowed commands, file scope and sandbox settings.
.agents/hooks.json
Hooks
Checks that run on defined events in the agent’s work.
.agents/mcp_config.json
MCP configuration
A shared list of MCP servers the agent connects to for the project, in line with the allowlist your admin sets.
permission rules
Project permissions
Allow, ask and deny rules plus the permissions granted to the project: what the agent does without asking, what it must ask about, and what it will not do at all. Deny beats ask, and ask beats allow.
Gemini Enterprise settings
Admin settings
Organisation policy in the AI developer tools settings of Gemini Enterprise, for example an allowlist of MCP servers, whether third-party models are allowed, and prompt logging to your Google Cloud project.
.github/workflows/
PR gate in CI
A CI check that does not let an agent-made change into the main branch without tests and human review.
go/no-go memo
Decision memo
A written assessment of the pilot against the criteria agreed before kickoff, with a go or no-go recommendation.
team
A trained team
Developers who know the configuration, change it through PRs and can maintain it on their own.
Your admins apply the admin settings in Gemini Enterprise, outside the repo. Permission rules are set per user and per project, so we describe them in the configuration documentation. The memo goes to the person who makes the decision, and the know-how stays with your team.
Our own example
We work the same way ourselves
We run our own operation under the same rules we put in place in the pilot.
- Agents have defined roles, such as planning, copy, site building, SEO and QA.
- Every agent works through a PR, and automatic gates check every change.
- Changes to agent definitions, scripts and gates wait for a person to review them and merge them by hand.
We have already delivered a Gemini rollout for a client. As with all our client work, we do not name the company.
# Scope: any open PR targeting main whose checks are green (operator's
# explicit choice), EXCEPT a PR that changes code or gates: `scripts/**`,
# `.github/**` (incl. pr-guards.yml), `.claude/**`, `package.json`,
# `package-lock.json` (any folder). […]
# […] Gated PRs get the label `needs-adam` and a comment, and wait for
# Adam to merge by hand […]An excerpt from the auto-merge rule in our repo
A PR that changes agent definitions, scripts or gates is not merged automatically. It waits for the founder to merge it by hand. This rule comes from a security decision: content that an outsider feeds to an agent must not be able to change code or gates and have that change go live on its own.
After the decision
The pilot does not turn into a wider rollout on its own. You decide the next step, based on the memo.
A go decision
The next step is a rollout to more teams. We agree its scope, time and cost separately, based on the pilot’s findings.
A no-go decision
You keep the configuration in the repo and the memo. You know why it is not worth going further right now.
Google Antigravity rollout: when to start with a pilot
The pilot helps when
- Your developers already work with Gemini tools, each with their own settings.
- Your team uses Gemini Code Assist, and you plan the move to Google Antigravity in Gemini Enterprise.
- You want shared rules before the agent spreads to more teams and repos.
- Someone on your side can make the go/no-go decision and own it.
- Your security team is asking what the agent may do in your code and needs the answers in writing.
The pilot is not the right choice when
- You are still choosing a tool. Then start with the comparison of coding agents in our knowledge base.
- Nobody on your side can take responsibility for the decision.
- You expect us to supply the licences. We do not sell them: you buy the Gemini Enterprise subscription directly from Google.
- You want agent-made changes to reach your code without review.
Common questions
Is Aurora AI a Google partner?
No. Aurora AI is an independent consultancy. We do not sell licences and we are not a billing intermediary. You buy the Gemini Enterprise subscription directly from Google, in the Google Cloud console or through Google Cloud sales, and your administrator assigns licences to developers.
Will our code be used to train models?
According to Google documentation (as of October 2026), under Google Cloud terms, company code and prompts in Google Antigravity are not used to train base models, and telemetry and logs go to your own Google Cloud project. In the pilot we write down which subscription and which settings this depends on, and confirm it with your security team.
How long does the pilot take, and what does it cost?
That depends on the team, the repo and the decision criteria, so we do not publish prices on the site. We agree time and cost in writing before kickoff, after a first conversation.
Gemini tools change quickly. What happens to the configuration?
That is exactly why the configuration lives in your repo and changes through a PR, like any other code. The move from Gemini Code Assist to Google Antigravity shows it well: when the tool changes, the team updates the configuration in a normal PR instead of rebuilding each developer’s settings one by one. In the pilot, the team practises exactly this way of working.
We use Gemini CLI or Gemini Code Assist today. Does the pilot still make sense?
Yes. We start from what the team uses today. A GEMINI.md file also works in Google Antigravity, and we carry the rules and settings that work into the shared configuration in the repo.
What if the decision is no-go?
You keep the configuration and the memo. The memo shows which criteria were not met, so you know what would have to change before you revisit the decision.
Can you roll out Google Antigravity across the whole company?
That is a possible next step after a go decision. We plan and price that stage separately, once we know what the pilot showed.
More in the knowledge base
Articles and guides that go deeper into the topics of the pilot. If you are still choosing a tool, start with the comparison of coding agents.
Describe how your team works with Gemini tools today
Tell us which tools and settings your developers use today, which repo you want to start in and who will make the go/no-go decision. We reply by email and suggest a conversation about the pilot.
The contact page leads to email. You do not need a finished specification.
Aurora AI is an independent consultancy. We are not a Google partner, we do not sell licences, and we are not a billing intermediary. Google Antigravity and Gemini Enterprise are Google products.