Codex subagents can handle independent pieces of a task while the main agent coordinates the goal and combines the results. Start with bounded read-only work, give each agent the context it needs, and require findings you can verify. More agents also mean more model and tool work, so splitting a small task can add cost and coordination. This guide follows official subagent documentation and supplies a two-file practice design. We prepared the fixture but did not start its agents, so it is an instructional example rather than a measured parallel run or a claim of saved time.
Delegate independent questions
Good starting tasks include reading separate modules, checking different documented requirements, or investigating separate test failures. Each task should have a result the main agent can assess without rereading every intermediate note.
Avoid splitting a tightly coupled edit across agents without a plan. If both need to rewrite the same function, they can overwrite or misunderstand each other’s changes. One focused agent may finish that job with less coordination.
The official subagent guide describes current local delegation after a direct request or applicable project or skill instruction. Availability and controls differ by client; check your installed release before following a command from another surface.
Give every agent a bounded assignment
An assignment needs a purpose, allowed inputs, permitted actions, and a return format. For a read-only investigation, say explicitly that the agent must not edit files or expand the task.
Our practice fixture has totals.py, which omits the last item from a sum, and contacts.py, which lowercases an address but leaves surrounding spaces. A short README states the intended behavior. The two checks can be investigated independently.
Use two read-only agents in this practice folder. One checks totals.py
against the README; the other checks contacts.py. Each returns one
reproducible finding with a file and line reference. Neither may edit,
use the network, inspect other folders, or delegate further. Wait for
both, verify the findings, and combine the results. Do not apply fixes.This is the prepared request, not a transcript of an executed delegation. The expected acceptance check is to reproduce the sum and whitespace cases independently before accepting either finding.
Supply enough context without granting more access
Tell each agent what the main goal is and which requirement its own task serves. Supply the relevant file and rule. Do not assume it sees every detail of the main conversation, and do not send unrelated private information simply to make its context larger.
Permissions remain a separate boundary. A task description saying “read only” is useful instruction, but it is not a substitute for the client’s actual file and tool controls. Use the permissions guide when checking what an agent can execute.
For persistent project expectations, keep AGENTS.md short and relevant. Avoid conflicting instructions across agents about the same files or acceptance condition.
Keep model and reasoning choices explicit when needed
The official guide describes inheritance from the parent when no override is configured. A client can also support agent-specific model or reasoning settings. Verify availability for the actual account before requesting a particular model.
Choose settings for the task’s difficulty and check the result. A fast scan of two functions is different from a subtle security investigation. Higher effort or additional agents is not automatic proof of better quality.
Record total work when comparing approaches: parent effort, delegated work, retries, and integration. A smaller parent transcript does not prove that the whole task used less allowance.
Collect findings, then verify them
Ask for a short report: finding, relevant file and line, reproduction, and uncertainty. The main agent should wait for all required results, identify contradictions, and check the decisive claims against the files or tests.
If a finding is incomplete, send a specific follow-up rather than accepting a vague warning. If two reports disagree, reproduce the case and identify the missing assumption. Do not combine incompatible conclusions merely because each came from a separate agent.
The code review exercise shows independent reproduction of a concrete boundary defect. Use that standard for a delegated review too. A plausible report is a lead to verify, not a completed repair.
Separate agent ownership from Git isolation
Agents are a way to divide work. Git worktrees are a way to give tasks separate working copies. A child conversation does not automatically establish a separate checkout.
For parallel writing, assign file ownership and tell each worker that other changes may be present. They should preserve unrelated edits and report collisions. If separate working copies are used, record their paths and starting revisions, then test the combined result after integration.
Keep one clear owner for the final output. The main agent must resolve conflicts, run the relevant checks, and state any remaining uncertainty. Several individually passing checks do not establish that the merged product works.
Stop work cleanly
Use the client’s available controls to inspect running agents, send follow-ups, or stop unnecessary work. In the documented interactive CLI, /subagents helps inspect and switch between agent threads. Confirm command availability in your version.
Before ending the task, identify unfinished agents and unresolved findings. Preserve useful results and verify any edits already made. Stopping an agent does not necessarily revert its saved files.
The practice design here remains unexecuted. For your own trial, complete the two read-only checks, reproduce both findings, and record the actual total work before deciding whether delegation helped.