Parallelism: When More Executors Help and When They Get in the Way

When a lot of work has piled up, the temptation is simple: hand it out to several executors and wait for a faster result. But five active agents do not mean five times the speed. If they depend on one another, change the same files or wait in the same review queue, the extra executors may simply push the waiting and the errors downstream into integration.

Learning outcome. After this unit you will be able to tell overlapping work apart from genuinely parallel execution; identify independent parts and the critical path; spot shared resources and the limits of their isolation; estimate the notional time saving together with its overhead; verify the result on the merged revision; and measure the time to an accepted result rather than the number of executors running at once.

Prerequisites. This unit builds on Dependency Graphs, on delegation as covered in Codex Subagents and Orchestration, Plugins, MCP and Skills and The Orchestrator Pattern, and on the team boundaries from Human Teams, Expertise and Specialist Agents. Separate Git working trees are covered in detail in Worktrees and Isolated Environments. Choosing a model is the subject of Model Routing, and the full economics of a studio is examined in The Economics of an AI Studio.

Is the work overlapping or running in parallel?

Sequential execution means the next piece of work starts only after the previous one has finished. Parallelism means several pieces of work genuinely run at the same time on separate available computing capacity — for example, on different cores of a central processing unit (CPU) or on different machines. Separate environments can isolate state, but if they share a processor, a queue or some other narrow resource, separating the environments does not by itself create parallel computation.

Concurrency means several pieces of work make progress during the same period of time, even though at any given instant the resource may be switching from one to another. On a single processor a program can interleave several tasks: they overlap in time, but they are not computed simultaneously. A person can also "run" several requests in parallel by switching between them; the switching itself creates no extra time for focused work.

In agent systems, several calls may be waiting for a response at once, but that alone does not prove that the provider's model is computing them on separate machines. For planning, the practical question is: can these pieces of work move forward without waiting for each other, and are there enough independent resources to serve them?

So distinguish three outcomes:

• Activity: the executor is busy or waiting for a response.
• A finished unit of work: the executor has delivered a result that can be checked.
• An accepted integrated result: a shared revision that includes all the necessary changes has passed verification.

More activity does not guarantee more of the last two.

When are tasks truly independent?

Task names do not prove that the tasks have no dependencies. "Update the client" and "update the server" sound like two separate jobs, but a single response format may tie them together. If the server renames a field and the client does not know about that decision, both branches can finish on their own while the product breaks after they are merged.

Before handing out work, agree a contract. It should record:

1. The shared goal and the completion criterion. What observable result will be accepted?
2. Preconditions and dependencies. What must be known or finished before work starts?
3. Ownership boundaries. Which files, modules, schemas, services or data belong to each executor?
4. The shape of the result. For example, a list of verified findings with file and line references, or a change with a described contract.
5. The integration owner. Who will reconcile the results, resolve contradictions and be responsible for the shared check?
6. Shared state and permitted actions. May the work change a database, a queue, configuration, a branch or a live environment?

Independence is high when an executor has enough data, can work within a defined area without waiting for another part, produces a compatible result and hands it to the integration owner. If the parts touch the same contract, they can be made more independent by agreeing that contract first. If that does not help, the work should stay sequential, or be given to one executor with a separate reviewer.

The official Codex and Claude Code materials recommend handing out independent research, and advise taking conflicts and coordination into account when shared code is edited concurrently. That is useful product guidance, not a promise of any particular speed-up (Codex: subagents, Claude Code: subagents).

Fully worked case: three searches and three implementations

A team wants to find out whether it can remove the obsolete "draft" status from a catalogue. To begin with, it can hand out three bounded searches:

• one executor finds the places where the status is written;
• the second finds the readers and background processes that depend on the status;
• the third finds the tests and documentation that pin down its behaviour.

All of them work read-only on one and the same revision. They return the code path, evidence of the dependency and any uncertainty. The orchestrator compares the findings, checks the critical places and only then decides how to change the code. The searches can run in parallel because the result of one is not an input to another. Bringing them together still needs an owner.

Now suppose three executors implement the removal of the status in parallel. One changes the data model, the second the interface, the third the importer, and each one derives the new format on its own. These are now three implementations of a shared behaviour, not three independent parts. An agreed contract and non-overlapping boundaries can open the way to parallel work; without them, you will most likely end up reconciling incompatible assumptions. If the boundaries cannot be divided, one executor implements the change as a whole and a second independently verifies the behaviour.

