We have said a version of this sentence more than once: every gate checks one branch against the base, so nothing checks the branches against each other.
The first half of that is wrong. It is worth correcting in public, because the true version is narrower and holds up better.
Modern merge queues have tested combined states for years. Mergify runs speculative checks, so the second pull request in the queue is tested against the base plus the first, and the third against the base plus the first two. Graphite builds temporary combined pull requests and runs speculative execution across stacks. Aviator treats a stack as one queue unit and validates its combined head. Trunk builds parallel checkout lanes that represent proposed future states of the trunk.
These are real answers to a real problem, and anyone who runs one of these tools would have caught the overclaim immediately. So here is the honest version.
Merge queues validate queued pull requests against predicted future states, using the tests your repository already has. That is a different question than the one that shows up when several agents write in parallel.
When. A merge queue starts working when a change becomes a queued pull request. In an agent run, most of the risk exists earlier. Five agents are holding five branches, several of which are not pull requests yet and some of which never will be. The moment worth checking is while the branches are still open, not after they line up to land.
How. A merge queue validates a combined state by running the tests you already wrote. If no test exercises the seam between two changes, a green queue is not evidence that the seam is fine. It is evidence that nothing looked. Cross-branch contract analysis does not need a test to exist in order to notice that one branch changed a function signature while another branch added a caller that expects the old one.
What. A queue reports pass or fail on a suite. A contract check reports which function, which route, which schema, on which pair of branches, and which side is now incompatible. Those are different outputs. One tells you something broke. The other tells you what will break and where.
There is a growing shelf of tools that run several coding agents at once and show you the result: isolated worktrees, per-agent sessions, diffs, branch and pull request state, some of them remotely and on a phone. They are genuinely good at what they do, and if you run parallel agents you probably use one.
They tell you where work is running. They do not evaluate whether the branches those agents produced are compatible with each other. A cockpit can show you five green workspaces whose combined state does not hold.
Another shelf records what happened in your agent sessions: conversations, decisions, handoff notes, searchable across tools and projects. Useful, and increasingly necessary when you cannot remember what you were building three sessions ago.
They remember that an agent said a branch was ready. They cannot establish that it is ready. That distinction sounds small until the day the two disagree.
Put it together and almost every adjacent tool owns one part of the problem well. Merge queues own combined validation once work is queued. Cockpits own visibility into where agents are working. Portals and connectors own remote access to repository and organization facts. Memory tools own what was said.
The part that stays unclaimed is narrow: a deterministic answer about whether the branches that are open right now still compose, expressed as contract-level facts, available before anything reaches a queue.
That is the whole claim. It is smaller than "nobody checks combinations," and it is the one we can defend.
The reason this seam widened is arithmetic. One person opening two pull requests a week produces one pair to reconcile. Five agents holding nine branches produce thirty six pairs, and the pairs are where the incompatibility lives. Cheap code generation made the writing fast and left the reconciling exactly as expensive as it always was.
Every tool above is solving a real piece of that. We are solving the piece that sits between the branches, before merge, and we would rather describe it accurately than broadly.