concurrent.cd
Tool / Nool is a coordination layer over Git that stores work in an append-only ledger of causally linked change events it calls "knots". An agent first announces the files it expects to touch (its footprint) and takes leases on them, then proposes its change. Before the change is accepted ("solidify"), Nool runs it through gates: a symbol-level blast-radius check (which code depends on what changed), optional full semantic validation, and authored policies written in Aram and run as WASM. `nool fleet plan` writes the footprints for a task list and schedules agents so footprints don't collide. The ledger attributes each write to the agent that made it, so `nool pluck` can undo one bad change without losing the others. Decisions are kept with `nool learn` (with scope and supersedes) as memory agents can query.

Nool

A coordination layer between coding agents (Claude, Codex, Cursor) and Git: it schedules agents by planned file footprints, checks changes and lands them, billed as "air traffic control for AI coding".

The summary describes what the project says it does; inclusion is not an endorsement.

Take

Worth tracking mostly for how honest its benchmark is (vendor-run, pre-registered, open harness). It finds the gain comes from scheduling by file footprint, not from replacing git: unscheduled git lost 23 and 40 of 60 tickets at 35 agents, but git given the same footprint locks ties Nool when the plan is perfect. Nool's own edge shows when plans are wrong. With noisy footprints at 20 agents, the gap grows from 0 to +6.7 pts (n=2 per level), and conflicts drop from 10.5 to 6.0 at heavy noise.

Two findings matter for the field beyond Nool:

  • File locks are necessary but not enough. In a zero-noise run of scheduled git, billing tickets that were correctly serialized each passed their own tests while the shared suite failed. Semantic checks are still needed after scheduling.
  • Governance costs throughput. The bare path beats git worktrees (718.5 vs 635.4 tasks/hr). Full validation only ties git, and an authored policy trails it by 51.8 tasks/hr, but that policy blocked all 10 seeded violations in 36 of 40 runs. The documented announce/discover lease protocol was slower than git on every measure except process count (242 tasks/hr). None of validate --all, verify --all or doctor catches a change that has already landed.

On memory, Nool's decision ledger reached 0.75 precision against 0.40 for flat retrieval (TF-IDF), and stale hits fell from 16 to 6. Limits: synthetic agents in the throughput runs, a 300-line service, one model, landing that costs 11–79× git's commit, and only 14 of 85 commands exercised.

AI-drafted

Mentioned in

Link

Nool coordination benchmark: Nool vs git worktrees at 10–45 agents

nool.dev/research/coordination-benchmark · §5.6 Implementation Audit; §5.7 Imperfect Intent Robustness; "What this does not establish"

Nool's own pre-registered benchmark, with an interactive data explorer, comparing it to git when 10–45 agents edit one repo at once. Its harness and raw data are open.

Take

A rare vendor benchmark that undercuts its own headline. Unscheduled git worktrees lost 23 and 40 of 60 tickets at 35 agents. But git given the same file-footprint locks ties Nool when the plan is accurate, so the gain comes from claiming files before work starts, which any team can build. Nool's edge shows only when plans are wrong: a 0 to +6.7 pt gap at 20 agents as footprint noise rises, from n=2 runs per level.

What carries beyond Nool:

  • Locking files isn't enough. In one run with a perfect plan, every ticket passed its own tests while the shared suite was broken. Check the whole system's health, not just how many tickets were accepted.
  • Catching conflicts at merge time wastes money. Starting every agent blind and resolving at merge wasted 37–41% of spend. Claiming files up front kept waste near $0.
  • Checks cost speed. With no checks, Nool beats git worktrees (718.5 vs 635.4 tasks/hr). Full validation only ties git, and custom policy rules trail it by 51.8 tasks/hr.

Watch the overhead figure. The page quotes 11–79× git's commit time, against a bare commit. The repo README puts it at about 6× (11× at 100 files) against git with a realistic pre-commit hook, and says those hooked figures came from a loaded machine and need a re-run. Raw data is in the repo: the findings report, plus results/trackc/fleet_runs.jsonl and results/micro/.

  • Coordinate
  • Verify
  • Integrate
  • Plan
  • Remember
AI-drafted