OpenAI’s Symphony team ran into a fairly ordinary scaling problem. Engineers could open several Codex sessions, assign work, review the results and steer each session as it progressed. Once they were juggling roughly three to five interactive sessions, context switching became painful and productivity started to fall.[1]
The agents could keep running. The engineer still had to remember what each session was doing and review the results.
Symphony responded by moving the control plane away from individual sessions and towards issues and tasks. Each issue received its own workspace, while the orchestrator kept a single authoritative state for dispatch, retries and reconciliation.[1] Once the unit of work becomes a task rather than a session, ownership and hand-offs become part of the design.
This article uses Lead Agent, Worker and Checker as shorthand for those responsibilities. They are editorial names, not fixed roles exposed by Codex.
Start with one decision owner
Take a permissions refactor that touches an API, middleware and tests. There are several jobs that can be separated cleanly: mapping every existing permission check, implementing an already-approved rule, and finding callers or tests that will need migration work.
If the permission model is still moving, sending three Workers off in parallel gives each of them room to invent a different contract.
The Lead Agent should keep the outcome, scope, dependencies and acceptance criteria coherent. Bounded execution can move elsewhere once those decisions are stable enough to hand off.
OpenAI used this shape when it introduced GPT-5.4 mini. A larger GPT-5.4 model retained planning, coordination and final judgement, while mini subagents handled narrower work such as codebase search, large-file review and supporting documents.[2]
For the permissions change, the Lead Agent might send one Worker to map the current checks, another to implement the approved rule and a third to trace migration impact. If two Workers return with incompatible assumptions, neither gets to settle the architecture by being first to finish.
Figure 1 | The Lead Agent keeps decision ownership, Workers handle bounded execution, the Checker verifies claims, and closure stays explicit.
Give the Worker something that can be inspected on return
“Handle permissions” is short, but it leaves almost every operational choice to the Worker.
A read-only investigation can be tighter:
Goal:
Map every permission check involved in session creation.
Scope:
Read only. Do not modify files.
Return:
- file path
- function or rule
- current behaviour
- unresolved ambiguityAn implementation assignment needs a different boundary:
Goal:
Implement the already-approved session permission rule.
Writable scope:
src/auth/*
tests/auth/*
Return:
- changed files
- tests run
- failures or assumptionsThese are illustrative contracts; Codex does not require this schema.
The result can be inspected without reconstructing the Worker’s entire session. The Lead Agent knows what was authorised, what evidence should come back and which discoveries belong outside the current task.
Codex App already supports several agents working in parallel and uses built-in worktrees to separate their working copies.[3] A vague assignment remains vague inside a perfectly isolated worktree.
Two clean branches can still implement two different designs
Two isolated worktrees can avoid file conflicts while the Workers still implement different versions of the same contract.
OpenAI’s Harness Engineering environment made applications, logs and metrics available per worktree so each change could be exercised in its own observable environment.[4] Symphony likewise gives each issue a dedicated workspace, with the orchestrator maintaining authoritative state outside those individual workspaces.[1]
Now suppose one Worker shortens a session-token lifetime while another writes a migration against the old lifetime. Neither branch needs to have a Git conflict. Both can even have internally sensible tests. The disagreement appears only when the pieces are brought back together.
Working-state ownership says where a Worker may make changes. Semantic ownership says who defines the contract, schema, invariant or architecture decision that those changes are meant to implement.
Worktrees, per-task workspaces and write scopes handle the first problem. The second still needs a decision owner.
Figure 2 | Workspace isolation separates working state; semantic disagreement still needs an authoritative convergence owner.
What the Checker needs to verify
When a Worker says done, it is making a claim about execution completion. Acceptance still needs evidence.
OpenAI’s Harness Engineering workflow has Codex review its own changes, request additional specific agent reviews and respond to both human and agent feedback. The team also reported moving much of its review effort towards agent-to-agent review.[4]
For the permissions refactor, a Checker can stay deliberately narrow. It can inspect whether the diff escaped the authorised scope, whether the acceptance criteria were actually met, whether the tests exercise the new permission behaviour, and whether the Worker’s conclusions can be reproduced from code, tests, logs or other evidence.
If the Checker discovers that the architecture itself is wrong, it can reject the result and return the evidence. It should not silently become the new architect.
The Worker may have implemented the requested change correctly while the acceptance criteria were wrong. Or the criteria may be sound and the implementation may have missed a caller path.
Someone still has to reconcile the returns
By the time three Workers and a Checker return, the hard part may be deciding what their outputs mean together.
A legacy permission rule may have appeared during codebase mapping. The implementation Worker may already have changed the new path. The Checker may then find that migration tests still encode the old token lifetime. None of those outputs, by itself, tells the team whether the refactor is ready.
Someone still has to reconcile assumptions, order dependencies, decide which findings belong in the current scope and accept or reject the combined result. That can be the Lead Agent or a human owner, depending on the work.
A Symphony run can stop at a workflow hand-off such as Human Review; the tracker item does not have to become Done simply because the run succeeded.[1]
OpenAI’s Codex safety guidance provides a separate set of controls around sandboxing, approvals, access boundaries and agent-native telemetry.[5] Those controls define what an agent can do, which actions need approval and what can be audited later. They do not define the closure role used in this article.
If the permission contract is still changing, the subtasks repeatedly touch the same state, or each decision depends on the previous implementation detail, extra Workers add hand-offs before they add useful parallelism.
Symphony also leaves ambiguous work that needs strong judgement or expertise in the interactive lane when that is a better fit than ticket-level orchestration.[1] Its observation about people struggling beyond roughly three to five interactive sessions belongs to the same specific workflow, not to a universal Multi-Agent limit.[1]
Before adding another Worker to this permissions change, three things should already be clear: its write scope, the evidence required on return, and the state it must exchange with the rest of the work. If those boundaries are still fuzzy, keeping the job in one thread may be easier to reason about.
References
[1] OpenAI, “An open-source spec for Codex orchestration: Symphony”, 27 April 2026.
[2] OpenAI, “Introducing GPT-5.4 mini and nano”, 17 March 2026.
[3] OpenAI, “Introducing the Codex app”, 2 February 2026.
[4] OpenAI, “Harness engineering: leveraging Codex in an agent-first world”, 11 February 2026.
[5] OpenAI, “Running Codex safely at OpenAI”, 8 May 2026.