Codex Multi-Agent V2 in practice: splitting tasks, assigning models, and controlling costs

Why multi-agent

A single agent completing a complex task typically works through a sequence: read the code, check tests, confirm boundaries, implement, then verify. The problem isn't that each step is slow—it's that many investigations that could happen in parallel are forced into a queue.

The first benefit of multiple agents is overlapping independent waits: one scout traces the call chain, another checks permissions and test coverage, while the lead agent confirms scope with the user. Once the evidence comes back, the implementation phase avoids a detour.

But if the work is tightly coupled, adding agents is pointless. When the next step depends on the previous result, everyone needs to modify the same core code, or the final answer can only be judged as a whole, a single agent is usually faster. Whether to parallelize depends on the task structure, not on how many agents your tool can launch.

What tasks can be split

A task is worth splitting only if it meets three criteria at once: subtasks can proceed independently, their results can be verified independently, and their write scopes won't collide.

Take adding an "export CSV" feature to an existing product. Investigating the current data flow, checking permission rules, and finding test locations can all run in parallel. But the field definitions and permission contract must be settled first. Once that contract is stable, the backend API, frontend entry point, and tests can be implemented separately. If three agents concurrently modify shared types and the same core functions, parallelism just brings the conflicts sooner.

What you actually export isn't a command like "go build the export feature." It's each subtask's goal, scope, deliverable, and acceptance criteria. If a task spec is vague, the boundaries aren't drawn yet. Continuing to split at that point just copies the ambiguity onto more agents.

Which model to assign

Eric Provencher's simplest configuration is to stay within the same model family and only adjust reasoning_effort. That isolates task difficulty as the single variable you're tuning, without having to compare multiple models' capabilities, pricing, and output habits from the start.

Light doesn't mean less capable; it just spends less reasoning on narrow discovery work. High isn't automatically better for everything—it should be reserved for parts with genuinely higher ambiguity, risk, or system coupling. Handing every file-location task to High turns cheap searches into expensive deliberation. Assigning architectural conflicts to Light saves reasoning upfront but pays for it in rework.

This role table is a practical default, not a platform whitelist. The current GPT-5.6 family also includes Terra, Luna, and other options; multi-agent setups can delegate to any supported model. The safe path is to get a baseline working first, then compare real tasks across different models and reasoning levels. Don't confuse using the most expensive setting with finding the best configuration.

How agents coordinate

Once the task is split, the lead agent remains the coordinator. It's responsible for avoiding duplicate investigation, defining file ownership, tracking dependencies, integrating results, and continuing to communicate with the user. What gets delegated is the specific work, not the final responsibility.

But information doesn't have to flow up the chain. When a scout finds a permission check entry point, it can send the file path and conclusion directly to the worker that depends on it. The lead agent only needs to know the dependency is resolved. That saves a round of relay and keeps the coordinator's context from filling up with every intermediate message.

The concurrency budget can be set per thread. When Eric shared this method, the default was four agents, including the coordinator. The most straightforward combo is one coordinator plus three parallel scouts, each investigating a different question. Alternatively, a smart worker can lead a scout and a worker as a small team handling a complex subproblem. Four was the default at the time, not a permanent cap, and certainly not a quota to fill every time.

Direct communication doesn't mean decentralized chaos. Who can edit which files, who decides shared contracts, when to merge, and who does the final acceptance—these still need a clear task graph. Communication can take the shortest path; ownership must not be ambiguous.

How much context to give

Whether a subagent inherits the parent conversation should depend on how much it relies on existing decisions. Narrow, read-only investigations often work well with fork_turns: "none": give it just the current question, the scope it's allowed to read, the output format, and the acceptance criteria. Workers that need to carry forward architectural decisions, compatibility constraints, or user preferences should inherit the relevant history.

A clean context isn't a blank task sheet. The tool scope, business constraints, and "don't touch this" rules from earlier conversations don't automatically carry over—they need to be explicitly written into the dispatch. Conversely, inheriting too much history drags in unrelated discussion, and can even make a leaf agent think it should keep spawning more agents. In that case, be explicit: complete the task directly, no further delegation.

Eric's boundary prompt for leaf agents is short enough to reuse directly:

Complete this task directly. Do not create any additional agents. The delegation rules your parent received apply only to the parent.

Another common misconception: fork_turns: "none" isolates the chat history, but it doesn't disable the platform's sandbox or permission mode. You can trim the task context; the system's security boundaries still apply.

How to codify into a Skill

A division of labor is worth turning into a Skill only if it works repeatedly. What deserves codification isn't "always create three agents." It's the discipline that's easy to forget and reusable across tasks: which work goes to a scout first, when to escalate reasoning, how to avoid overlapping writes, whether a leaf agent can delegate further, and which actions require user approval.

A Skill lets the coordinator avoid re-explaining team conventions from scratch each time, but it can't pre-draw task boundaries for a project. When code structure, risk, or model capabilities change, the defaults need to adjust alongside real results. The best Skills read like a living operations manual, not a permanently correct automation spell.

Eric has packaged these conventions into the open-source repository provencher/codex-skills, and orchestrate/SKILL.md is a short, runnable version. To install, copy the orchestrate directory to ~/.codex/skills/, then invoke it with $orchestrate. What's worth borrowing isn't any single prompt line—it's bundling roles, reasoning effort, context, ownership, and approval boundaries into one reusable rule set.

What you save, what you pay

The most common misunderstanding is that multi-agent means "faster and cheaper on tokens." In reality, those are two different ledgers. When independent work overlaps, wall-clock time can drop. But every agent reads material, reasons, calls tools, and checks results—total tokens usually go up, and you add coordination, conflict, and rework costs on top.

So the primary goal of multi-agent optimization is usually shortening wait time, increasing exploration coverage, or reducing the risk of getting it wrong in one pass—not reducing total tokens. It might also keep the lead agent's context cleaner, but that just moves the work elsewhere; it doesn't mean overall system consumption went down.

When evaluating, look at four things at minimum: completion time, duplicate investigation, write conflicts, and rework count. Record the single-agent baseline first, then change one variable at a time. Eric suggests focusing experiments on four knobs: reasoning effort, context inheritance, delegation permissions, and collaboration style between agents. For example, start by parallelizing just two read-only investigations, or raise one high-ambiguity task from Medium to High. Without a real comparison, there's no such thing as the "best orchestration."

In the end, the choice compresses into one line: tightly coupled work stays with a single agent; work that can proceed independently, be verified independently, and has low conflict risk is worth assembling into a team. What multi-agent truly saves is wasted waiting. What it costs is more model work and stricter coordination discipline.