Fan-out, fan-in and the critical path

Fan-out is dividing work among executors once the boundaries have been defined. Fan-in is returning the results to the integration owner for comparison, merging and verification. The Orchestrator Pattern treats these steps as part of orchestration; here the point is to calculate how much time can disappear once the work is handed out, and how much stays in the shared queue.

A dependency graph shows what must finish before another piece of work can start. The critical path is the longest chain of dependent work, and it determines the earliest possible completion time of the whole result. Work outside that chain can form parallel branches, but joining them to the shared result still requires integration.

Consider a notional change to a product import. First, the team spends 20 minutes agreeing and applying an update to the data schema. After that, one independent part takes 35 minutes and another takes 30 minutes. Finishing requires 25 minutes of shared integration, verification and human review.

Stage	Working sequentially	Running the independent parts in parallel
Schema update that unblocks both parts	20 minutes	20 minutes
Change to how an imported record is displayed	35 minutes	35 minutes, alongside the next row
Import adapter built to the already agreed contract	30 minutes	30 minutes, alongside the previous row
Shared integration, verification and review	25 minutes	25 minutes, after both parts are ready
Agreeing boundaries, merging branches and extra time in the review queue	0 minutes in the baseline estimate	10 minutes, a notional assumption
Total time to an accepted result	110 minutes	90 minutes

In this example, the ideal time with no extra overhead is 20 + max(35, 30) + 25 = 80 minutes. With the assumed 10 minutes for agreeing and merging, it comes to 90 minutes. That is 20 minutes, or roughly 18.2%, less than the sequential estimate of 110 minutes.

These figures are a teaching model, not a measurement or a forecast for a real team. The model assumes that the two changes really are independent, can start after the schema update, have enough resources and do not increase the integration time. Under these conditions, the parallel plan needs about 120 person-minutes: 20 + 35 + 30 + 25 + 10. The sequential baseline is 110 person-minutes. So in this model calendar time goes down while total effort goes up.

If another 25 minutes of incompatible behaviour turn up after merging, the total reaches 115 minutes. The parallel plan then loses to the sequential one. As the shared part and the overhead grow, the advantage of the shorter parallel branch disappears.

Parallel work does not isolate shared state

Two separate conversations or environments do not necessarily mean two separate copies of every resource. Whoever plans the work has to check what exactly is shared:

• a file, data schema, type, configuration parameter or generated file;
• a database, test records, a port or a temporary directory;
• a network limit, a build queue or a tool's call limit;
• a branch, a Git object, an account or a secret;
• a person to whom unfinished work has to be handed for review.

A Git worktree is a separate working copy for checking out another branch. It reduces the risk of several executors accidentally overwriting each other's files, but the worktrees still belong to one repository and share its objects and most branch references. Worktrees do not separate an external database, a network queue or access to an account. The details and the commands for working with them are covered in Worktrees and Isolated Environments (Git: git-worktree).

Match the control to the resource:

• For code, define file owners and split the implementation along boundaries that can be verified.
• For a schema or a public contract, appoint a single decision owner or agree a shared version first. For database migrations, define the order and the schema version that dependent changes need. If a migration changes shared state or is not compatible with both versions, run it in turn and start the dependent work after the agreed stage.
• For a test database, isolate records by namespace, separate databases or transactions, if the system allows it. If an operation changes a single shared state, run it in turn.
• For configuration, generated files and shared branches, agree who changes them. Separating the work streams does not, by itself, establish such a rule.
• For access, grant only the boundaries and environments that are needed. There is no need to block all parallel work if it is enough to separate the specific conflicting resource.

The books listed in the sources — The Mythical Man-Month, Peopleware and Team Topologies — describe people and teams, so they do not measure the throughput of agents. Here their ideas serve as questions for the process: Brooks prompts you to include coordination and handover in the full estimate; Peopleware, to protect a human reviewer's time from a stream of small interruptions by gathering the evidence before the review; Team Topologies, to name the owner of the contract and organise collaboration around the points where boundaries meet. These are design heuristics, not quantitative laws for artificial intelligence; their effect has to be measured in your specific process. The human context is examined more fully in Human Teams, Expertise and Specialist Agents.

Integration verifies the combined result

