Let an agent check its own work. It can reread the brief, run tests, and fix obvious mistakes. Just do not let that same agent decide the change is ready to ship.
Self-review and approval do different jobs. Self-review improves the change. Approval gives it permission to move forward.
Write down what the reviewer should check
An independent reviewer cannot do much if it has to guess what good looks like. Define the review before the work starts:
- what the author may change
- which tests or evidence are required
- which problems must send the work back
- who makes the final call
A playbook gives those rules a home. Wallfacer's Playbooks documentation models a process as ordered steps with a named performer for each step. It separates work, decisions, and waiting into Act, Decide, and Wait steps.
Give the reviewer the full brief, the full change, and the results of every required check. A summary from the author is not enough.
Use a different approver
GitHub already enforces this rule for people. Pull request authors cannot approve their own pull requests. For Copilot cloud agent, GitHub also prevents the agent from approving or merging its pull request. The person who asked the agent to open the pull request cannot approve it either.
Give an agent reviewer a simple job: read the work, approve it, or send it back. Do not let the reviewer edit the change itself. Google's code-review guidance uses the same split. The reviewer explains the problem and why it matters; the author makes the fix.
If the reviewer rewrites the work, it becomes an author. The rewritten part still needs approval from someone else.
A separate reviewer can still miss a bug. The point is to keep the author from waving its own work through.
A useful reviewer needs permission to say no
Intercom makes this separation concrete. Claude writes the code. Separate sub-agents review the problem, intent, safety, logic, and engineering practices. The reviewer also rejects large pull requests and asks the author to split them.
Intercom tested the system against production outcomes. Its controlled pilot covered more than 100 pull requests. Intercom reports zero reverts of AI-approved changes and a 6–16x improvement in p75 time to approval. During the first four weeks of the wider rollout, 497 pull requests went from agent authorship through automated approval and into production.
Those results come from Intercom's codebases. The useful lesson is how they rolled it out: separate the roles, let the reviewer reject work, record each decision, and check the result in production.
Have a person review the finished result
Start with a person approving the finished change. For code, that means the pull request, its tests, and its review record. For a content track, it means the main post and every email or social post built from it.
The reviewer can then see whether the parts agree and whether the whole thing is worth shipping. They do not need to inspect every agent step along the way.
Once an automated reviewer performs well on one clearly defined kind of work, a person can review fewer cases. Intercom still lets any engineer request human review and keeps the person who ships responsible for watching production and rolling back.
Split one workflow into three jobs
Pick one agent-authored workflow and add four rules:
- The author writes and fixes the work. It may self-review. It cannot approve.
- The reviewer gets the brief, the complete change, and the check results. It may approve or request changes. It does not edit.
- The author handles the feedback. Any change sends the work through review again.
- A person approves the complete result until production results support automating more of the approval.
Use the author-never-approver control as a checklist, then write the three jobs into one playbook before its next run.