How to Build a Pull Request Review Agent

A pull request review agent starts from a clear trigger and ends with a handoff a person can check. The steps below cover that path, and the code shape after them lists the fields one run needs.

1. 1Define the trigger: issue, PR, failed CI job, docs change or support ticket.
2. 2Limit tool access to the files and systems the agent needs.
3. 3Add a plan step before writes.
4. 4Run checks and produce a short reviewer handoff.
5. 5Log the prompt, changed files, commands and result.

type AgentJob = {
  task: string;
  context: string[];
  allowedTools: string[];
  checks: string[];
  handoff: "diff" | "comment" | "pull_request";
};

Decide allowedTools first. While you build, broad access is tempting, because narrowing it is fiddly and everything works when you are watching. An agent that runs unattended with write access to the whole repo and a shell is a different kind of risk from one that can edit three paths and run a single command. You find out which one you built on the run where something goes wrong.

handoff decides whether people will trust the agent. For an agent that changes code, returning a diff keeps a person in front of every change before it lands, which is the right default while you learn how the agent behaves on your codebase. A pull request keeps the same gate with less friction once you have more confidence in the agent.

A comment is the lightest handoff and suits agents that only diagnose. Whichever you choose, don't let the agent merge until the commands in checks are ones you would have run yourself.

Most failures here are ordinary. The agent gets too much room, or someone trusts a "done" that no test proved.

Scope problems show up first. Give an agent a vague task and it will find related work to do, which looks like initiative until you face a diff across twenty files and can't tell which changes were the point. Narrow the task instead: name the files, name the behavior that should change and say what is out of bounds. A stronger model won't solve a scope problem.

Weak checks show up last and do the most damage. An agent reports success from its own reading of its own work, and nothing outside it says otherwise. If the agent's summary is the only thing between its work and your main branch, you have no review step. Give it a command whose exit code you trust, and fail the run when that command fails.

Check what Cursor already ships before you build. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. reviews pull requests for bugs, and a side project is unlikely to beat a shipped product at generic bug-finding on a diff.

Routing ships too. PR Routing & Approval, which you set up in Automations, assigns reviewers based on code ownership and commit history. It can also approve low-risk pull requests that meet criteria you write. Cursor says it does not replace a full code review.

Build only what those products don't cover. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. and Automations aren't included on Free, Plus or the legacy Start plan, so on those plans the whole build is yours. PR Routing & Approval supports GitHub and Origin repositories only, so a team whose code lives elsewhere still has to build its own routing. Both products also take rules and criteria specific to your repository, so read their settings before you decide that a check needs custom code.

Whatever you build, plan the delivery. Findings that live only in a comment thread go stale. A tool or MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server that files them in Slack or your issue tracker is a small piece of plumbing, and it decides whether anyone acts on them at all.

A short comment that points at the risk and at the proof, and by default nothing else. An agent that rewrites the PR hands the reviewer a second diff to review on top of the first.

Give yourself a way to tell whether the agent is working. Cursor's Security Agents track three numbers: vulnerabilities found, issues fixed and a resolution rate. To decide whether an issue was fixed, Cursor has a model review the incremental diffs. Copy that shape, even crudely: log each finding, look at the next push and count what got addressed.

Watch the share of comments that lead to a change, not the number of comments. A review agent whose findings nobody resolves is spending usage without improving the code.

Start with the pull-request trigger. It covers every pull request opened in the repo itself and doesn't depend on anyone remembering to run it. Pull requests opened from forks are the exception: pull request triggers don't run on them. A pre-push run is cheaper, but anyone can skip it, so it makes a good habit and a weak guarantee.

Filter the trigger either way, so a run doesn't fire on every pull request in the repo. On GitHub, a Pull request label changed trigger runs only when a specific label is added or removed, which lets reviewers opt a pull request in.

The governance line matters more than the code. Don't let an automation merge on its own: have its code change arrive as a pull request that a person reviews, so whoever clicks merge is accountable for it. The new exposure is who can start a run. Don't wire a code-touching automation to an audience you wouldn't give write access to the repo.

On a team, check the automation's Share settings as well. Run as decides whether it works with your credentials or as its own service account, and Access decides who can view it or edit it.

If you build on the SDK instead of Automations, change the defaults first. A local SDK agent runs every tool call without restriction, because a headless run has nobody to approve it. Turning on local.sandboxOptions keeps its shell commands' writes inside the working directory and temp folders, and blocks outbound network unless you allow a host. Turning on local.autoReview routes tool calls through Cursor's Auto-review classifier, which Cursor calls best-effort and not a security boundary. Keep the human review before merge either way.