GitHub Orchestration

Coordination patterns for multi-agent GitHub delivery.

Choosing a coordination pattern

Pattern	Use when	Cost
Sequential	Each step needs the previous step's output	Sum of steps
Parallel + barrier	You need all results together — dedup across findings, an early exit on zero	Slowest step
Pipeline (no barrier)	Each item flows through all stages independently	Slowest single chain
Hierarchical	A coordinator delegates and synthesizes	Slowest worker + synthesis
Adaptive loop	Repeat until a convergence condition (drive-to-green)	Unbounded — always cap rounds

Default to pipeline over barrier. A barrier is justified only when a stage genuinely needs cross-item context. "I need to flatten the array first" is not a justification — do the transform inside a stage.

What parallelizes in GitHub work

Independent, run concurrently:

Review lenses over the same diff
Security scans across alert classes
Metric collection across dimensions
Per-PR triage across open PRs

Genuinely sequential:

Branch → implement → PR (each needs the last)
Landing a stack (each landing changes the next base)
Migration → code → cleanup

The blackboard

Agents write findings to a shared structure; the coordinator reads and decides.

Contradiction is information. Two agents disagreeing means one has context the other lacks. Investigate; do not average their confidence.
Deduplicate by root cause, not by text. Two lenses describing the same defect differently is one finding.
Record what was dropped and why. A board that reports only survivors is indistinguishable from a board that found nothing.

Delegation

Narrow mandate plus an explicit return contract. "Review this PR" produces mush; "find correctness defects, return file/line/failure-scenario" produces findings.
Keep subagent prompts under ~400 words — subagents inherit a large context chain before your prompt, and long prompts raise rejection rates.
Prefer a named specialist over a general-purpose agent.
Never spawn duplicate agents hoping one succeeds. Spawn them with different lenses so disagreement carries signal.

Merge gates

These are absolute. An agent may not route around them:

Every required check green at the current head sha
Review quorum met, no outstanding CHANGES_REQUESTED
No unresolved threads when protection requires resolution
Clean mergeability against the base
No branch-protection bypass or admin override
Human approval for humanReviewPaths

Re-verify against live state immediately before merging. A gate that passed ten minutes ago is not evidence about now.

Reporting

Report per phase, with a marker per phase, and never claim a phase you skipped. A summary that reads complete while a step was silently dropped is the worst possible output — it converts a partial result into a false one.

github-orchestration