An integration check answers the question of whether the changes work together. An automatic merge of branches does not mean Git has understood what the code is for: it can combine edits on different lines without a conflict even though the new behaviour is incompatible. A textual conflict reports the part of the edits Git could not reconcile automatically; the absence of a conflict proves nothing about contract compatibility or whether the program works correctly (Git: git-merge, GitHub: merge conflicts).

Fully worked case: two green branches break the client

This is a teaching example. In a profile service, the server used to return a field called "items". The contract owner decided to switch to "results".

1. On the server branch, a developer changes the response to "results" and tests the server locally.
2. On another branch, a developer adds a new profile list to the client. The client test uses a recorded response with the old "items" field.
3. Each branch passes its own checks on its own. The files were changed in different places, so Git can merge the branches without a conflict.
4. After the merge, the server returns "results", the client looks for "items" and shows an empty list. Nobody tested the combination of the two behaviours.

To fix the process, the contract owner first pins down the shape of the response. If compatibility must be preserved, the server temporarily returns both fields, or introduces a response version and sets an order in which the client migrates. Then a shared check runs the server and the client together against the same schema on the merged revision. The check must confirm the observable outcome — the client displays the records that were sent — and not just that each build succeeded.

If the interface cannot be changed gradually, the changes are brought together in a coordinated order, and the release stays blocked until the shared contract has been verified. This process does not require all teams always to work sequentially. It adds one explicit checkpoint exactly where the branches meet.

A real but limited case: two subagents ran one call

In July 2026 a user opened an issue in the GitHub project oh-my-openagent reporting that a single task call sometimes spawned two subagent sessions with the same request in the same working copy. The report includes launch logs and three instances of overlap; in one of them, two sessions spent 15 minutes 51 seconds changing the same six files and ran git add and git commit almost simultaneously. This is a specific user report about one system, not a measure of how often such a bug occurs or of agents' average productivity (issue #6487).

