How to Split AI Work Without Losing Control

Subagents are extra AI workers that handle focused parts of a larger task. The main agent assigns the work, brings the findings together and checks the result.

• Use them when useful work can happen independently, such as reviewing separate documents or investigating different causes of a bug.
• Keep one agent for a small task or when each step depends on the last answer.
• Keep someone responsible for checking the combined result. More agents do not guarantee a better answer.

Try it on a real task

Choose a task with two or more parts that can be investigated separately. Replace the brackets, then copy this prompt into an assistant that supports subagents. It asks for an investigation and recommendation before any changes.

Help me achieve [specific outcome] using [files, sources or project].
Preserve [important constraints].

Use subagents where independent work would help. Choose a small, useful
division of work and give each agent a bounded assignment. Keep tasks
with dependencies in the right order.

For now, inspect and propose only; do not edit files or take external actions.
Ask each agent for findings, supporting references and uncertainties.
You own the final answer: check material claims, reconcile disagreements
and give me one coherent recommendation. Say if delegation is unavailable.

How the work fits together

Three ways to put this to work

These are hypothetical examples, not client results. Start with the one closest to your task.

Seven more situations to explore

Open an example to see the assignments, checks and expected result.

What is a subagent?

A subagent is an additional AI worker that the main agent starts for a particular job. It works with its own context—the information available to it—and returns a result. Depending on the system, it may also use tools, inspect files or make permitted changes. OpenAI’s Agents API describes this arrangement as separate agent contexts coordinated by a main agent. Agents API: multi-agent

Give each agent a clear question and ask for evidence you can check. A role name such as “security expert” does not establish expertise.

Separate working context also does not guarantee a separate workspace. For example, Agents API subagents share their session’s filesystem. Before allowing edits, establish who owns which files and how changes will be combined. Agents API: shared environment

How are subagents different from skills, hooks and separate chats?

On a narrow screen, scroll the table sideways to read every column.

A subagent can follow an available skill. A hook can supply a check or reminder at a configured event. These concepts describe different parts of the work; they are not interchangeable. See the official guides to skills and hooks.

Opening several chats yourself does not, by itself, make one chat their coordinator. For this guide, “subagent” means a worker delegated as part of the main task.

For a fuller comparison of workflows and event-triggered actions, read How to Choose Between Hooks and Skills for Your AI Agent.

Do you have to ask for subagents every time?

Not necessarily. Current local Codex documentation says delegation can follow a direct request or applicable AGENTS.md or skill instructions. A standing instruction can therefore remove the need to repeat the request. Available tools, configuration and higher-priority instructions still govern what happens. Do not assume that every complex task automatically triggers delegation. Codex subagent triggering

There are three practical ways to express your preference:

On a narrow screen, scroll the table sideways to read every column.

A possible standing instruction is:

Use subagents when independent, bounded work would materially help.
Keep small tasks and tightly dependent steps with the main agent.
Give each subagent a clear scope, relevant context and expected evidence.
The main agent checks material findings, integrates the work and verifies
the final result. Do not expand the user's authorization by delegating.

This is an example instruction to adapt. It does not enable missing tools, change permissions or guarantee a particular number of agents.

A worked example of checkout failing

Suppose the report is:

“On mobile, checkout sometimes leaves people on a spinner.”

The main agent should first establish what the report actually means. Which environment? Which checkout path? Is there a known time, error or reproduction step? Is the request to investigate, repair or both?

Clarify the outcome before dividing the work. Delegation cannot fill in missing user intent reliably.

For this example, assume the agreed task is a read-only investigation using the repository, existing test results and redacted logs. No live purchase is permitted.

On a narrow screen, scroll the table sideways to read every column.

Illustrative findings: The UI investigator finds a branch that leaves the loading state active after an unsuccessful response. The server investigator finds an unsuccessful response near a reported incident, but cannot establish that it was the same attempt. The test reviewer finds that the relevant UI test covers only success.

Those findings support a possible explanation. They do not yet prove that the reported customer failure followed that path.

The main agent should:

1. Read the identified code and check whether the findings refer to the same version.
2. Record the missing link between the log entry and the reported attempt.
3. Propose a controlled reproduction with a simulated unsuccessful response.
4. If repair is authorized, assign the smallest relevant change to one owner.
5. After the change, rerun the affected test and exercise the relevant browser path in the approved environment.
6. Report separately what was reproduced, what was changed and what remains unverified in production.

A useful final statement might be:

“The controlled test reproduced a spinner that never cleared after an unsuccessful response. The repair now shows a retry message in that test and in the local browser check. We have not yet established whether this explains the reported production incident.”

Passing tests is not proof of live customer success. Several agents agreeing is not independent verification if they all rely on the same unverified assumption. Different roles help only when their work adds checkable evidence.

Six more prompts for specific tasks

Already tried the starting prompt? Choose one of these when you know how you want to divide the work. Replace the brackets with your details.

2. Compare products consistently

Compare [products] for [use case] against [requirements and budget].
Use one subagent per product where practical, all using the same criteria.

Read current official documentation. Return source links, dates checked,
relevant plan limits and unknowns. Do not sign up, contact vendors or buy.

As the main agent, verify the important differences and produce one
comparison table. Explain which trade-offs matter to my requirements.
Do not recommend a product on the strength of an unsupported claim.

