Make the main Task a control plane, not a relay.
The key to a complex project is not launching more agents at once. It is deciding who owns the goal, what can be delegated temporarily, how evidence returns, and which state must remain in the project.
Remember these four rules
The main Task owns the outcome
The goal, scope, key decisions, integration, and final acceptance cannot be delegated away.
Subagents are temporary execution units
They take only bounded, independently parallel, objectively verifiable work.
Concurrent writes need isolation
Use a Worktree only when multiple writers must change the same repository.
Project files hold durable memory
Write important constraints, decisions, acceptance, and true state back to AGENTS, HANDOFF, and docs.
Why does adding more agents rarely solve complexity?
More agents can increase execution speed, but coordination cost rises with them. Without a control plane, four failure modes appear quickly:
Fragmented context
Each agent sees only part of the project, and constraints disappear through repeated summaries.
Ambiguous ownership
Everyone completes a local task, but nobody owns the combined result.
Concurrent write conflicts
Several executors edit one workspace, creating overwrites and mixed changes that are hard to review.
Untraceable project state
Decisions and checks live only in chat, so the next Task cannot inherit them reliably.
A control plane has four layers.
Each layer solves one kind of problem. Mixing them turns the main Task into a message relay.
Main Task
Owns the goal and constraints, chooses decomposition, integrates results, and accepts the outcome.
Subagents
Perform bounded exploration, implementation, testing, or independent review.
Worktrees / Handoff
Isolate concurrent writers or move one Task between environments without transferring ownership.
AGENTS / HANDOFF / docs
Preserve durable instructions, true state, architecture, decisions, and acceptance evidence.
A durable way to work.
The main Task does not appear only at the end. It stays involved from problem definition through delegation, integration, and state updates.
- 01
Inspect the project
Read the code, existing documentation, constraints, and uncommitted changes.
- 02
Define acceptance
Turn done into observable, verifiable outcomes.
- 03
Decide whether to delegate
Split out only work that is genuinely independent and bounded.
- 04
Execute within bounds
Subagents return findings, evidence, changes, checks, and risks.
- 05
Integrate and verify
The main Task resolves conflicts and checks the combined result in the real environment.
- 06
Review independently
A Reviewer finds omissions without silently taking over final decisions.
- 07
Update project state
Write confirmed state back to HANDOFF, decisions, and acceptance documents.
Not every kind of parallel work needs the same tool.
| Object | Use it for | Do not use it for |
|---|---|---|
| Main Task | One continuous outcome that needs durable decisions and context. | Long-term ownership of several unrelated projects. |
| Subagent | Read-only exploration, tests, log analysis, independent review, and bounded short tasks. | Ambiguous requirements, tightly coupled continuous edits, or work with no objective acceptance. |
| Worktree | Several writers in one Git repository, or comparing competing implementations. | A small sequential edit or a non-Git directory. |
| Handoff | Moving the same Task between Local, Worktree, or another execution environment. | Transferring final ownership to another Task. |
| Persistent Task | Cross-repository, cross-host, or long-lived independent ownership. | A short investigation that a Subagent can finish in minutes. |
| Automation | Stable, repeatable work with a clear success or failure condition. | A process that still needs frequent human guidance. |
Ask four questions before delegating.
Parallel delegation is likely worthwhile only when all four answers are yes. Otherwise, sequential work in the main Task is usually cheaper and clearer.
- 1Is the output concrete and clearly bounded?YES / NO
- 2Can it run independently alongside other useful work?YES / NO
- 3Is there an objective way to verify it?YES / NO
- 4Will it avoid unsafe concurrent write conflicts?YES / NO
Codex Project Setup writes the theory into the project.
The plugin does not automatically assemble a multi-agent team. It first creates a project structure that can carry the control plane; real work decides whether parallelism is needed.
Light
Keeps the essential project constraints, product definition, decisions, and handoff state.
Orchestrated standard
Adds architecture, acceptance, workflow, and Explorer / Reviewer role definitions.
Orchestrated federated
Adds integration structure only for real cross-repository, deployment, host, or shared-contract boundaries.
Parallelize execution. Never disperse ownership.
A good control plane does not make the main Task do everything. It makes sure the main Task always knows why the work exists, who is doing it, where the evidence is, whether the result passed, and where the next collaboration should continue.