The platform · a control plane for coding agents

Nool Platform

The Nool platform sits between agent intent and repository state so teams can govern code evolution without abandoning Git compatibility.

  • Semantic lineage and evidence trails for code transitions.
  • Git-compatible workflows with governed AI execution.
  • Policy and safety gates before changes become canonical.
Install, onboard a repository, and expose it to your agents
# One-line install, then verify the binary
curl -fsSL https://www.nool.dev/nool-install.sh | bash
nool version

# Onboard an existing Git repository without changing it
nool init --from-git main
nool discover features
nool status --compact

# Scaffold team governance and check release readiness
nool config init-governance
nool doctor --strict

# The web console and control-plane API, headless for a desktop or CI embed
nool console --serve

On macOS the installer supports Apple Silicon only; Intel Macs are not supported yet. Windows uses the PowerShell installer. Individuals evaluate free for 30 days or 2,000 knots; organisations license through sales.

What sits between an agent and your repository

A coding agent needs more than a model and a shell to work safely in a shared codebase. It needs an identity, a way to claim scope without colliding with other agents, memory that survives its session, a check on what its change actually reaches, gates that encode the team's rules, and a record of what it did that a person can audit later. Git provides none of these; it stores the result. Nool is the layer that provides them, installed on the repository you already have, running locally, with Git remaining the storage and ecosystem layer underneath.

The pieces

The CLI is the product's surface: init, announce, propose, solidify, debug, learn and the rest, with --compact output designed for agents to read. The MCP server exposes the same capabilities to Claude Code, Cursor and any MCP-capable agent as tools. The ledger in .nool holds knots, findings, tasks, leases and attestations and mirrors to Git. Try branches with isolated worktrees give each agent its own room; leases with fencing numbers give each room a lock. Personas are persistent, budget-capped agent identities with a charter and memory. Fleets plan and run parallel work and reviewer quorums. A hub server extends leases across machines with OIDC principals and org and repo access control. nool console serves a web console and the control-plane API, and Nool Mission Control is the desktop control plane for inspecting projects, missions, governance and agent activity.

Local first, by design

Nool runs entirely on the machine where the repository is. The licence verifies locally against a signed file. Policies evaluate locally. Nothing phones home. Syncing to a hub is opt-in for teams that need cross-machine leases, and Git-only teams get fenced leases as compare-and-swap refs without any server. That is a deliberate posture for the buyers who evaluate Nool as a governance control rather than as developer tooling: security and platform leads need to know where agent activity is recorded and who can read it, and the answer is the repository they already control.

Proof from running it on itself

Nool governs its own development. As of the July 2026 internal case study, three repositories, the Nool core, Mission Control and this website, held 1,307 knots, 299 recorded findings and 407 resolved semantic conflicts, with a 100 percent internally calculated debt-remediation rate. Those are dogfooding metrics from nool insights, published with the caveat that they are not an independent audit and that resolved semantic conflicts are DAG convergence events, not prevented production failures. The vendor-run coordination benchmark, built so a skeptic can check every number, is the measured one: bare Nool ahead of git worktrees on throughput, processes and stall, and governed Nool tied on throughput with slightly higher stall (synthetic agents, nool 6.14.1).

Workspaces: many repositories, one control model

Most organisations do not have one repository. nool workspace coordinates a polyglot workspace of nested Nool projects: it reconciles the workspace topology, turns cross-project goals into real child-ledger tasks, rolls release health and operating metrics upward conservatively, and orders coordination across dependencies. Engineering leaders get one recursive control model from organisational intent down to project execution, without a shadow management ledger beside the code. Each project keeps its own ledger and its own gates; the workspace layer reads them and coordinates between them, which is the same local-first posture applied one level up.

Frequently asked questions

Is Nool a hosted service?
No. It is a CLI and ledger that run on your machine and in your repository, with an optional hub server you can run for multi-machine leases and a desktop control plane. There is no requirement to send code or activity anywhere.
Which agents does it work with?
Any agent that can run a CLI or call an MCP server: Claude Code, Codex, Cursor, Gemini CLI and internal agents. Fleets and quorums are deliberately cross-vendor.
What is Mission Control?
A separate desktop application for inspecting projects, missions, governance state and agent activity across repositories. It is part of an organisation licence alongside the CLI and is not required to use the CLI.
How does licensing work?
Individuals get a free 30-day or 2,000-knot evaluation with no card. Organisations license Nool org-wide through sales; the licence verifies locally. There are no self-serve paid tiers.
Can it govern many repositories at once?
Yes. nool workspace treats nested Nool projects as one workspace, with topology reconciliation, goal-to-task decomposition into child ledgers and conservative rollups of release health. Governance packs apply the same roles and policies across every project.