Does this replace pull requests?

No. Solidified knots mirror to Git and can flow through your existing pull request process; nool merge can also ingest an incoming branch into candidate knots and run the gate stack on it. What changes is that intent, impact, tests and approvals are attached before the pull request exists.

Which agents can be builders and reviewers?

Any agent Nool can run under a spec, across vendors. A quorum is deliberately cross-vendor so one model is not reviewing its own work. Claude Code, Codex, Cursor and Gemini CLI can all participate through the CLI or MCP server.

How do I keep an agent from burning budget?

Personas carry a daily USD budget, persona runs have a maximum number of turns, and nool usage budget-set caps token spend per agent. nool fleet start can run nool doctor --strict as a self-check before any reviewer is charged.

Can humans stay in the loop?

Yes, at the points that need judgment. nool approve records a human approval or rejection on a knot or thread, the architect gate holds coupling changes for sign-off, and the pre-push gate holds sensitive paths for a CISO attestation.

Can tasks come from GitHub Issues or Jira?

Yes. nool task import-github and nool task import-jira import a single issue as a task with explicit or generated draft criteria, and the list variants show what is available without importing. The upstream issue is untouched; the task in the ledger is what agents claim and what knots are linked to.

Multi-Agent Development Workflow for Coding Agents

Coordinate multiple AI agents by binding plans to verified state, surfacing collisions early, and preserving findings across the workstream.

One task, end to end

# Define the work with criteria that can be checked
nool task create --name "Add retries to webhook delivery" \
  --acceptance "Retries are bounded to 5 with exponential backoff" \
  --acceptance "Tests cover timeout and permanent-failure paths" --solidify

# Decide the shape before spending: single agent, parallel, or reviewer quorum
nool fleet advise --task webhooks=src/billing/webhooks.ts,src/billing/retry.ts --blast 12

# Run a builder with a cross-vendor reviewer quorum in its own worktree
nool fleet start --builder <builder-spec> --reviewer <reviewer-a> --reviewer <reviewer-b> \
  --intent "Add bounded retries to webhook delivery" --isolation worktree --max-iterations 3

# CI attests the landed knot, then the task can be verified done from evidence
nool test select --knot <knot-id> --format json
nool attest record --from-head --checker github-actions --assertion unit-tests --verdict pass --push origin
nool task verify-done --id <task-id> --landed-knot <knot-id> --from-attestation --solidify

Agent specs name the vendor and model for each builder and reviewer. The quorum fraction defaults to 60 percent and tightens with blast radius.

A workflow agents can follow without a human refereeing

Most teams run agents inside a human workflow designed for one developer at a time: pick a ticket, branch, code, open a pull request, wait for review. With several agents the human becomes the scheduler, the conflict resolver and the reviewer of everything, and the throughput gain disappears into coordination. Nool's workflow moves the scheduling and the conflict detection into the ledger so the human's remaining job is judgment: deciding what to build and approving what the gates and reviewers could not decide alone. The loop is announce, lease, propose, gate, review, solidify, and every step leaves a record an agent or a person can read later.

Tasks with acceptance criteria, in the same ledger as the code

Work starts as a task with verifiable acceptance criteria, created directly or imported from a GitHub or Jira issue. Tasks move through Open, Claimed, InProgress, InReview and Done, or through a custom lifecycle declared in configuration. An agent picks a task, starts it, and the work it proposes is linked to it. The QA checkpoint is where criteria are verified. nool task verify-done records a verification receipt against the knot that landed, and with trusted attestations in place it can require a passing verdict for every obligation the touched paths carry before a task is allowed to finish. What shipped and what was planned stay in one place, so they cannot drift apart the way a ticket tracker and a repository do.

Planning a fleet before spending on one

nool fleet advise takes the footprint of each task and a few measurable signals, such as blast radius, expected iterations and stable context size, and recommends an architecture: a single agent, parallel independent agents, or a builder with a cross-vendor reviewer quorum. nool fleet plan computes the waves of tasks whose node sets are disjoint, so agents in the same wave cannot collide, and with --run executes the plan with each task in its own branch, identity and lease. nool fleet start runs the quorum shape: one builder produces the work, several reviewers from different vendors judge it, and the quorum fraction tightens automatically as blast radius rises. A denied quorum can feed reviewer rationale back to the builder for a bounded number of retries.

Gates, attestations and the push

Between propose and solidify sit the gates: the envelope check, deterministic policy gates, and for changes that raise coupling, a named architect's sign-off. CI joins the loop through attestations: a job runs nool test select to pick the tests a knot's changes affect, runs them, and records a signed pass or fail with nool attest record, exported as a ref rather than a commit. Since 7.0 a knot that touches auth, crypto, identity or billing paths waits for a named CISO role to attest before it reaches origin. The result is a change whose intent, impact, tests, reviews and approvals are all attached to it when it lands.

Importing work you already track

Teams do not start from an empty task list. nool task list-github and nool task import-github bring a GitHub issue in as a task, and the Jira equivalents do the same for Jira, without changing anything upstream. Imported tasks arrive with draft acceptance criteria that nool task criteria inbox surfaces for review, so an issue written as a wish becomes a task with checks an agent can satisfy. Tasks relate to and block each other, carry tags and priorities, and can be assigned to a person or an agent identity. The tracker of record can stay where it is; what moves into the ledger is the link between the work and the knots that close it.

Frequently asked questions

Does this replace pull requests?: No. Solidified knots mirror to Git and can flow through your existing pull request process; nool merge can also ingest an incoming branch into candidate knots and run the gate stack on it. What changes is that intent, impact, tests and approvals are attached before the pull request exists.
Which agents can be builders and reviewers?: Any agent Nool can run under a spec, across vendors. A quorum is deliberately cross-vendor so one model is not reviewing its own work. Claude Code, Codex, Cursor and Gemini CLI can all participate through the CLI or MCP server.
How do I keep an agent from burning budget?: Personas carry a daily USD budget, persona runs have a maximum number of turns, and nool usage budget-set caps token spend per agent. nool fleet start can run nool doctor --strict as a self-check before any reviewer is charged.
Can humans stay in the loop?: Yes, at the points that need judgment. nool approve records a human approval or rejection on a knot or thread, the architect gate holds coupling changes for sign-off, and the pre-push gate holds sensitive paths for a CISO attestation.
Can tasks come from GitHub Issues or Jira?: Yes. nool task import-github and nool task import-jira import a single issue as a task with explicit or generated draft criteria, and the list variants show what is available without importing. The upstream issue is untouched; the task in the ledger is what agents claim and what knots are linked to.