Skip to content

Work Dispatch and Change Integration

Separate work dispatch from change integration when starting a task and landing its output require different eligibility rules.

Work dispatch assigns eligible tasks to execution capacity. Change integration decides which candidate changes can enter the target branch together. This distinction is an editorial synthesis of Symphony's dispatch specification and GitHub's merge queue behavior. The sources describe separate systems, with no reported combined deployment. Use the distinction when work completion and merge completion have different conditions.

Define each queue's decision

Here, task queue means the logical set of pending work. It does not imply that Symphony requires a message broker. The comparison uses each source's own objects and rules:

Boundary Object Eligibility Completion event
Work dispatch, in Symphony Normalized tracker issue Required identity and labels, active nonterminal state, adapter eligibility, no running or claimed entry, available global and per-state capacity Worker execution ends; successful execution can hand off for review without completing the issue
Change integration, in GitHub Queued PR and its temporary merge group Branch-protection requirements, enqueueing by a user with write access, then required checks against the latest target branch and queued predecessors Changes reach the target branch

Symphony Draft v1, sections 1, 7, and 8 defines the dispatch contract. GitHub's merge queue documentation defines integration behavior. An available execution slot supplies no evidence that the output meets those merge requirements.

Record the handoff states

Define these states locally. The names below are editorial definitions:

  • A completed run records an execution outcome. It can succeed without producing a PR.
  • A candidate change is an output artifact, if the run produces one.
  • Here, a policy-approved PR has cleared your repository's defined acceptance policy. Policy approval alone does not establish queue admission or merge completion. The cost metric selects a later counting event, such as merge or deployment; approval alone does not enter that denominator.
  • An integrated change has landed on the target branch.

This vocabulary preserves Symphony's separation of run success from issue completion and GitHub's separate queue admission and merge events. Symphony specification, GitHub merge queue documentation.

The sources do not report a shared dependency protocol.

Why it works

Separate decisions attach evidence to the object under judgment. Symphony checks whether an issue can run; GitHub checks a proposed combination before merging. Keeping those decisions explicit prevents execution success from substituting for integration evidence. This is a design inference from Symphony and GitHub, not a measured productivity gain. GitHub's guarantee covers configured required checks; omitted semantic interactions remain outside that evidence.

When this backfires

A dedicated integrator can become a bottleneck. Cursor removed that role after it created more bottlenecks than it solved; workers handled conflicts themselves. The account also reports unresolved coordination problems. It supports optional ownership arrangements, without establishing permission to bypass repository checks. Wilson Lin, Cursor, January 14, 2026.

For low-volume work, consider a sequential execute, review, check, and merge process. Keep the decisions explicit without adding separate queue services. The cited sources establish no minimum worker count or mandatory service split. The synthesis remains emerging. A draft specification and separate implementation accounts support its components; independent replication of the combined practice remains absent from this evidence.

Example

Cursor's Solid-to-React migration passed CI and early checks while careful review remained outstanding. That report illustrates why passing checks and completing acceptance deserve separate records. It does not establish that the migration used Symphony or GitHub's merge queue. Cursor's experimental account.

Scope boundaries

Use evidence-bundled agent PRs for review evidence and verification capacity saturation for review capacity. Scheduler mechanics belong in the Symphony specification guide. Execution concurrency belongs in lane-based queueing and bounded batch dispatch.

This pattern leaves queue setup, retry protocols, and release permission outside its scope. Use the Factory Engineering index for the broader delivery process.

Key Takeaways

  • Name the event that releases dependent work. If a task needs a prerequisite on the target branch, use integration as that event. This is a design deduction.
  • Assign an owner for integration decisions and conflict resolution; a dedicated agent is optional.
Emerging — single recent source Last reviewed: 2026-11-06