A related pull request proposed that, on a retry, the previous session should be terminated first and only then the replacement created. In the open version of the proposal, a reviewer pointed out separately that if the cancellation fails or times out, the code may still go on to create a new session. As of the date it was checked, the proposal remained open (pull request #7223). So a team has to verify the state transition itself: a retried call must not leave the old executor active alongside the new one. Confirmation that a cancel command was sent does not, on its own, prove that the shared actions have stopped.

The bottleneck may not be generation

A parallel plan is limited by the scarcest resource it needs. That may not be the model:

• the rate limit of a model or a tool;
• waiting for a network or external service to respond;
• the CPU or random-access memory (RAM), when there is not enough for simultaneous local builds;
• the continuous integration (CI) queue — the automated builds and checks run on changes;
• a test environment that only one process can use safely;
• human review, which has to read, compare and accept every result.

Do not equate the number of agent threads you are allowed to run with the throughput of the service. For example, the current Codex documentation describes a setting for the maximum number of subagent threads open in parallel, but leaves the choice of the default value to Codex itself. The Claude Code documentation gives a default limit of 20 concurrently active subagents launched by the built-in Agent delegation tool, in versions from 2.1.217 onwards. Other mechanisms, including forks and agent teams, have separate rules. These limits depend on the product and version, are not interchangeable, and do not describe a model's plan limits or the speed of human review (Codex: subagent settings, Claude Code: running agents in parallel).

In Claude Code, the exceptions matter even within a single product: the built-in /subtask creates a separate fork of the current session and takes a slot, but is not blocked by the parallel-call limit of the Agent tool. Resuming a finished subagent can also take a new slot without that limit being checked, while agent groups and workflow sessions have their own limits. So a numeric value has to be read together with the description of the specific mechanism and version, not carried over to every kind of parallel work (Claude Code: running agents in parallel).

If a team can produce ten changes an hour but review only two, the queue simply grows. An unreviewed branch is not yet finished work. Likewise, running more local builds at once can make each of them slower if the processor or memory is already busy.

Delay, contract changes and retries

A plan has to keep working when one executor runs late, the preconditions change or part of the task turns out to be duplicated.

• Delay. Check whether an independent finished part can move on to integration. If the result is unusable without the delayed part, do not call it ready just because the other branches are active.
• Contract change. Stop the dependent parts, publish the new version of the contract and mark which results need to be revisited. Do not integrate changes built on an outdated assumption.
• Duplication. Before retrying, find out whether the previous executor has finished and whether its writes or external actions have already happened. First stop or isolate the old process, then create the replacement.
• Partial success. Keep the verified results together with the revision or another exact reference to their source. Discard only the outdated or unverified part, then adjust the dependencies.
• Shared operation. If it cannot safely be repeated or split, run it serially: the next step starts only after the previous one has been confirmed.

After an interruption or cancellation, reconcile the actual state of the files, the database and the queue. A "cancelled" message can appear before an external side effect has stopped. This matters especially when two sessions share a working copy or test data.

Choosing a useful degree of parallelism

Start from the result you need and compare plans under the same conditions. For several representative changes, record the starting revision, the acceptance criteria and the completion boundary: a result counts only after the shared check and human review. Then compare the sequential and parallel options on these measures:

• time from start to an accepted result;
• people's time spent on setting up, merging, reviewing and fixing;
• the number of retries and cancelled attempts;
• textual conflicts and behavioural incompatibilities after integration;
• errors found during the shared check;
• time spent waiting for a model, tool, environment or reviewer;
• tokens consumed per model and agent, and the actual cost of the calls, if the service provides such data.

Do not change the task, the quality criterion, the environment and the set of executors all at once and then attribute the difference to parallelism alone. A small measurement describes its own conditions; it is not a universal percentage for every type of work.

When three independent searches really do reduce waiting, return their results to a single owner for consolidation. When several changes depend on one unstable contract, stabilise the contract first or run the dependent part in turn. If the shared check or human review is already fully loaded, extra executors will not speed up acceptance: first reduce the batch size or clear the queue.

Summary

Parallel work helps when the parts are independent, have clear boundaries and sufficient resources, and an owner can verify them together. It shortens only the part of the graph that can genuinely overlap; sequential dependencies, shared state, integration and review remain. So measure the time to an accepted result and the total effort, and run shared operations that cannot safely overlap one at a time.

Sources and further reading

• OpenAI, Subagents in ChatGPT and Codex. Current documentation page; no publication date given. Supports the material on Codex parallel threads, recommendations for read-heavy and write-heavy work, token costs and limit settings. URL. Accessed 2026-09-24.
• Anthropic, Create custom subagents. Current Claude Code documentation; no publication date given. Supports the description of independent research, sequential delegation, separate context and the version-dependent Agent-tool limit. URL. Accessed 2026-09-24.
• Anthropic, Orchestrate teams of Claude Code sessions. Current Claude Code documentation; no publication date given. Points out the overhead of agent teams and the risk of several sessions editing the same file. URL. Accessed 2026-09-24.
• Git, git-worktree. Current Git reference. Explains multiple working copies and the Git references they share. URL. Accessed 2026-09-24.
• Git, git-merge. Current Git reference. Explains automatic merging, textual conflicts and manual reconciliation of incompatible changes. URL. Accessed 2026-09-24.
• GitHub Docs, Merge conflicts. Current reference; explains when GitHub blocks a merge because of a conflict between branches. URL. Accessed 2026-09-24.
• niStee, [Bug]: Single task() invocation spawns duplicate parallel subagent sessions in same worktree, issue #6487 in oh-my-openagent. Opened 2026-07-30. Primary but single piece of evidence of a duplicated launch and concurrent editing. URL. Checked 2026-09-24.
• AceRothstein71, fix(delegate-task): abort superseded sync session before fallback retry spawn, pull request #7223 in oh-my-openagent. Opened 2026-08-24; still open as of the date checked. Describes the cause of the repeated launch; the discussion includes a remark about cancellation timeouts. URL. Checked 2026-09-24.
• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, 2nd ed. The publisher's official materials and table of contents; the human arguments and their limits are discussed in Human Teams, Expertise and Specialist Agents. Not evidence about the productivity of AI agents. URL. Accessed 2026-09-24.
• Tom DeMarco, Timothy Lister, Peopleware: Productive Projects and Teams, 3rd ed. The publisher's official materials and table of contents; the human context is discussed in Human Teams, Expertise and Specialist Agents. URL. Accessed 2026-09-24.
• Matthew Skelton, Manuel Pais, Team Topologies: Key Concepts. The authors' material on team boundaries and interaction; used here as a design lens, not as a quantitative forecast of parallelism. URL. Accessed 2026-09-24.