Codi-E mascot - teal character with glasses and laptop

Codi-E Blog

How The Rig Reviews Code: Meet Review-E

When an AI agent opens a pull request, who reviews it? In The Rig — our agent orchestrator — another agent does. Its name is Review-E, it reviews in character, and a change doesn’t merge until four gates pass.

· 7 min read

Our agents write a lot of code. iBuild-E builds iOS apps, Volt-E handles infrastructure, and others open pull requests across dozens of repositories every week. That raises an obvious question: you can’t let an agent merge its own unreviewed code — so who reviews it?

In The Rig, the answer is another agent. Review-E reads every agent-authored pull request and either approves it or requests changes — held to the same gates a human reviewer would face. And it does this without a single per-repo workflow file: The Rig owns the whole lifecycle centrally, from “PR opened” to “merged.”

Here is how a change travels that path, and what has to be true at each step.

Who reviews the AI’s code?

When an agent finishes a task, it opens a pull request like anyone else — a branch, a diff, a linked issue. The temptation is to let it merge straight away. We don’t. An unreviewed change from an autonomous agent is exactly the kind of thing that should get a second pair of eyes.

So The Rig routes every agent-authored pull request to a dedicated reviewer agent, Review-E, before anything merges. Review-E isn’t a linter and it isn’t a rubber stamp — it reads the change in context and makes a call, the same way a human reviewer would. Human-authored pull requests stay outside its scope; Review-E reviews agent code.

The review flow, end to end

Every pull request follows the same path. There are two checkpoints — an intake gate when the PR arrives, and a merge gate before it lands — with the review itself in between.

  1. A pull request opens. An agent pushes a branch and opens the PR against the repo.
  2. The Rig is notified. A webhook tells The Rig a PR is open. It normalizes the event and runs the intake checks.
  3. Intake gate. Before any review work is queued, The Rig confirms the basics: the PR links an issue, and it carries the required labels. Miss those and it’s sent back before a reviewer ever looks at it.
  4. Review-E is assigned. The Rig hands the pull request to Review-E.
  5. Review-E reviews. It reads the diff in character (more on that below) and posts a verdict: approve, or request changes.
  6. Merge gate. The change only merges when all four conditions hold. The Rig enforces them and merges automatically.

The diagram at the top of this post is that flow in one frame: Pull Request → The Rig → Review-E → Merge → Merged, with the two gates underneath.

Meet Review-E: a reviewer with a persona

The part that surprises people: Review-E reviews in character. Like the other characters in our lineup, it runs from a persona — a personality prompt that shapes how it reads code and how it phrases feedback. It’s a reviewer with a point of view, not a generic bot.

But personality isn’t the whole story. For each pull request, Review-E reads against four things:

  • Its persona — the character prompt that defines its reviewing voice and priorities.
  • Your conventions — the repo’s CLAUDE.md / AGENTS.md, so it reviews to your rules, not generic ones.
  • Prior memory — what it has learned reviewing this codebase before.
  • The acceptance criteria — what the linked issue actually asked for.

Then it does what a human reviewer does: approve, or request changes with specifics. Because it reads your conventions and the issue’s acceptance criteria, the feedback is grounded in your project — not a one-size-fits-all checklist.

The four gates before merge

A green review isn’t enough on its own. The Rig holds every change behind four gates, and all of them have to pass:

Review approvedReview-E approved the change (no outstanding “request changes”).
CI greenThe test and build checks all pass.
Threads resolvedEvery review conversation is resolved — nothing left hanging.
No manual holdNo manual-merge label asking a human to take it from here.

When — and only when — all four are true, The Rig merges the pull request automatically. No one clicks the button. If any gate fails, it waits.

Why it’s centralized

The old way to do this was a pair of workflow files in every repository — one to request a review, one to auto-merge. It works, but it doesn’t scale: the same logic is copy-pasted into every repo, and the copies drift out of sync the moment you change anything.

The Rig pulls that logic into one place. There’s a single owner of “PR opened → reviewed → merged,” and every repository inherits it. Add a new repo and it gets the same review and the same gates on day one — with nothing to copy and nothing to keep in sync.

The 30-second version

Prefer to watch it? Here’s the whole flow in half a minute.

Run the Docs · “How The Rig reviews code” (30s).