The Peer Reviewer Agent — A Second Opinion With No Shared History
How Datarim's Peer Reviewer agent runs in an isolated context to surface concerns the original session might have agreed past.
The same model that wrote a document is the worst model to review it. It knows the decisions that were made, the alternatives that were rejected, the reasoning that felt convincing at the time. All of that context makes it harder to see what is actually on the page. The Peer Reviewer agent is built around the opposite condition: it starts with no shared history.
This is not a polish pass. The agent's frame is adversarial — its job is to find weaknesses, not confirm that the work looks reasonable. It must surface at least two substantive concerns, or it must provide explicit grep evidence for each check it ran that came back clean.
What it does
The agent receives the artifact paths — a PRD, a plan, a QA report, or code — along with the acceptance criteria list and a set of drift taxonomy hints. It then checks six specific areas.
AC verification commands get scrutinized for semantic correctness, not just syntax. A command like grep -c X file confirms that a string is present — it does not confirm that the underlying contract holds. DoD claims with no attached test output are marked as unverified. Reflection documents that narrate success without diagnosing what went wrong the first time are flagged for missing the lesson. Any high-severity gap that was quietly moved to the backlog without explicit operator approval is called out as an unauthorized downgrade. The agent also checks whether the verification steps could be reproduced end-to-end by a new operator with no prior context, and whether the implementation scope drifted from what the PRD actually specified.
One concrete example
A QA report claims that an API endpoint is secured by checking that a test exists with the word «auth» in its name. The Peer Reviewer reads the test file, finds the test, and then reads the test body — and notes that the test asserts the endpoint returns a 200, but the auth header in the test is hardcoded to a valid token. The test passes whether or not the endpoint enforces authentication for unauthenticated requests. This gap gets filed as a finding; the operator decides whether to act on it before archiving.
Where it sits
The Peer Reviewer runs at /dr-verify, specifically in Layer 2 and Layer 3 of that command's tri-layer architecture. Its isolation is the mechanism: it operates on a different model checkpoint from the session that produced the artifact it reviews, which is what makes the cross-family check meaningful. It has read-only tools — Read, Grep, Glob — and cannot modify anything it finds.
See the full agent roster on the Peer Reviewer reference card, or read what Datarim is for the bigger picture.