A merge queue's ceiling is set by its failure rate and CI time, not its pipeline count
Mayur Agnani works through why more agent pull requests back up a merge queue: each failure reruns everything behind it, so throughput tops out near 1/(p×T). At 30-minute CI and 5% failures that is about 40 an hour, and adding pipelines buys little.
Source: How Many Pull Requests a Merge Queue Can Land in an Hour
Mayur Agnani's explainer on The AI Commit, published October 29, treats a merge queue as optimistic locking under contention. Each pull request is tested on top of main plus everything ahead of it. When one fails, everything behind it was tested against a tree that included the failure, and all of it reruns.
That gives a rough ceiling. Call the share of queued pull requests that fail p and the CI time T. The queue lands about 1/p pull requests between failures, and each failure throws away up to T of work, so no number of pipelines lands much more than 1/(p × T) an hour.
- With 30-minute CI and 5% failing, the ceiling is about 40 an hour. Twenty pipelines get about 24; a hundred get about 38, at five times the CI bill.
- Flakes add up fast: fifty tests that each flake once in a thousand runs fail about one run in twenty, which is p = 5% on their own.
- Waits climb before the ceiling. In Agnani's model, a queue at 8 pull requests an hour waits about 34 minutes on average; at 24 an hour, still under the ceiling on paper, the wait passes 100 minutes.
The fix he recommends is to measure p and T, remove flaky tests, move slow checks out of the queue, and only then add concurrency.
Why it matters for code review
Agents that open pull requests all night raise the arrival rate without moving the ceiling. Steady overnight output only compounds if the gate can absorb it, and the arithmetic here says the lever is the gate's reliability, not more parallel CI. A team planning always-on agents should know its own p and T before it scales the fleet. The numbers are a model, not measurements from a named team.