Orchestrator: Agents Take the Next Issue While You Review

Last week, we added a Start with button to every issue in Origin.

Pick an issue, choose Claude Code or Codex, press Start, and the agent runs headlessly on your machine. It gets its own Git worktree, works through the task, and opens a pull request when it is done.

That workflow worked well, but it also made the next bottleneck obvious. Agents were ready to work, yet they still spent most of the day waiting for one of us to open the issue list, decide what should run next, choose an agent, and press the button.

So we automated that part too.

Origin's Orchestrator now watches the issue queue on a schedule. It finds work that is actually ready, takes issues by priority, assigns each one to the agent most likely to finish it, and starts the run automatically.
Once a PR opens, reviewer agents take over. If they request changes, the coding agent gets another round on the same branch. When every required review passes, the run stops at Ready to merge.

Final merge still belongs to a person.

On the first live day in our own workspace, Orchestrator handled 43 runs and produced 21 PRs ready to merge.

Orchestrator in our own workspace after its first live day: 43 runs and 21 PRs ready to merge.

How AI Agent Orchestration Picks the Next Issue

By default, Origin checks selected repositories every 10 minutes instead of simply grabbing the first open issue.

Before an issue enters the execution queue, several conditions have to be true. Nobody else can already own it, every dependency must be closed, and the issue has to match configured filters such as type, labels, and maximum priority.

Work that clearly should not be handled by a coding agent gets skipped.
We added that filtering after seeing what happened on our own issue list. During the first live day, Orchestrator picked up three issues starting with “Verify…” and another that said it “waits on the replay benchmark.” Each one occupied a slot for roughly 15 minutes before the agent reached the pre-start check and asked for clarification.

Those were valid issues, just not actionable coding tasks.

Origin now leaves them out, along with anything marked [Postponed].

Once the ready queue is clean, Orchestrator fills available execution slots. You control how many AI agent runs can happen at once we use two and can also set a daily budget or restrict automated execution to a specific window, such as overnight.

One additional rule keeps the queue balanced: Origin will not start more than one new issue per agent during the same check. Otherwise, one high-performing agent could consume the whole queue before other available agents get a chance to run.

How Origin Chooses the Best Coding Agent

Only agents that can actually run are considered.

For local agents, the required CLI has to be installed and signed in on one of your machines. Cloud agents such as Copilot, Cursor, or Devin need the corresponding credentials.

Once eligible agents are known, Origin scores each one against the issue.
Three signals determine the assignment:

• 60% historical completion rate. Origin looks at how often the agent has successfully finished the same kind of work, such as bug fixes, features, refactors, or chores. Task-specific performance is used once at least three relevant runs exist. Otherwise, Origin falls back to the overall rate. With fewer than three runs total, the agent gets a neutral score rather than a fabricated success rate.

• 25% your agent order. Your own preference still influences the result. If one agent is ranked first in the workspace, Origin takes that into account.

• 15% billing model. An agent already covered by a subscription gets an advantage over one billed per token.

Origin also shows why it picked a particular agent. One of our bug-fix runs, for example, was assigned to Claude Code with this explanation:

100% of 10 runs on bug fixes finished · #1 in your order · on a subscription (max) · on Artems-MacBook-Pro.local

Completion rates come from the same run history already visible on the issue page. As Claude Code, Codex, or another agent completes or fails more tasks, future assignments use that updated history. In practice, routing improves as the workspace accumulates real run data instead of relying only on static preferences.

Dry Run Before Automated Execution

You do not have to hand the queue over to Orchestrator immediately.
Dry run uses the same scheduling and agent-selection logic, then writes each planned assignment and its reason to the activity feed without starting anything.

That makes it easy to watch several checks and compare Origin's choices with what you would have picked manually. If the routing looks sensible, switch to Live.

What Happens When an AI Agent Run Starts

In Live mode, an issue assigned to a local agent is queued for one of your machines.

Origin's existing review runner - origin review runner - claims the job and executes the same command behind the manual Start button:

origin issue start --agent claude --background --force
Because Orchestrator uses the existing issue-runner path, all the same safeguards still apply.

Every task gets its own Git worktree. Origin checks that the selected agent is signed in, runs a pre-start check to make sure the task is clear enough, applies a time limit, and expects the run to produce a pull request.

Code stays on your machine and runs through your existing agent account.
For supported cloud agents, Origin starts the task through the provider using the same prompt that the manual Start dialog would have sent.

