# The review found the recurring mistake. Record it where the next change will look.
nool learn --about src/billing/ --scope billing --kind finding \
--content "Never call the payment provider from a React component; go through src/billing/client.ts so retries and idempotency keys apply."
# Before proposing a billing change, an agent reads the findings for that scope
nool findings src/billing/ --scope billing
nool context "add a refund button to the invoice page" --scope billing --budget 3000
# Review as evidence: a cross-vendor quorum, then a signed verdict on the knot
nool fleet start --builder <builder-spec> --reviewer <reviewer-a> --reviewer <reviewer-b> \
--intent "Add a refund button to the invoice page" --isolation worktree
nool attest record --target <knot-id> --checker architecture-review --assertion architecture-review --verdict pass
nool attest obligations <knot-id>Findings are scoped, so a billing rule is not returned for a mobile question. Attestations are refs, so review evidence never rewrites the branch.
Why review comments repeat
Every team has a review comment it has written a hundred times: round once at the end, never call the payment API from a view, keep the auth middleware pure. Each time it is written it lives in one pull request thread and dies there. The next agent, or the next engineer, has no way to find it, so the mistake recurs and the reviewer writes the comment again. Agents amplify this because they start every session from zero; a coding agent can be corrected on Monday and make the identical change on Tuesday with a fresh context window and no memory that the correction happened. Review memory is the missing piece: the outcome of a review has to become something the next change can be checked against.
Turn a review outcome into a finding
Nool gives review outcomes a home in the repository. When a reviewer corrects a change, the correction is recorded with nool learn as a finding, a root cause or a reasoning note, attached to a subject and a scope. nool findings retrieves it for that subject before the next change is proposed, and nool context includes relevant findings in the packet an agent reads before it starts work. A finding can supersede an earlier one when the rule changes, and the history of what the team believed is preserved. On the nool.dev site repository, 83.3 percent of recorded findings were retrieved again during later work, an internal measurement from nool insights reported in the July 2026 case study.
Reviews that are checked, not just remembered
Memory that agents can read is the first half. The second half is review that produces evidence. nool attest record mints a signed verdict from a checker, human or automated, about a knot: unit tests, a security scan, an architecture review, a human approval. Attestations are exported as refs, never as commits on the branch, and nool attest obligations shows which assertions a knot's touched paths require and which are still missing. For agent-produced changes, nool fleet start runs a builder against a cross-vendor reviewer quorum whose required fraction tightens as blast radius grows, and feeds a denied verdict's rationale back to the builder for a bounded retry. Reviews stop being comments and start being verdicts attached to the change.
A loop that gets cheaper over time
Put together, the loop looks like this. A reviewer or a quorum catches a problem. The correction is recorded as a scoped finding. The next agent's context packet contains it, so the same mistake is far less likely. If it happens anyway, an authored policy can encode the rule as a deterministic gate, and the review never needs to be written by a person again. The team's review effort compounds instead of evaporating, and the ledger shows, per subject, which corrections have been made, which are current, and how often they are being reused.
Obligations: making review non-optional
Memory helps the willing. Obligations bind the rest. In configuration, an attestation obligations table maps paths to the assertions they require, such as unit tests for everything, a security scan for anything under auth, and an architecture review for the payment package. nool attest obligations shows the resulting matrix for a knot: what its touched paths require, which are satisfied by trusted attestations and which are missing. nool attest wait lets a pipeline block until a trusted pass exists, and nool attest sweep moves every finished task whose landed knot now carries its required attestations to verified done. Review stops being a courtesy and becomes a precondition, without a human tracking who reviewed what.
Frequently asked questions
- Does this replace an AI pull request reviewer?
- No, it makes one useful. A review bot without memory writes the same comment forever. Record its accepted corrections as findings and they become context for every future change; encode the recurring ones as policies and they become deterministic gates.
- Can review memory be wrong or go stale?
- Findings carry a scope, can be superseded by newer findings, and can be queried as of a past timestamp. A rule that changed does not disappear; it stops being returned as current.
- How do reviewers from different vendors help?
- A single model reviewing its own vendor's output shares its blind spots. nool fleet start takes reviewer specs from different vendors and requires a quorum, with the fraction tightening automatically as blast radius rises.
- Where do attestations live?
- As signed refs under refs/knots, replicated with the repository and never as commits on your branch. nool attest show lists them with trust resolved from the configured checker keys.
- Can CI enforce that a review actually happened?
- Yes. Declare the assertions each path requires in the attestation obligations configuration, have reviewers and CI record signed verdicts with nool attest record, and use nool task verify-done --from-attestation so a task can only be verified when every obligation carries a trusted pass.