Why Nool · for engineering leaders
Run more agents. Keep control of the codebase.
Your engineers already run Claude Code, Codex or opencode. Nool decides who may change what, runs your rules before anything lands, and keeps a signed record of every change. Your repositories, reviews and CI stay as they are.
What changes at fleet scale
Three things break when agents multiply.
- 01
Agents collide
Two agents on two branches can rewrite the same function, and Git only notices when they meet in CI. With 35 agents on one codebase, unscheduled git hit 20–22 merge conflicts a run and landed 33–62% of tasks; with Nool, no conflicts and 98–100% landed.
- 02
Review becomes the bottleneck
Agents produce more change than your senior engineers can read. The job is now deciding which changes need a person, and letting the rest land on checks you trust.
- 03
AI review is not a control
An AI reviewer can approve tomorrow what it rejected today. A rule you write gives the same verdict on the same change every time, and no model makes the call.
Source: the coordination benchmark, vendor-run and pre-registered. Given the same perfect plan, git ties Nool; real fleets rarely have one. Read the benchmark
For your engineers
What changes, and what doesn't.
Stays the same
- Their coding agent: Claude Code, Codex or opencode
- Git, branches, pull requests and code review
- CI and how you deploy
Changes
- Agents claim the code they will change before they edit it, so overlap shows up first
- Each change is built, tested and checked against your rules before it lands
- Every landed change carries its intent, test results and approvals
Day one
What works on install, and what you switch on.
On install
- Agents announce what they are about to change and hold a lease on it, so two agents don't edit the same code at once.
- Each proposed change is built and tested in isolation before it lands, and a mutation check records whether the tests actually pin it.
- Every landed change gets a signed evidence record you can print with nool evidence.
When you configure it
- Your rules: block secrets, protect folders, require tests. Written in YAML beside the code, or compiled to WASM by your platform team when a rule must not bend.
- Who may change what: role grants signed by your issuer, with identity from your identity provider through nool login. Until you configure an issuer, grants are not enforced.
- One policy floor for every repository in workspace.toml. A repository can tighten it, never weaken it.
- Named human approval for the paths that need it, such as auth, crypto and billing.
Fast mode skips validation for quick local iteration. Keep full validation on every path that matters.
Rollout
Three steps, each one earning the next.
- 01
One engineer, one repository
Install Community on a real repository and run your agents through it for a week. It is free, with no email and no card. You see what the agents touched and where they overlapped.
- 02
Turn on the rules that matter
Add rules for secrets, protected folders and required tests, and keep full validation on the paths that matter. Changes that break a rule are refused before they land, not flagged afterwards.
- 03
Across the organisation
Set one policy floor across repositories, connect your identity provider for role grants, and add named approval for sensitive paths. Team plans are self-serve; Enterprise adds the organisation rollup and contract terms.
Audit evidence
A record your auditors can check.
Every landed change carries a signed record of its intent, the checks it passed and who approved it. Anyone with a clone can verify it. nool audit verify maps your repository's history to the controls of a framework, and packs ship for SOC 2, ISO/IEC 27001:2022, PCI DSS 4.0.1, the HIPAA Security Rule, GDPR and SOX ITGC.
The packs check your repository's controls. They are not a certification of Nool.
Your code
Where your code and evidence live.
- Code and evidence stay on your machines or in your VPC.
- The CLI contacts nool.dev only for licence and device activation. Licences are signed tokens that verify offline.
- Sign-in for role grants goes through your own identity provider.
- Air-gapped deployment is available on Enterprise.
Compared
What your current tools can't tell you.
| What you need to know | Git and CI | An AI code reviewer | Nool |
|---|---|---|---|
| Which agents are about to change the same code | No: it shows up at merge or in CI | No | Yes, before the edit |
| Whether a change breaks your rules, before it lands | After the push, in CI | Sometimes, and the verdict can change | Yes, the same verdict every time |
| Whether the tests actually pin the change | No | No | Yes, a mutation check recorded with the change |
| A signed record of what each change passed and who approved it | Partly: commit and pull request history | No | Yes, on every landed change |
See it on your own repository.
Talk to us about a rollout for your team, or have one engineer try Community first.