Review loop

Reviews are the part of code review that most agents get wrong: they treat them as one-shot, so the reviewer ends up repeating themselves. AO closes that loop — when a REQUEST_CHANGES review lands, the agent sees the review body and the inline comments in context and pushes a fix.

What triggers it

The SCM plugin watches your PR for:

• A new review with state CHANGES_REQUESTED
• New comments on an existing review
• Line-level comments ("inline comments")

When any of these appear, the session transitions to changes_requested and the agent is woken with the full review body + all unresolved inline comments.

What the agent sees

A single structured prompt with:

• Reviewer's top-level message (the review summary)
• Each unresolved inline comment, formatted as path:line — comment
• A pointer to the PR head SHA

Configurable behavior

reactions:
  reviewRequested:
    enabled: true           # default
    includeResolved: false  # default: only unresolved threads
    maxRetries: 3

maxRetries matters more than you'd think — occasionally a reviewer and agent will disagree about the right fix, and you don't want the agent stuck in a loop.

Manually replay a review

# Check all tracked PRs now
ao review-check

# One project
ao review-check myproject

# Dry run: show who would get nudged
ao review-check --dry-run

Best practices

• Use inline comments for mechanical changes. "Rename this variable", "move this into a helper" — agents handle these well.
• Use the top-level review message for design-level feedback. Agents are better at responding to a coherent paragraph than to a dozen small inline nits.
• Resolve threads as they're addressed. Keeps the agent's next nudge focused.

Approvals

An APPROVED review doesn't trigger the agent — it transitions the session toward mergeable. AO never auto-merges; that's your call.

Automated review (bugbot) detection

Not every review comment is from a human. AO recognises a hardcoded list of known automation accounts and routes their comments to the separate bugbot-comments reaction instead of changes-requested. This lets you handle them differently — for example, treat advisory bot feedback as informational while still requiring a human approve before the agent acts on it.

GitHub (scm-github) treats the following as bots:

GitLab (scm-gitlab) treats the following as bots (in addition to any username matching project_\d+_bot or ending in [bot]):

A typical configuration pairing:

reactions:
  changes-requested:
    auto: true
    priority: "action"       # human review comment — act immediately

  bugbot-comments:
    auto: true
    priority: "info"         # advisory bot feedback — log and proceed

The bot list is hardcoded in each SCM plugin and is not currently configurable via agent-orchestrator.yaml.

Review polling throttle

To avoid hammering the GitHub / GitLab API on busy repositories, AO throttles getPendingComments and getAutomatedComments calls to at most once every 2 minutes per session (REVIEW_BACKLOG_THROTTLE_MS = 2 * 60 * 1000). The throttle is in-memory and resets on daemon restart.

Practical consequence: after a review comment lands on the PR, there can be up to a 2-minute delay before AO reacts. This is expected and by design.

If you need an immediate check outside the polling cadence, run:

ao review-check           # check all tracked PRs right now
ao review-check myproject # one project only
ao review-check --dry-run # show what would be sent, don't send

ao review-check is a standalone CLI command that calls the GitHub API directly and is not subject to the in-process throttle.