Engineering laneLands cleanly
Six sessions finish at once. One release lands them all.
When several sessions finish within minutes of each other, every merge makes every other branch stale. Releases gathers the pull requests that are ready, verifies them together once and moves main. One that conflicts is rebased and put back in line.
- 34% → 16%
- of pull requests needed a rebase
- 2.02 → 1.42
- CI runs per pull request
- 13.6 → 8.9
- ejections per 100 assembled
- 17.4 → 20.2
- pull requests landed per day
onMain's own repository. Before: Releases landing one pull request at a time, 50 pull requests, 25 to 27 September 2026. After: Releases batching, 76 pull requests, 27 September to 1 October 2026. Computed from the committed snapshot, never typed.
The problem
Agents made writing the change fast. Landing it became the queue.
Building onMain with three to six sessions at once, every merge made the other branches stale, and every rebase started another full check run. Landing one pull request at a time, each landed plan cost about 500 billable CI minutes.
How Releases works
A session marks its work ready and walks away.
- 1Hand offA session whose pull request is green labels it ready and ends. Nothing waits on the landing.
- 2GatherReleases waits until nothing new has been marked ready for five minutes, twenty at most.
- 3AssembleEach ready pull request is merged onto main in order. One that conflicts is set aside, rebased onto the new main and put back in line.
- 4Verify onceThe whole suite runs one time on the batch. If it fails, the batch is halved until the culprit is found.
- 5Landmain moves to the commit that passed, and each landed pull request is told which one.
What it guarantees
main only moves to a commit the whole suite passed.
Releases will not move main to a commit that was not checked, and it will not overwrite main if main moved during the run.
Your agents drive it. A session hands off through the MCP and ends; nobody watches the queue.
Part of your guardrails
The last gate before the result is checked.
Releases is a gate at landing. With the gate system, it also checks what your guardrails asked for before a change lands, and the result is checked against what was meant after it does.
Handed off
- Plan challenged before the build
- Pull request green, labelled ready
Lands cleanly
- Nothing lands unless the whole suite passed
- Tests linked to the acceptance criteriatest_linked · acceptance_verified
- A review recordedreview_recorded
The result
- Checked against what was meantintent_verified
- What you learn becomes the next idea
Questions
What people ask first.
How is this different from GitHub's merge queue?
The guarantee is the same: only what passed is merged. Releases checks a whole batch in one run, so there are fewer CI runs when a batch passes, and it runs where the merge queue isn't offered, such as private repositories on GitHub's Team plan.
Landing takes longer. Is that a problem?
The gather window adds minutes: the median from ready to merged went from 26 to 55. Nobody waits on it, because the session ended when it handed off.
Does landing deploy?
That's your product's call, written in its fill of the Standard. On our own sites a green landing dispatches the deploy; a rollback stays a person's decision.
When can I run it?
Now. Releases is in every edition, and it runs on GitHub Actions and CircleCI.
Part of the engineering lane
Clear work in. Clean releases out.
Releases is how the engineering lane lands parallel work without a pile-up. The product lane decides what's worth building; the engineering lane builds it and lands it.