A team uses GitHub's merge queue to serialize merges and prevent conflicts on a high-traffic main branch. They want their agent-generated PRs to participate in the merge queue. Which configuration MOST appropriately integrates agent PRs with a merge queue?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A merge queue exists precisely to prevent parallel merges from breaking each other — bypassing it for agents introduces the exact races the queue was designed to prevent. Treating agent PRs as first-class queue participants means they get the same serialization guarantees as human PRs. Separate queues defeat the serialization purpose since two queues can still create parallel-merge races.
Full explanation below image
Full Explanation
GitHub's merge queue serializes merges to prevent the 'merge race' problem where two PRs pass CI independently but conflict when merged together. The value of the merge queue comes from all PRs going through a single serialized path.
Option A (bypass via admin permissions) defeats the merge queue's purpose entirely. Agent PRs merging outside the queue can break main for human PRs currently in the queue, causing CI failures and additional back-and-forth. It also sets a bad precedent — a bypass for 'automated' changes that could introduce problems is exactly when you want serialization guarantees.
Option B is correct. Agent PRs should participate in the merge queue under the same conditions as human PRs: required status checks must pass, and minimum approvals must be satisfied (which for auto-merge candidates might be zero additional approvals if the agent review agent has already approved, or one approval from a human reviewer depending on policy). This treats agent-generated code with the same rigor as human code — appropriate since both affect the same main branch. The merge queue handles the serialization; the agent doesn't need to do anything special except ensure its PRs meet entry conditions.
Option C (separate agent merge queue) fails because two parallel queues can still create merge races between each other. The serialization guarantee only holds when all merges to main go through a single queue.
Option D (daily batch PR) is a workaround, not an integration. Squashing multiple agent PRs into one large daily batch PR loses granularity (difficult to attribute problems to specific changes), increases the blast radius of any single issue, and makes rollback harder. It also creates a review burden: reviewers must evaluate the aggregate of many changes rather than individual, focused PRs.