Two AI Agents Passed Review. Why Couldn't Their Code Be Merged?

Two AI coding agents finish their tasks.

Both pull requests pass their own tests. Both receive independent reviews. Neither agent changes the same file.

Then the team integrates the branches—and the product breaks.

What exactly passed?

In an earlier discussion, I asked whether two AI agents reviewing the same pull request were actually independent. A conversation with Dev_PJS sharpened a different issue: a task may be independently verifiable yet have no realistic path to integration.

That distinction matters as teams increase the number of coding agents they run in parallel.

Two green branches, one broken product

Consider this hypothetical example. Both agents start from the same commit, M0.

Agent A updates an order API. The old response is:

{ "total": 49.95 } 

The new response uses integer cents:

{ "totalCents": 4995 } 

Agent A updates the existing consumers it knows about. Its tests pass. An independent reviewer approves the exact commit.

Agent B adds a CSV export feature on its own branch. It uses the old API shape:

const csvAmount = order.total.toFixed(2); 

Agent B's tests use fixtures based on M0. They pass too. A separate reviewer approves the commit.

No files overlap. Git can merge both changes without a textual conflict.

But once both changes are combined, the exporter receives an order with totalCents, not total. Its assumption is now false. A real producer-consumer integration test would catch it; isolated tests with old fixtures may not.

The review receipts can all be authentic. The reviews can all be competent. They still describe two different candidate states.

 M0 (shared base) / \ M0 + A: PASS M0 + B: PASS \ / A + B: UNTESTED 

Two isolated PASS results do not imply a PASS for the combined change.

There are two admission questions

Before an agent starts an implementation run, I want to ask:

1. Can this be checked?

Is there a defined acceptance condition, an independent evidence path, and enough verification capacity to evaluate the result?

2. Can this land?

Is there a plausible route from the proposed change to an integrated candidate that can be tested and accepted? What shared interfaces or dependencies might move? Who will resolve conflicts? Is integration and acceptance capacity actually available?

The second question is not simply whether Git currently reports a branch as mergeable. Git detects certain textual conflicts. It does not establish that two independently developed features remain semantically compatible.

A queue of agent runs is useful when it contains work waiting to start. A queue of completed-but-unverified or completed-but-unintegratable changes ties up review time, forces repeated rebases, and makes activity look like delivery.

Sometimes the cheapest decision is to defer starting a new write-heavy run until the team can realistically validate and land it. Read-only investigation or other independent work can still proceed.

A provisional PASS needs a fresh integration check

Even a good admission decision can become stale while an agent works.

A base commit moves. A shared API changes. Another writer modifies an overlapping contract. A review covers commit A1, but the author pushes A2 after the review.

The historical review of A1 remains useful evidence about A1. It is not automatically authorization to merge A2, nor evidence that A1 + B1 works.

A practical workflow could keep these decisions separate:

If the task includes deployment, production verification is a further stage. Merge success is not proof of a successful release.

I would preserve old observations while marking stale decisions as stale. That keeps the audit trail intact without recycling an outdated PASS.

The failure-injection test I'd run

This is a small experiment a team can reproduce without a fleet of AI agents:

1. Pin a shared base commit M0.
2. On branch A, change an API field and update existing consumers.
3. On branch B, add a consumer of the old field, using old fixtures. Make the file changes non-overlapping.
4. Run and record the isolated tests and reviews for A and B.
5. Construct the exact proposed integration candidate, then run a contract test using the new producer and new consumer together.
6. Confirm that the integration gate refuses acceptance when the contract test fails, even though both isolated branches passed.
7. Repair the consumer, rebuild the combined candidate, and verify that a valid integration is allowed to proceed.

I'd add one more negative case: approve a candidate, change its head commit, and verify that an approval bound to the old revision cannot authorize the new one without appropriate fresh checks.

The positive case matters too. A system that refuses every merge is safe only in a trivial sense. It must also allow a properly checked, compatible combination to land.

What should we measure?

More agent runs are not necessarily more delivery.

The metrics I would watch are accepted integrated changes, time from starting work to acceptance, integration rework, and how much finished-but-unaccepted work accumulates.

This changes the optimization target. Running five agents simultaneously may increase generated code. If only one change can be independently checked and integrated at a time, the other four may create a larger queue rather than faster delivery.

Parallelism still has a place. Independent write sets and stable interfaces can support useful concurrency. The constraint is the team's ability to validate the resulting system, not the number of terminals it can open.

A note on ARC

I maintain Agent Role Contracts (ARC), an open-source checker for declared AI-agent roles, responsibilities, task scope, and related bindings. Its current declaration checks are not an integrated merge queue, runtime enforcement system, or proof that independently reviewed branches compose safely.

The integration-admission and combined-candidate tests above are proposed workflow requirements, not a claim that ARC already enforces them.

The question I keep coming back to is simple:

A verified change is not yet an integrated result.

How does your team handle this today? Do you limit agent runs by available review and integration capacity, serialize interface-changing work, or allow broad parallelism and resolve conflicts at the merge queue?

I'd be particularly interested in a case where two genuinely green, independently reviewed PRs produced a broken combined candidate—and the smallest test that would have caught it.