Subagents in Codex are useful in a specific case: when a task splits into independent read-heavy subtasks that can be run in parallel. Exploring the execution path, finding security risks, assessing test coverage are different lines of attention, and running them at the same time is faster than sequentially. But parallelism has a cost that is easy to forget: each agent consumes separate tokens and creates a coordination cost, so the number of workers is not a quality metric.

This is worth repeating, because the temptation is strong: more agents does not mean a better result. A swarm of agents is a spend multiplier, and launching it for a task that a single pass solves linearly is more expensive and dumber. Parallelism is justified where the subtasks are truly independent and each benefits from a separate context. Where one rg and reading a couple of files suffice, splitting into agents only adds coordination and tokens without speeding anything up.

For write-heavy work the order is reversed: first you define ownership, then you parallelize. Two agents changing one file or contract are often slower than one - they proceed from different pictures, and the results do not converge at the merge. So writing is distributed so that each agent has its own area that only it is responsible for. You parallelize independent knowledge and ownership, not the stages of one change, which by definition depend on each other.

The most predictable way to apply subagents is exploration by several read-only roles. It helps to see such a decomposition once. Below is a request for three parallel subagents: the explorer builds a map of the execution path, the reviewer looks for correctness and security problems, the test analyst - gaps in coverage. Nobody changes files, and at the end their results are gathered into one deduplicated evidence list. The exploration goes in parallel and cheaply, while only one changes files afterward.

The key in such a decomposition is a minimal context and an explicit expected output for each worker. Each agent is given a narrow task, a definition of done and a result format, not the whole repository "just in case". This is both cheaper and more precise: a subagent returns a compressed summary rather than a raw dump, and the orchestrator assembles the overall picture from these summaries. A broad context handed to everyone is a waste of tokens and a blurring of focus, not help.