3. Investigate checkout without changing it

Investigate [checkout symptom] in [environment] using [repository,
redacted logs and existing test results]. This is read-only diagnosis.

Delegate UI response handling, server/log analysis and test-coverage
inspection as separate bounded tasks. Give everyone the same reported
steps, timeframe and version. Do not edit code, change payment settings,
run a live purchase or trigger new transactions.

Each agent should return evidence, possible explanations and missing proof.
You check and combine the findings, then propose the smallest useful
next check. Distinguish a plausible cause from a reproduced failure.

4. Review a code change with evidence

Review [branch or diff] against [base revision]. Do not modify files.

Use separate subagents for behavior regressions, access-control risks
within the changed code, and test gaps. Keep all reviews on the same diff.
Each finding needs a file reference, a concrete failure condition and
an explanation of its consequence. Mark uncertainty; do not invent findings.

Wait for the reviews. As the main agent, check the evidence, remove
duplicates and return a prioritized list. State the review's scope and
any checks that could not be performed.

5. Combine documents without losing contradictions

Create a briefing for [audience and decision] from [documents].
Use only these materials and keep their contents within this workspace.

Assign separate documents or clearly defined sections to subagents.
Have each extract decisions, commitments, dates and unanswered questions,
with page or section references. Do not edit the source documents.

You own the synthesis. Check conflicting statements against the originals;
do not silently resolve them. Return a concise briefing, a conflicts table
and questions that need an owner. Do not send the briefing to anyone.

6. Produce content with a single editorial owner

Draft [resource] for [audience] to help them [specific outcome].
Use [approved brief, tone and source material].

Delegate primary-source checking and practical-example development as
separate tasks. Once a draft exists, use a reviewer to check clarity and
whether the claims are supported. Label hypothetical examples honestly.

You own the structure and final voice. Resolve review findings, preserve
the brief and save one reviewable draft at [destination]. Include source
links beside factual claims. Do not publish, schedule or send the content.

7. Implement with clear file ownership

Implement [approved feature] in [repository], preserving [working behavior].
Use the agreed interface [reference] and acceptance checks [checks].

First inspect the current code. Delegate independent components only:
- Agent A may edit [component A files].
- Agent B may edit [component B files].
- You, the main agent, own [shared configuration and integration files].

Each agent reports its changes, checks and unresolved issues. If it needs
another owner's file or a changed interface, it must report the dependency
before editing. Preserve unrelated work. Do not commit, push or deploy.

After both assignments finish, review the combined changes and run the
agreed checks, including the relevant user flow. Report the final result
and any remaining evidence gaps.

File ownership is a coordination rule. Where stronger separation is needed, use supported workspace or permission controls; writing a boundary in a prompt does not enforce it technically.

When one agent is the better choice

More agents bring more work to coordinate. OpenAI’s Responses API guidance identifies independent work as a useful fit and highlights dependencies, shared writable state and extra token use as important trade-offs. Those are useful considerations when choosing a workflow; the API’s settings should not be assumed to apply to every product. Responses API: when to use multi-agent

On a narrow screen, scroll the table sideways to read every column.

Faster completion can still mean more total work

Subagents may reduce elapsed time when useful tasks overlap. They also consume tokens for their own instructions, reasoning, tool results and reports. The coordinator then needs to read and reconcile the results. Codex documentation explicitly notes the additional token use. Codex subagent availability and usage

Think about elapsed time and total work separately. A shorter wait does not establish a lower bill or a better answer. Cost depends on the product, models, tools and actual usage; there is no universal savings figure.

“Parallel” also does not mean everything starts at once. Capacity limits, tool access and dependencies can cause work to run in stages.

A practical workflow that keeps the work connected

1. Define the result and boundaries. Say what you need, what must stay unchanged and which actions are allowed.
2. Assign independent pieces. Give each worker the relevant sources, version, expected output and file ownership. Keep dependent steps in order.
3. Choose suitable tools and models where supported. A short extraction task may need less reasoning than a difficult review. Local Codex supports model and reasoning settings for subagents. Codex model configuration
4. Check and combine the findings. Read the evidence, resolve contradictions and bring the work into one answer.
5. Verify the result. Try the finished artifact or user flow. Say which checks passed and what remains unknown.

Delegation does not expand authorization. Permission to research does not include publishing, sending messages, spending money or deleting data. Pass the same boundaries to each worker and use the available permission controls.

A reusable assignment template

Objective: [the result we need]
Context: [sources, relevant decisions, environment and version]
Preserve: [working behavior, facts or constraints]

Assignment: [one bounded question or component]
Allowed actions: [read-only, or exact permitted edits]
Ownership: [files, tools or state this worker owns]
Dependencies: [what must happen first; who owns shared changes]

Return: [findings or artifact], [supporting evidence], [checks performed],
and [uncertainties or blockers].
If the task requires work outside this scope, report it before proceeding.

Main agent: [who checks the findings, integrates the work and verifies
the final result]

Start with one useful delegation

Give one worker a clear assignment. Check whether its result helped you make progress. If it did not, improve the assignment before adding more agents.

Go back to the starting prompt and try it with a task you already understand.

Read the companion hooks and skills guide to decide whether you also need a reusable method or an event-triggered action. For help applying these ideas to a real workflow, explore AI consulting and training.

← Back to all resources