Features

Everything a change passes before it lands.

Nool sits between your coding agents and Git. Agents claim the files they will change, each change is built, tested and held to your rules before it lands, and what lands carries its own evidence.

Talk to usTry Community free

Coordinate

Agents claim their work before they start.

  • Leases

    An agent names the files it will change and holds a lease on them. Another agent asking for the same files waits or takes other work, so two agents never rewrite the same code at once.

    nool announce intent

  • Blast radius

    Before a change lands, Nool lists the code that depends on it, down to the callers of a single function.

    nool debug blast-radius

  • Isolated worktrees

    Each agent can work in its own checkout under its lease. It merges back against the base it started from, and a real conflict stops with markers instead of a guess.

    nool try new --worktree

Check

Every change is checked before it lands, not after the push.

  • Build and tests, in isolation

    Proposing a change builds it and runs the tests it affects in an isolated copy of the repository. A change that does not build is refused.

    nool propose

  • Mutation check

    Nool alters a few of the changed lines on purpose and runs the tests again. The record says whether the tests caught every alteration, so you know if they actually pin the change.

    tests_constrain_change

  • Configurable rules

    Rules written in YAML beside your code, such as no secret keys in a diff. Edit the file and the next change is held to it. The same change gets the same verdict every time.

    policies/*.yaml

  • Hard rules, installed for your teams

    Your platform team compiles rules to WebAssembly and installs them for every repository. They are sealed: changed only by rebuilding, never by an agent editing a file.

    nool policy stats

Land and audit

What lands carries its own evidence.

  • A signed record of every change

    Each landed change is signed and records who proposed it, which checks it passed and which rules applied.

    nool evidence knot

  • Human approval where you want it

    Changes can wait for a person's sign-off. Authors cannot approve their own changes unless you allow it, and then the approval is labelled as a self-approval.

    nool approve

  • Audit reports from Git history

    Check the controls over any range of changes from Git history alone. A fresh clone reproduces the same answer.

    nool audit verify

  • Your Git forge stays

    Nool pushes ordinary Git commits to the forge you use today, so pull requests, CI and code owners keep working.

    nool push origin

Remember

What one session learns, the next one starts with.

  • Findings

    Agents and engineers record decisions and root causes. Nool brings the relevant ones into the next session that touches the same code.

    nool learn

  • A bug ledger tied to changes

    Each bug is filed against the change that introduced it and linked to the change that fixed it, so you can see how long defects stay open.

    nool bug report

  • Replay and bisect

    Replay an agent's run step by step, or search the history for the change that introduced a regression.

    nool debug bisect

nool code

A coding harness your team owns.

  • Sessions that end verified

    Run a goal with a supported provider or a local model, within the budget you set. The session works in its own worktree under a lease and ends Verified only when the build, the affected tests and the task's acceptance criteria pass.

    nool code

  • Fleets (Team)

    Split a goal into tasks that child sessions run in parallel. They land in dependency order and pass one combined check.

    nool code --fleet

Any model in the cockpit.Your team in the tower.

Nool governs whichever agent your team already uses. nool code is the agent Nool ships, governed the same way.

How nool code works

nool code

nool code is the coding agent harness your team owns, not one a model provider runs for you. You set the budget, you decide how a task moves from goal to landed change, and your platform team hardens it to the business's rules.

  • Budgets that stop a session, not just warn
  • Your task lifecycle, from goal to verified landing
  • Hardened to your platform team's rules
  • Run local models or any supported provider
In this run the model reported "Fully Complete". The check said otherwise, so the session stopped at 80% of its $2 budget and handed the call to a person.

Ask the tower. It shows you the log.

Each answer is real output from nool 7.24.0 in a fresh repository, copied line for line.

Agents claim the code they will change before they start. When two reach for the same file, the second is refused before it writes anything, so nobody reviews a collision. With 35 agents on one codebase, 98–100% of tasks landed against 33–62% for git without coordination.

Read the benchmark →
Two agents, one filenool 7.24.0
$ nool try new quota-raise --worktree --nodes crates/billing/src/lib.rs --agent-id claude-code --intent "Raise the Community quota"🧪 Started Experiment [c03a500c] Branch 'quota-raise'  ├── 🔒 Spatial Lease: Secured lease [a830a891] (seq 3) on file:crates/billing/src/lib.rs (0 conflicts)  └── 🎯 Intent: Raise the Community quota$ nool try new quota-refactor --worktree --nodes crates/billing/src/lib.rs --agent-id codex --intent "Refactor quota lookup"Error: Coordination conflict: agent b0deb2ca (try branch quota-raise) on file:crates/billing/src/lib.rs. Try branch 'quota-refactor' was not created. Wait for the scope: `nool lease wait file:crates/billing/src/lib.rs`; see holders: `nool lease status`.

Run it on your own repository.

Talk to us about a rollout for your team, or have one engineer try Community first.

Talk to usTry Community free

Code and evidence stay on your machines or in your VPC. The CLI contacts nool.dev only for licence and device activation. Security and data