Before assigning a second Codex worker, draw the dependency graph. If one slice needs output from another, that edge matters more than the number of worktrees available.
Take a feature that changes a database schema, an API contract and a frontend. Codex can place the work in separate worktrees, but the API still needs the schema to settle and the frontend still needs the API contract. Repository isolation prevents workers from trampling the same local Git state; it does not remove the dependency.[2][3]
Parallel Codex work is already a product capability. Early Codex guidance encouraged well-scoped concurrent tasks, the Codex app added parallel threads and isolated worktrees, and Symphony formalised dependency tracking, bounded concurrency and one authoritative orchestration state.[1][2][3] The remaining design problem is deciding which slices can actually move independently.
This article uses Outcome → Direct → Independence → Ownership → Closure as a dispatch test called Baton. Baton is an article method, not an OpenAI product term.
Parallelism starts with the dependency graph
Consider the chain first:
Database schema
↓
API contract
↓
Frontend integrationThree isolated branches do not turn it into three independent jobs. Each worker can avoid overwriting another worker’s local files while still depending on the same unresolved contract.
Keeping the edge visible produces a safer topology:
Schema owner
↓ verified contract
API owner
↓ verified contract
Frontend ownerThe other option is to freeze the shared contract first and delegate only the downstream work that has become independent. In either case, no worker has to invent an input that another worker still owns.
The Codex app documentation supports a deliberately narrow claim: worktrees isolate working state so agents can operate on separate copies of a repository.[2] Semantic independence still has to come from the task graph.
Figure 2 | Worktrees isolate Git working state, but dependency chains and shared mutable state can still prevent true task independence.
A slice is a poor candidate for independent execution when it needs unfinished output from another slice, changes the same shared state, relies on an unverified assumption owned elsewhere, or becomes largely invalid if another worker fails. Several of those conditions at once describe a pipeline or DAG more accurately than a fan-out.
Symphony follows that model directly. Blocked tasks stay blocked; parallel execution appears as dependencies clear in the graph.[3]
Delegation has to pay for itself
A direct task carries one context. The agent reads the problem, changes the candidate, verifies it and returns the result.
Delegation adds briefs, scope boundaries, hand-offs, shared assumptions, result review, conflict resolution and another verification pass after integration. The extra structure is useful when it buys back real waiting time, independent coverage or genuinely separate implementation paths.
OpenAI’s Symphony write-up describes the human side of this cost. Three to five simultaneous Codex sessions were manageable for the team; beyond that, more attention went into remembering state, switching terminals and following long-running work.[3]
Outcome quality belongs in the same calculation. “Look into auth” leaves a worker to invent its own stopping condition. “Locate the earliest failing boundary in token refresh, read-only” returns something the main agent can compare and verify. Vague outcomes only distribute ambiguity across more sessions.
Anthropic’s production multi-agent research work provides useful cross-vendor evidence for the economics. Highly parallel research can justify the extra agents, while workloads with substantial shared context or tight inter-agent dependencies carry higher token and coordination costs and fit less well.[6] That is not a Codex product rule.
OpenAI’s June 2026 Codex usage study shows that heavy users were already spreading substantial amounts of work across several parallel agents.[5] It confirms the operating pattern, not the dispatch decision for a particular task.
If one agent can finish the job without a material delay or coverage loss, keep the direct path. A one-file bug, local rename or narrow test repair usually falls into that category. Repository-wide investigation, independent review and bounded changes in unrelated modules are better candidates for fan-out.
Ownership covers the work surface and the authority boundary
“Backend” and “frontend” are role labels, not enforceable ownership. A delegated slice needs enough detail to expose scope crossing: allowed paths, read-only inputs, forbidden writes, acceptance conditions and stop conditions.
Shared mutable files usually need one owner. If several workers can rewrite package-lock.json, a shared schema, central configuration or the same generated output, a clean Git merge says little about semantic compatibility. Each patch can be locally coherent while assuming a different version of the shared contract. OpenAI’s Harness Engineering work is relevant here because it treats architecture, tests, documentation, rules and feedback loops as part of the environment an agent works against.[4]
Write scope does not change decision authority:
Delegation divides work.
It does not expand authority.A worker can prepare a patch, proposal or evidence without acquiring permission to push, deploy, publish, delete or change live configuration. The actor already authorised for the high-impact operation still decides whether it happens.
Baton compresses the dispatch decision
Figure 1 | Baton checks Outcome, Direct, Independence, Ownership and Closure before fan-out; a failed check returns the task to a simpler topology.
| Check | Question | If it fails |
|---|---|---|
| Outcome | What verifiable result should come back? | Define the task before delegating |
| Direct | Would one agent be cheaper or faster overall? | Keep the direct path |
| Independence | Can each slice progress without guessing another slice’s state? | Preserve the dependency as a sequence or DAG |
| Ownership | Are write surfaces, shared state and stop boundaries unambiguous? | Re-scope or assign a single owner |
| Closure | Who integrates, re-verifies and issues the final verdict? | Name the closure owner first |
One failed check is enough to send the work back to a direct path, a dependency-aware sequence or a different ownership split. Baton does not require five ritual stages, and five green checks do not guarantee success.
The same test gives useful starting points for common workloads:
| Workload | Sensible starting point | Why |
|---|---|---|
| Small bug in one file | Direct | Integration overhead usually dominates |
| Bounded changes in unrelated modules | Fan-out | Dependencies and write ownership stay separate |
| Read-only diagnosis across a large repository | Fan-out | Parallel exploration with little write collision |
| Schema → API → UI | Sequential / DAG | Downstream work depends on upstream contracts |
| Reviewers examining different risk classes | Parallel checkers | Independent perspective is part of the output |
| Several workers editing central configuration | Single owner / re-scope | Shared mutable state dominates |
| Relevant scope is still unknown | Scout first | Find the boundary before splitting the work |
| Deploy, publish or destructive action | Authorised actor closes | Delegated execution does not confer decision authority |
Worker count should follow the dependency graph and ownership map. Model routing comes later. Mechanical slices may suit a faster or cheaper lane; difficult reasoning, review or final synthesis may stay with a stronger model. Model choice cannot repair an entangled scope.
Fan-out can shrink after launch
Initial decomposition is provisional. Repeated waiting between workers, shared files appearing in several scopes, a closure owner spending most of the job reconstructing context, or regressions appearing only after green slices are integrated all indicate that the original independence estimate was too generous.
The briefs expose the same problem. If each one grows a wall of caveats such as “do not touch this until that worker finishes” or “stop if this shared file changes”, the workflow may be spending more effort defending an artificial parallel boundary than executing the task. Reduce concurrency or return the shared surface to one owner.
Part 02 covered closure in more detail. For dispatch, the boundary is shorter: know who owns the integrated candidate before the first worker starts. Three local DONE results can still conflict, overlap or pass only local checks. Symphony likewise separates run success from completed workflow state; a run can reach a hand-off such as Human Review while the orchestrator retains authoritative state for retries, dispatch and reconciliation.[3]
OpenAI’s June 22 guide to long-running Codex work treats verifiable steps, continuity across workstreams, delegation and human oversight as parts of the same operating problem.[7] An extra worker earns its place when it produces a slice that can advance independently and still return to one integrated, verifiable candidate. Otherwise, keep the direct path, preserve the dependency, or give the shared surface one owner.
References
- OpenAI, “Introducing Codex”, 16 May 2025.
- OpenAI, “Introducing the Codex app”, 2 February 2026.
- OpenAI, “An open-source spec for Codex orchestration: Symphony”, 27 April 2026.
- OpenAI, “Harness engineering: leveraging Codex in an agent-first world”, 11 February 2026.
- OpenAI, “How agents are transforming work”, 25 June 2026.
- Anthropic, “How we built our multi-agent research system”, 13 June 2025.
- OpenAI, “Codex-maxxing for long-running work”, 22 June 2026.