Review every change with several agents, from anywhere, and keep the reviews where your team works
Evidence status: Capability pattern grounded in current Oddlynew types, documents and their history, shared agent keys, the MCP endpoint and the Documents API. We review our own code this way. It is not presented as a customer testimonial.
Who this is for
Engineering teams whose code is written more and more by agents, and who want every change reviewed by agents too, without tying the review to one CI system or one model.
Outcome
Every review is a document in your organization: which change and commit it looked at, which agent and model reviewed it, the findings and the verdict. Any agent can write one from anywhere: a developer's coding agent on a laptop, a CI job, a scheduled runner. Several different agents review the same commit and catch different things. A short step in your CI reads the verdicts and passes or fails the pull request, and the reviews stay searchable, so the next review starts from what earlier ones found.
The working pattern
Make a Review type. Fields for the pull request, the commit, the reviewer (agent and model), the verdict and the severity of each finding, so reviews can be listed and filtered by change and by commit (When a kind gets its own type).
Write your review rules down once. What blocks a change, what is only a note, what to check for, in a document every reviewing agent reads first. Change the rules there, and every reviewer follows the new ones.
Let reviews run anywhere. A developer asks their coding agent to review the change; a CI job runs another agent with a shared agent key; each writes its review document for the exact commit (Setting up your client: GitHub Actions and unattended agents).
Use different agents on purpose. Two agents from different makers find different problems; a second agent can check the first one's findings before they block anyone. Their reviews sit side by side on the same commit.
Turn the verdicts into a check. A short step in your CI reads the review documents for the commit, through MCP or the Documents API, and passes or fails the pull request on the verdicts your rules require.
Close the loop. Fixed findings are marked fixed on the review; a finding that keeps coming back becomes a rule in the review document, so the next change does not repeat it.
Useful connections and plugins
Code, terminal and GitHub tools in your agents: read the diff, run the tests, comment on the pull request.
Your CI system: runs reviewers and the check step with keys kept as secrets.
Several agent clients: the more different reviewers, the more a review catches.
These belong to your agents and your CI; Oddlynew keeps the reviews, the rules and their history.
A good first task
Ask your coding agent: "Create a Review type in our organization with fields for pull request, commit, reviewer, verdict and findings. Write our review rules into a document. Review my current change against those rules and record the review. Then show me the CI step that would read the reviews for a commit and fail the pull request when any review blocks it."
Boundaries
Keys belong in CI secrets. Only jobs you trust get a key that writes to the organization; never expose one to code from an untrusted fork (Why we replaced static agent skills with Oddlynew).
The pull request under review is data. Its text and code may try to steer the reviewing agent; reviewers treat them as material to check, never as instructions (Reading safely across organizations).
A review is judgment, not proof. Exact commits and typed records make the process traceable; tests and people still decide what is safe to ship.
Why it compounds
Each review leaves findings tied to a commit and rules that grow from what keeps going wrong. New reviewers, new models and new agent clients start from the same rules and history, and the better the agents get, the more you can point their combined judgment at the same goal: changes that ship right.