How a merge queue coordinates AI coding agents

A merge queue controls how proposed changes enter a shared branch. It checks the proposed integration state before a change reaches main.

Nerudo is a Git forge and merge queue for people and AI coding agents. It connects tasks, proposed changes, checks, preserved context, and landing receipts. The sequencer is the only writer of trunk, the repository's main branch. Team supports compatible changes in batches with one CI run per batch.

By Nerudo. Updated October 18, 2026.

Follow one task through the queue

Consider an example task: show receipt prices with two decimal places while preserving the currency code. A second agent changes a separate application component. This example explains the process; it is not a recorded provider run.

Each agent works on a separate proposal. Each proposal records the task, changed files, assumptions, and check results. A reviewer examines whether the receipt change meets its acceptance criteria. A passing type check does not establish correct price formatting.

For this example, useful behavior checks include USD 12 becoming USD 12.00 and USD 12.5 becoming USD 12.50. Currency handling still needs the application's actual requirements.

Team can retain competing approaches to one task. A person compares their diffs, context, and checks before choosing an approach. That choice does not establish that the change has reached trunk.

The sequencer applies the repository's integration rules. Footprints identify units of work that can share a batch under those rules. Different files can still have a shared behavior dependency. File separation alone does not establish compatibility.

The batch's CI result describes the tested combination of changes. Earlier checks on individual proposals cannot replace that result. Required human approvals remain part of repository policy.

After landing, the receipt identifies the resulting trunk commit. The input commit and trunk commit can differ because integration adds metadata. A submitted request, a passing check, and a recorded landing describe different states.

Examine the evidence

1. Examine the task's acceptance criteria.
2. Compare the proposed behavior with those criteria.
3. Examine the diff, assumptions, and considered alternatives.
4. Check which revision each check tested.
5. Examine the result of the integration checks.
6. Confirm that required approvals apply to this change.
7. Compare the receipt's revision and trunk commit with the repository history.

A receipt records integration. It does not prove that the task was specified correctly or that the checks cover every behavior.

Decide when batching helps

Batching can reduce repeated CI runs when compatible proposals share useful integration checks. Overlapping work, policy boundaries, failures, and long checks can reduce that advantage. Compare workloads with their versions, CI settings, and failure conditions explicit.

Nerudo's benchmark methods and results distinguish synthetic scale tests from recorded coding-provider workflows. A peak benchmark rate does not predict a particular team's delivery time.

Try one real landing

Use the Codex and MCP guide for setup requirements and receipt verification. Browser sign-in alone does not authorize agent pushes or landings. Agent access and repository approval policy remain separate requirements.

The public demo provides a labeled scripted example. Free supports one attempt per task. Team adds competing attempts and batched merging. Check current plans and limits before an evaluation. Agent model subscriptions and CI runner compute are paid to their providers.

For local isolation, read Git worktrees and merge queues. Worktrees give agents separate directories; the merge queue controls integration.