Merge Queues Explained: Keeping CI Green at Agent Scale

A merge queue is a gate between approved and merged. Instead of landing a pull request the moment someone clicks merge, the queue builds a temporary version of the target branch that includes your change plus every change queued ahead of it, runs CI against that combination, and only merges when the combination passes.

The reason it exists is a gap most teams discover the hard way: the code CI validated on your branch is not the code main becomes. Your pull request passed against the main that existed when you branched. By the time you merge, other changes have landed, and nothing has tested your change against them.

The failure mode is racing green PRs. Two pull requests are open, both pass CI, both get approved. One renames a function; the other adds a new call to the old name. There is no textual conflict, so git merges both without complaint, and trunk is now broken even though every check on every PR was green.

GitHub's older answer was the "require branches to be up to date before merging" rule, which forces you to rebase onto latest main and re-run CI before merging. It works, but manually: with ten PRs in flight, whoever merges first invalidates the other nine, and each author updates and re-runs by hand, then races to merge before someone else lands. A queue automates exactly that loop.

GitHub's merge queue has been generally available since 2023, and one cycle through it looks like this.

1. 1A pull request passes its required checks and gets approved. Instead of merging, you click "Merge when ready," which adds it to the queue.
2. 2GitHub creates a temporary branch (prefixed gh-readonly-queue/) containing the latest target branch, your change, and every change queued ahead of yours.
3. 3CI runs against that temporary branch, triggered by a merge_group event, so what gets tested is exactly what main would become.
4. 4If checks pass, the PR merges in first-in-first-out order. If they fail, the PR is removed from the queue and the temporary branches behind it are rebuilt without the failed change.

The removal step is the clever part. A failure doesn't jam the queue; the failed change is ejected and everything behind it revalidates against a combination that no longer includes it. The queue also has knobs worth knowing before you turn it on.

The racing-green-PRs problem scales with how many changes are in flight at once. A team of humans might hold ten open PRs; a team running parallel agents can hold fifty, opened faster than anyone merges them. Every extra in-flight change makes every branch's CI result staler by the time it lands, so the combination failures a human team hits monthly become a daily event, then an hourly one.

That is why the queue shows up in every serious pitch for agent infrastructure, including Origin's. Coverage of Cursor's Compile demo framed Origin around throughput no human team produces, a claim of 22.6 commits per second into one repo. At anything like that pace, "rebase and re-run before merging" is not a policy a person can execute. Something has to serialize the landings and validate the combinations, and that something is a queue.

There is a cost to name too. Once every merge flows through the queue, the queue is your merge capacity: CI time per group and group batching set the ceiling on how fast anything lands. Grouping helps (GitHub can validate up to 100 PRs in one group), but a slow test suite becomes a slow queue, which is a good reason to fix the suite before the volume arrives.

Origin is built by the Graphite team, and Graphite already ships a merge queue for its stacked-PR workflow; its announcement of the Cursor deal named the stacked PRs platform and merge queue as things it will keep investing in. Coverage of the Compile demo went further, describing Origin queues that keep CI green and automated fixes for failing builds. The expected shape is a stack-aware queue: one that understands dependent changes landing in order, not just independent PRs.

Where you can actually get a queue today is a shorter list than the coverage suggests, so here it is.