An agent review that says “looks good” leaves an engineering lead with an unresolved question: good against which obligations?
Assay gives the reviewer a brief, the candidate change and relevant system context. A brief is the work request’s outcome, scope and acceptance requirements. Review examines the candidate against that contract and returns findings for repair or an evidence-backed answer.
Correctness and security have established review responsibilities. Performance and architecture reviews* are planned additions. Separating their questions helps the reviewer follow different consequences of the same change.
Give the reviewer a concrete decision
Desk tools brief 24 makes shared audit-ledger reads cheaper for commands including deskpost, which posts agent reviews after checking authority and safeguards. The history records earlier activity used by write budgets, failure protection and duplicate-post prevention.
One safeguard trips after five consecutive refusals for the same tool and target. Progress resets the run; an ignored result such as a dry run leaves it unchanged. The run reaches beyond the one-hour write-budget window. Its retry pause lasts until 15 minutes after the latest refusal, then permits a fresh attempt.
Take five refusals spread over five days, the newest a minute ago, with no progress between them. The required decision is to refuse the next write. A candidate that reads only the last hour sees one refusal. Its cheaper read has changed the permission decision.
This gives the reviewer something sharper than “look for edge cases”: one obligation, a concrete history and two different answers.
Correctness: follow the behaviour
Correctness asks whether the optimized reader makes the same decisions as the original. It also follows rotation and recovery: can yesterday’s file hide a previous post, or can a malformed line make good history disappear?
A useful finding connects an obligation, evidence and a consequence.
For the one-hour candidate, the finding can say: the breaker must retain a five-refusal run; this history makes the full reader refuse while the candidate permits; another unsuccessful write can proceed. The remedy is to continue reading until the failure counts are determined, with a full-read fallback when the bound cannot establish them.
The reviewer can ask the worker to add the reset case too. A successful entry between the older refusals and the current request ends the run. Both cases matter to correct behavior.
Security: follow the authority
Security asks whether the change preserves authorization, trust boundaries and data handling. In this case, an incomplete history can permit a write that the safeguard should deny. The reviewer traces the credential, content checks and recorded state supporting that permission.
Security is a separate required review for risk-classed changes, including public-repository changes under the current procedure. It has a separate verdict. A correctness approval cannot supply that verdict, and security approval cannot erase an unresolved correctness finding.
The old-refusal defect can therefore matter to both reviews. It needs one repair item carrying both kinds of evidence, while each required review remains responsible for its own result.
Performance*: examine the work required
Performance examines equivalent behavior and the cost of obtaining it: bytes read, repeated parsing, memory, lock contention and elapsed time on a defined workload.
The ledger contract requires a guard median below 50 milliseconds on a planted ledger of at least 100 MB. Its historical verification reports roughly 905 milliseconds for the full read and 0.16 milliseconds for the bounded read on a 109 MB fixture. A separate byte-count test checks growth behavior.
Those observations concern the guard. Deskpost still performs a full-history read for duplicate prevention, then posts and confirms the review. A performance assessment of the entire command would measure those stages too.
Planning is the earliest useful place to ask this question. An hour-only cutoff is cheap and wrong for the refusal run. A valid stopping rule reduces work only after the required answer is established.
Architecture*: examine ownership
Architecture compares the change with the approved direction. It examines ownership, dependencies, migration steps and temporary mechanisms.
Here the ledger remains authoritative. All readers learn to traverse daily segments. Adding a second fast store for “already posted” would introduce another owner that must be synchronized, recovered and reconciled.
That is a concrete design question: does the second store earn its coordination cost, and how does it preserve the ledger’s meaning? The answer differs from whether the current candidate passes the five-refusal check.
*Performance and architecture reviews are planned.
Follow a finding through repair
Suppose the first candidate uses the hour-only shortcut. The reviewer supplies the five-refusal counterexample. The worker changes the stopping condition so it waits for the budget window and both failure counts: the run for this tool and target, and the backstop run across all targets for this tool. If the resource cap arrives before those answers are known, it falls back to the full reader.
The repair returns with comparison tests for the long refusal run, an intervening success, ignored events and the fallback. Re-review checks the new candidate and its evidence. It also checks that yesterday’s remembered post survives rotation.
The security and correctness observations remain one underlying defect. Deduplication avoids making the worker repair it twice; it does not combine the required verdicts into one vote. Each applicable review answers for the revised candidate. An outstanding required objection keeps the candidate from becoming ready.
The review desk then considers the current reviews, CI and mergeability. A human owns merge in the ordinary flow. If the finding instead exposes a missing requirement, the brief’s owner must settle that requirement before worker and reviewer can agree on success.
Evaluate the value of extra review
Compatibility, accessibility, factual accuracy and consumer workflows can deserve focused checks. Start with the uncovered question, the evidence available and the action its answer could change.
Review methods improve too. Claude Code’s review service checks candidate findings against the code before deduplicating, ranking and posting them. That suggests a specific experiment in finding validation. The continuing-improvement article examines how to compare such refinements with the existing review.
Judge an added review by substantiated additional findings and missed problems, alongside the repair and human effort it causes. A long list of objections is activity; a demonstrated contract violation gives the worker something useful to fix.
An engineering lead can use this without Assay: require the reviewer to show the obligation, input, observed mismatch and consequence, then follow the repair to the revision being accepted.