Queue handling also includes a couple of failure protections. If no runner picks up a queued run within 30 minutes, it expires. If a run starts but fails, Origin removes that issue from the orchestration plan for six hours instead of retrying the same broken launch every 10 minutes.

Automated Pull Request Review and Fix Rounds

Opening a PR does not end an orchestrated run.

One of Orchestrator's PRs: Codex fixed a security alert, three reviewer agents approved it, then a person merged it.

Once the PR reaches Origin, the run moves to In review and every reviewer agent configured for that repository receives it.

If all required reviewers approve the change, the run moves to Ready to merge and Origin sends a notification. Automation stops there; someone on the team still decides whether the code should actually be merged.

When a reviewer asks for changes, Origin collects the findings into one fix issue and sends it back to the same coding agent on the same branch.
After the agent pushes its fixes, the PR goes through review again. Only reviews against the new commit count, so approval from an older version of the code cannot carry over after the branch changes.

You can also decide how many automated fix rounds an agent gets. Default is one, with a maximum of three.

If reviewers still request changes after the final round, the fix fails, or reviewers do not finish, Origin moves the run to Needs you.
Every run therefore ends at one of two useful human checkpoints:

• Ready to merge - implementation is complete and reviewer agents approved the current commit.

• Needs you - something in the execution or review loop needs a person to step in.

That is the boundary we wanted to keep. Orchestrator handles issue execution, pull request review, and fix cycles without making the final shipping decision for you.

Activity feed and Orchestrator settings: fix rounds, two concurrent runs, a 10-minute check interval, and a $30 daily budget.

What Happened on the First Live Day

We switched our own workspace to Live on October 29. Setup was deliberately small: Claude Code and Codex on one MacBook, two simultaneous runs, and a $30 daily budget.

By the evening, Orchestrator had started 43 runs. Claude Code handled 20, and Codex handled 23. Not every run worked, and that was probably the most useful part of the test.

• 25 runs opened a PR. Twenty-one were approved by reviewer agents and waiting for merge. Two had already been merged, and we closed another two ourselves.

• 14 runs ended without a commit. Agent inspected the issue but changed nothing. Some tasks had already been completed by an earlier PR. Others were too vague to act on, including one literally titled “change it - I don't know how.”

• 4 runs stopped during the pre-start check. Those were the “Verify” and “waits on” issues mentioned earlier. Instead of guessing, agents asked for clarification. Those runs are also why the current filters exist.

Running Orchestrator on our own development work exposed product bugs too.
One run finished before its PR reached Origin, which caused the review step to be skipped. Another problem involved an optional reviewer: three PRs remained in review for roughly an hour because the runner processed required reviewers first.

Both issues were fixed the same day. More important, though, was what the experiment showed about the queue itself. Roughly a third of our issues were not real, actionable coding work.

Some were outdated. Some had already been solved elsewhere. Others were too vague or blocked by work that had not happened yet.

AI agent orchestration makes this visible quickly. Even a strong coding agent cannot do much with an issue that should not have entered the queue in the first place.

Orchestrator works best when the issue list contains work that is actually ready to be done.

What Orchestrator Will Not Automate

Orchestrator has explicit boundaries. It will not merge a pull request. Runs stop at Ready to merge or Needs you.

Local-agent code does not execute on Origin's servers. Local coding agents continue to run on your machine, while cloud agents execute through their own vendors.

Configured limits are also hard boundaries. Orchestrator will not exceed the number of concurrent slots, go over the daily budget, or launch new work outside the execution window.

Duplicate starts are blocked as well, including cases where two Origin workspaces share one repository.

This is not meant to be an unrestricted autonomous coding loop. What makes sense to automate is the repetitive coordination between a ready issue and a reviewed pull request, while the team keeps control over what actually ships.

Start With Dry Run

You need three things to try Orchestrator:

Origin CLI, at least one supported agent CLI signed in on your machine, and the Origin runner:

origin review runner

Open Orchestrator in the sidebar, select the repositories it should watch, choose the issue types it can pick up, order your agents, and configure concurrency, budget, and scheduling limits.
Start in Dry run and watch a few checks in the activity feed.

You will see which issues Origin would start, which agent it would assign to each one, and the reasoning behind every choice.

If those assignments look right, switch to Live.

From there, Origin keeps ready work moving through AI agent assignment, implementation, pull request review, and fix rounds while your team stays focused on decisions that still need human judgment.

Try Origin and put Orchestrator to work on your issue queue.