Why Only One Issue Is Opened Even When 12 Agents Analyze Simultaneously

src/ Let us consider a scenario where you need to locate deprecated API calls scattered across multiple directories. It is intuitive to assume that if twelve AI agents are assigned simultaneously to twelve directories, twelve issues will inevitably be raised. However, in GitHub's agentic workflows (gh-aw), regardless of the number of agents deployed, only one final issue is ultimately opened. This outcome does not stem from complex conflict-resolution techniques, but rather from a design that never grants agents write (pencil) permissions to the repository in the first place.

The GitHub token held by the agents lacks any write permissions. Even if instructed to "push this code to the repository," the request is rejected at the token level, making it physically impossible to save. The only output agents can produce is request data stating, "Please create an issue with this content." This post examines how multiple agents can perform parallel analysis without resulting in repository conflicts or duplicate work.

Parallelism Is for 'Reading', While 'Writing' Lies Behind a Gate

GitHub transitioned its agentic workflows to public preview on June 11, 2026. This feature runs coding agents via GitHub Actions to handle repetitive tasks such as issue triage and weekly summaries. A core security design of this system is providing agents with read-only tokens and blocking access to secrets ¹.

In other words, parallel processing exists only in the 'repository reading and analysis' stage. Multiple agents can simultaneously open different files to understand their contents, but none can write the results directly back to the repository. Actual writes are handled by a separate job with distinct write permissions. This separation fundamentally prevents conflicts and duplicates that might otherwise occur during parallel execution.

Safe Outputs: Agents Propose, Systems Execute

The mechanism that manages this separation is called 'Safe Outputs' in the official GitHub documentation. Agents generate only structured data (requests) without write permissions, and a separate, privileged job reads this data to execute the actual API calls ². When an agent leaves a request stating "create an issue with this title," another system with issues: write permissions processes it ².

Here, a default setting serves as the key to preventing duplicates. Unless configured otherwise, the create-issue feature is enabled automatically, with its upper limit (max) fixed at '1' ². Labels and title prefixes are also controlled by being linked to the workflow ID ². Even if 12 agents simultaneously request issue creation, the gatekeeping system verifies them and executes the operation only once.

Each request carries a unique ID (so_...), and if ordering between jobs is required, depends-on is used to reference the previous job's ID to create a queue. The next job runs only after the previous one is complete; if dependencies become entangled (fail-closed), execution halts for safety ². Pull request merges follow the same rules. Rather than agents holding direct merge permissions, the system verifies the policy and processes only approved requests ²³.

The Boundary Between Parallel and Sequential Execution in Code

The api-sweep example code released by Start Debugging illustrates this flow well. This example assigns one agent per directory under src/ to locate deprecated API calls (HttpClientFactory.Legacy) ³.

// .github/extensions/api-sweep/extension.mjs (Start Debugging 예제 기반)
const dirs = await ctx.step("dirs-v1", async () =>
  (await readdir("src", { withFileTypes: true }))
    .filter((d) => d.isDirectory())
    .map((d) => `src/${d.name}`),
);
// ctx.parallel(): 디렉터리 수만큼 에이전트를 동시 실행 (읽기/분석)
const results = await ctx.parallel(dirs.map((dir) => () =>
  ctx.agent(
    `List every call to ${api} under ${dir} and the replacement it needs. ` +
    `Return an empty list if there are none.`,
    { label: `sweep:${dir}`, schema: HITS },
  ),
));
// 결과를 합치는 단계는 순차적으로 진행됨
return { hits: results.filter(Boolean).flatMap((r) => r.hits) };

Parallel execution applies only up to the section using the ctx.parallel() function. Each agent simply returns its findings in JSON format. Once the returned data is aggregated, a single final issue is created in the last stage according to the safe-outputs setting (max: 1) ³. Even if twelve agents bring back their respective findings, they converge into one at the final gate.

Three Operational Modes and Their Common Safety Boundary

Methods for using multi-agents are broadly divided into three categories, which differ in terms of write permissions ³.

1. /fleet (Ad-hoc execution): When a user provides a prompt in a Copilot CLI session, sub-agents immediately divide the work. This mode is suitable for interactive scenarios where humans supervise and steer the direction, and writes are permitted based on the session's granted permissions ³.
2. Dynamic workflows (Scripts): The division plan is predefined in JavaScript code. This mode is used for tasks requiring repeated execution or budget caps, with write capability determined by session permissions and code ³.
3. gh-aw (Unattended automation): Executed by events or schedules when no one is watching. In this environment, agent jobs must be strictly read-only, and all writes must pass through the Safe Outputs gate ³.

Companies such as Carvana and Marks & Spencer rely on gh-aw for complex system changes and maintenance because of the trust generated by these built-in control mechanisms ¹. Carvana cited 'flexibility and built-in controls' as the reason they could entrust agents with changes spanning multiple repositories, while Marks & Spencer recovered developer time previously lost to issue triage and dependency maintenance by utilizing a reusable workflow catalog.

Conclusion

Multiple AI agents do not conflict when handling the same repository because they compete intelligently. Instead, agents in the gh-aw structure hold read-only tokens, physically preventing them from writing to the repository ³¹. Instead, the generated requests are verified at a separate gate equipped with max caps and label rules, ensuring that even if multiple proposals are submitted, final reflection occurs only once ². Parallelism remains safe not due to complex merge techniques, but because writing was fundamentally pushed behind a single gate from the outset.