Short answer
For a coding agent to fix its own failing CI and review comments, three things have to exist: something that watches the pull request, a record of which agent session owns it, and a way to deliver the failure or comment into that session. Most agent apps show you CI status and leave the next step to you, or give you a button. Orchestrator.inc (formerly Agent Orchestrator) does the delivery without a click: it polls GitHub and GitLab, and when a check fails, a reviewer requests changes or the branch conflicts, it tells the agent that owns the PR. Merging stays your decision.
What "autonomous" should mean
| Step | Who does it in a good loop |
|---|---|
| Open the PR from a worktree branch | The agent |
| Notice a failing check | The tool, by polling the Git host |
| Send the failing check names, links and log tails to the right session | The tool |
| Read the failure, fix, push | The agent |
| Notice requested changes or unresolved comments | The tool |
| Address each comment and push | The agent |
| Rebase when the base branch moves and the PR conflicts | The agent, prompted by the tool |
| Decide to merge | You |
The rows that break when you do this by hand are the middle ones: noticing, and routing to the right session out of many.
The problem in practice
You have five agents, each with an open PR. Over lunch, two PRs fail CI, one gets review comments and one falls behind main and conflicts. None of the agents knows. When you get back, you check each PR on GitHub, work out which session wrote it, and paste in the failure or the comments. The agents could have fixed all four in the time it took you to notice them.
The manual way
With one agent you can run the loop yourself with the GitHub CLI:
gh pr checks --watch # wait for CI on the current branch
gh run view --log-failed # read the failing job's log
Paste the failure into the agent session that owns the branch and ask it to fix and push. For review comments:
gh pr view --comments
Paste the unresolved ones into the same session.
Where the manual way gets expensive
- You are polling. Nothing tells you a check failed until you look.
- With several agents you have to remember which session owns which PR.
- A comment fixed in one push can be pasted again by mistake, and an old failure can be mistaken for a new one.
Doing this with Orchestrator.inc
1. Every worker owns its PR
Each worker runs in its own worktree and branch, and a PR the worker opens is discovered automatically. To attach an existing PR, claim it, or start a worker on it (CI recovery):
ao session claim-pr <session-id> <pr-number-or-url>
# or start a worker on an existing PR
ao spawn --project my-project --name fix-pr-42 --claim-pr 42 --mode chat
2. Failing checks go to the owner
When a claimed PR has a new failing check, Orchestrator sends the failing check names, run links and the end of each failed job's log to the owning session, in Chat or the terminal UI. It compares the check list with the previous poll, so an unchanged failure is not resent. For the full log, the agent follows the link or uses the Git host's CLI.
3. Review comments go to the owner
When a reviewer requests changes or the unresolved comments change, Orchestrator sends the unresolved comments to the owning worker. Resolved threads drop out of the next message, and repeated deliveries are de-duplicated (review loop).
4. Add a reviewer agent
You do not have to wait for a person to review. Choose a reviewer agent in Project Settings, for example Codex reviewing Claude Code's work, and turn on automatic review; 22 of Orchestrator's 38 harnesses can review. The reviewer posts an inline comment for each change it requires, and Orchestrator sends those to the worker like any other review comment. You can also start a review by hand:
ao review trigger <worker-session-id> # start a review now
ao review ls <worker-session-id> # see the verdict
5. Merge conflicts
When the PR conflicts with its base branch, the owning session is told so it can rebase.
6. You merge
When the PR is approved and checks pass, its card moves to Ready on the board and you get a notification on the desktop and on your phone. Orchestrator never merges on its own; you merge from the desktop app or with the CLI:
ao pr merge <pr-number>
A reviewer agent's approval is not a GitHub approval and does not satisfy branch protection.
Current limits
- There is no retry budget, so an agent that keeps failing keeps receiving new failures until you step in.
- Local sessions run on your machine, so it has to be awake for the loop to run. Optional Orchestrator Cloud plans run sessions in hosted sandboxes instead.
How other tools handle it
As of October 2026:
| Tool | Failing CI | Review comments | How |
|---|---|---|---|
| Orchestrator.inc | Automatic, to the owning session | Automatic, to the owning session | Polls GitHub and GitLab; optional reviewer agent from another vendor |
| Sculptor | Automatic | Not documented | Its CI Babysitter dispatches agents at failing pipelines |
| Orca | One click | One click | "Fix broken checks" and "Resolve with AI" buttons |
| Conductor | One click | Synced into the workspace | The Checks tab forwards failing checks to the agent |
| Paseo | No CI event | Configurable | Paseo Hub triggers on PR comments and reviews, which you write yourself |
| T3 Code | Manual | Manual | PR review UI; "Work on PR" starts a chat on a PR |
| Superset, Emdash, Nimbalyst | Manual | Manual | Show PR and check state; you send the follow-up |
Best AI coding agent orchestrators compares these tools on more than the PR loop.
Frequently Asked Questions
Can Claude Code fix failing CI on its own?
Claude Code can fix a failure once it knows about it. Something has to notice the failing check and tell the right session. Orchestrator.inc does that for every worker's PR; by hand you would watch gh pr checks and paste the failure in.
Will the agent merge its own PR?
Not in Orchestrator.inc. It moves the PR to Ready and notifies you, and you merge in the desktop app or with ao pr merge.
Does this work with Codex and other agents?
Yes. Delivery goes through the session's Chat or terminal UI, so it works with any of Orchestrator.inc's 38 harnesses, and 22 of them can also act as the reviewer. The agent catalog on docs.orchestrator.inc lists them.
Does it work with GitLab?
Yes. Orchestrator.inc polls GitHub and GitLab, including self-managed GitLab, and sends failing checks and review comments from either to the owning agent.
How do I try an autonomous PR loop?
Install Orchestrator.inc from orchestrator.inc, add a repository and spawn a worker on a small issue. When its PR fails a check, the failure arrives in the worker's session without you pasting it in.