We ran into this while updating our own virtualization stack.
One agent branch moved message layout onto a new Pretext-based measurement path. Another improved inline code fencing and markdown rendering on top of the old DOM measurement path. A third expanded tests around the existing scrolling behavior. Each branch was green on its own. Each diff looked reasonable in review. But once we replayed them together, the combined branch was encoding two different directions at once, and main broke.
Nothing obviously looked wrong in any one branch. The Pretext migration branch was a real improvement. The markdown branch was also reasonable, because it was extending behavior that still existed in its own worktree. The test branch was green too, because it was validating the old path in isolation.
That is what makes this a landing problem. Review does not necessarily catch it, because each diff still has a coherent local story. Rebasing does not necessarily catch it, because Git can reconcile text without telling you that the combined branch now contains two conflicting directions. The failure only becomes obvious when you replay the changes onto the same target branch and verify the merged result there.
Coding agents have more than just a review and verification problem. They have a landing problem.
If you use coding agents seriously, this pattern shows up quickly. You do not get one branch waiting politely for review. You get several plausible branches, each created cheaply, each locally green, each based on a slightly different mental model of where the code is headed.
The hard part is not only whether the agent can write code. It is whether one developer can supervise, combine, and keep coherent a stream of overlapping changes arriving faster than a human would normally produce them.
Even if the changes are well tested and well reviewed, you still need a way to land them cleanly. That part gets less attention than it should.
What changed with agents
Human teams already know the general shape of this problem. That is why merge queues exist in CI.
But the old workflow assumed the pressure showed up mostly at team boundaries: many developers, shared branch, centralized CI, PRs waiting remotely.
Agents change where the pressure appears.
One developer can now have five or ten local worktrees moving at once. Some are independent. Some overlap. Some are stacked. Some are exploratory and will be thrown away. Some are still too rough to send to GitHub. The important point is that the integration pressure arrives before the remote workflow does.
That is why I do not think this is just "merge queues, but earlier." A normal PR queue assumes a slower human cadence, fewer in-flight branches per person, and a review process that starts once work is already shaped enough to push upstream.
Agent work is different. The branches are cheaper, more numerous, more disposable, and more likely to be based on slightly stale intent. Existing remote workflows kick in too late. By the time GitHub CI sees the branches, you may already have spent a lot of time reviewing, rebasing, or mentally reconciling changes that never should have landed together in the first place.
That is the key difference. Traditional merge queues protect a shared branch from many humans. A local agent merge queue protects one developer from the concurrency they can now create for themselves.
The failure is not just a merge conflict
Sometimes the problem is obvious. Two branches touch the same lines, Git complains, and you deal with it.
The worse cases are quieter.
One branch changes the direction of the system. Another extends the old direction in a locally sensible way. A third adds tests around the old behavior. Nothing necessarily conflicts at the text level. A rebase can succeed. A superficial review can succeed. The failure is that the combined branch no longer represents one coherent intent.
That is why the phrase "just let the agent rebase" is incomplete. Rebasing can repair text. It cannot tell you whether the branch history still makes architectural sense.
Why rebasing is not enough
The obvious objection is: if agents can rebase and resolve conflicts, why do you need a queue at all?
Because rebasing solves one step inside the process. It does not give you the process.
A coding agent that can rebase is not the same thing as a workflow that can integrate parallel changes reliably.
Rebasing helps with one step inside the process: conflict resolution. A queue gives you the process around it:
- ordering,
- replay against the real target branch,
- and a consistent place to run combined verification.
That distinction matters because many conflicts are conflicts of intent, not just text.
The diff tells you what changed. It does not always tell you why. One agent may be moving the system toward a new abstraction while another extends the old one in a perfectly reasonable way. Git can help align the text. It cannot tell you whether the combined branch still reflects one coherent direction.
That is why we have found it useful to commit plan documents alongside source changes, even when they are messy. When an agent has to rebase, resolve, and resubmit, those plan artifacts often make the difference between a shallow merge and a correct one.
And even perfect rebasing is not enough on its own. Change A can be green on its own. Change B can be green on its own. A plus B can still be red.
That is the landing problem.
What a local queue actually adds
A local merge queue gives you a deterministic landing loop:
- take candidate agent changes in order,
- replay them onto the real target branch,
- verify the combined result,
- and send back anything that no longer lands cleanly.
That sounds simple, but it is different from "the agent can rebase." The queue is where you decide what branch state is actually real, what order changes are allowed to land in, and what happens when a locally good diff no longer survives contact with the rest of the work.
For teams, a normal CI merge queue is still the right final home for shared integration. But agent workflows need this discipline locally first.
So we built the Agent Merge Queue
The Agent Merge Queue in ctx is meant for exactly this situation: landing many agent-produced changes onto one target branch, usually main.
Agents do their normal work in isolated worktrees. You review the result. When a change is ready, it goes into the queue.
The first gate is mechanical: does it apply cleanly on top of the latest target branch?
If not, the entry goes back for revision. The agent can rebase onto the new upstream state, inspect the overlapping work, resolve the conflict, and resubmit.
Passing Git is only the first half of the queue. The second gate, optionally, is verification on the merged result.
That matters because change A can be green on its own. Change B can be green on its own. A plus B can still be red.
The queue catches that by testing the combined branch state before it advances the target branch.
The deeper point is simple.
Agents make it cheaper to produce overlapping work than to reconcile that work.
Verification and review are essential because agents can miss bugs, edge cases, and architectural issues. The merge queue solves a different bottleneck: landing parallel changes cleanly once you already have work that looks good in isolation.
That is why ctx has an Agent Merge Queue.
If you want the product walkthrough, the docs are here. But the main point is simple: if you want parallel agents to be more than a demo, you need a serious local answer to the landing problem.