For engineering teams
Grok Build pilot: from private setups to a shared configuration in your repo.
A Grok Build pilot for a team that already uses it: a shared configuration in one repo and a written go/no-go decision against agreed criteria.
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
- .grok/skills/team procedures
- .grok/agents/subagents
- .grok/config.tomlallow, ask and deny rules plus MCP servers
- .grok/hooks/checks that run on events
- .github/workflows/PR gate
When every developer configures Grok Build their own way
Your developers already work with Grok Build, each on their own settings. For one-off experiments, that is enough. Once the agent changes code the whole team answers for, the missing shared rules show up in code review and in the questions your security team asks.
- 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.
- No shared rules
- Project conventions, how to test, which areas are off limits: each developer explains these to the agent separately, or not at all.
- Nobody knows what the agent may run
- There is no single place that shows which commands, files and systems 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?
xAI’s 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 uses Grok Build
- 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 use Grok Build 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 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, permissions and the agent’s tools go into the repo: AGENTS.md, skills, subagents, hooks, and the permission rules and MCP servers in .grok/config.toml.
- Aurora AI
- Prepares the configuration from the diagnosis 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 Grok Build 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 organisation policy, a CI gate and answers for your security team.
- Aurora AI
- Prepares the organisation policy and deny rules, sets up a PR gate for agent-made changes, and writes down answers to the security team’s questions.
- Your team
- Your admins deploy the organisation policy, and the security team asks its questions and assesses the answers. Licences and access stay on your own xAI plan or API account.
- 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
Shared project rules
Working rules for the repo that Grok Build loads in every session once the project folder is marked as trusted.
.grok/skills/
Team skills
Your team’s written procedures, which the agent loads only when a task needs them.
.grok/agents/
Subagents
The project’s subagent definitions. Each subagent works in its own context, separate from the main session.
.grok/config.toml
Permission rules and MCP servers
Shared allow, ask and deny rules and the project’s list of MCP servers, committed to the repo. A deny rule takes precedence over ask and allow.
.grok/hooks/
Hooks
Checks that run on defined events and can block the agent from using a tool.
managed_config.toml / requirements.toml
Organisation policy
Defaults and signed requirements that admins deploy outside the repo. A developer can override the defaults locally but not the requirements, which can, for example, set the list of allowed models or switch off the mode in which the agent approves everything itself.
.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 deploy the organisation policy for the whole company, outside the repo. 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
AI agents develop the site you are reading, 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 Grok 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.
When a Grok Build pilot makes sense
The pilot helps when
- Your developers already use Grok Build, each with their own settings.
- 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 a conversation about how your team works.
- Nobody on your side can take responsibility for the decision.
- You expect us to supply the licences. We do not sell them: you buy them directly from xAI.
- You want agent-made changes to reach your code without review.
- Your team uses Grok models only in another editor or agent. This pilot covers Grok Build itself.
Common questions
Is Aurora AI an xAI partner?
No. Aurora AI is an independent consultancy. We do not sell licences and we are not a billing intermediary. You buy licences and access directly from xAI, on a Grok business plan or through the xAI API. Grok Build is an xAI product.
Will our code be used to train models?
According to xAI’s documentation (as of October 2026), that depends on the plan and on the “Coding data, retention, and training” setting, which on team accounts only the team admin can change. The admin can also turn on Zero Data Retention (ZDR) for the team, which locks that setting. In the pilot we write down which plan and which settings apply to your team, 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.
Grok Build changes often. What happens to the configuration?
The configuration lives in your repo and changes through a PR, like any other code. When the tool gets a new feature or changes its behaviour, the team updates the configuration in a normal PR. In the pilot, the team practises exactly this way of working.
Our developers also use other agents. What then?
According to xAI’s documentation, Grok Build loads rules from AGENTS.md and, for compatibility, also from CLAUDE.md and the .claude/ directory. In the pilot we settle which file is the source of truth, so the same rules do not exist in several diverging versions.
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 Grok Build 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. The last one covers Grok Bot, a different xAI product from Grok Build.
Describe how your team uses Grok Build today
Tell us what 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 an xAI partner, we do not sell licences, and we are not a billing intermediary. You buy licences and access directly from xAI. Grok Build is an xAI product.