A platform needs to independently refactor 5 separate modules (auth, payments, notifications, reporting, search). An orchestrator agent should assign each module to its own subagent for parallel processing. Which coordination pattern and GitHub mechanism best implements this fan-out?

The fan-out pattern with separate GitHub Issues per subagent is the correct implementation because it provides each subagent with: (1) a dedicated, scoped task with clear boundaries, (2) independent status tracking (the issue can be labeled in-progress, completed, or failed independently), (3) no shared state contention (subagents do not compete to read/write the same issue), and (4) a human-visible coordination view where the orchestrator's progress is visible as issue state changes.

Option A (single issue, all 5 modules) creates coordination problems: all subagents read from the same issue, there is no per-module status tracking, concurrent updates to the issue body create race conditions, and the scope for each subagent is ambiguous.

Option C (sequential processing) defeats the purpose of parallel multi-agent coordination. If the 5 modules are independent (which is stated in the scenario), processing them sequentially takes 5x longer than parallel processing and eliminates the scalability benefit of multi-agent architectures.

Option D (matrix strategy with full codebase) gives each job the full codebase rather than module-scoped context, making it harder for each agent to stay within its assigned scope. Matrix jobs also lack the human-visible task tracking that individual Issues provide. The orchestration state is also tied to a single workflow run with no cross-run persistence.

Separate issues per subagent is the standard fan-out pattern for GitHub-native multi-agent orchestration.