# 5.4 Decompose complex requests (/managing-ai-workers/the-four-part-brief/decompose)

---
type: Document
title: "5.4 Decompose complex requests"
description: "Four signs that a request is too big to do all at once, three ways to split it, where to put the stop for a person's decision, and how to brief a worker that splits the job among helpers."
status: stable
order: 205.4
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-11-06T04:57:01Z
chapter: "05"
part: II
expert_status: required
concepts: [ "5.4" ]
last_verified: 2026-10-06
sources:
  - id: anthropic-multi-agent
    title: "How we built our multi-agent research system (Anthropic Engineering, verified 2026-10-29)"
    resource: https://www.anthropic.com/engineering/multi-agent-research-system
  - id: v1-thesis
    title: "The Agent Factory Thesis (Panaversity, first edition, verified 2026-10-06)"
    resource: https://agentfactory1.panaversity.org/docs/thesis
  - id: anthropic-cowork-start
    title: "Get started with Claude Cowork (Claude Help Center, verified 2026-10-30)"
    resource: https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork
  - id: claude-code-subagents
    title: "Create custom subagents (Claude Code Docs, verified 2026-10-30)"
    resource: https://code.claude.com/docs/en/sub-agents
  - id: openai-subagents
    title: "Subagents (OpenAI, ChatGPT Learn, verified 2026-10-30)"
    resource: https://learn.chatgpt.com/docs/agent-configuration/subagents?surface=app
generated:
  at: 2026-11-06T04:57:01Z
  by: process:panaversity
trust_tier: unverified
build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e
dirty: true
ksor_version: 0.0.60
---

**In everyday life.** You approve the paint color before the painter does the whole house.

Some requests are too big to do all at once. Splitting one into stages is called decomposing it. Four signs say a request needs it.

- It asks for several deliverables for different readers, such as a CSV for Maria and a memo for Dave.
- It mixes kinds of judgment, such as finding exceptions and adding up totals.
- A later part depends on a person's decision about an earlier part.
- The parts need different sources or different constraints.

The payment run shows the first three signs, and the third decides it. Its exceptions, the cases a person must decide, are the invoice that needs Dave's approval, the duplicate invoice, the Canadian-dollar invoice and the bank-detail request. Someone must decide them before the run file, the proposal CSV, is worth building, because those decisions change the file.

There are three ways to split the work.

1. **A sequence of briefs.** Brief each stage on its own, and check its result before the next begins. For example, one brief lists the exceptions. After you decide them, a second brief builds the run file and the memo.
2. **One brief with a stop point.** "First list every exception with its policy section, then stop and wait for my decisions. After I reply, build the run file and the memo."
3. **Plan first.** Ask the worker to propose a plan and wait: "Before you start, give me your plan in a few lines, and wait for my OK." Approve or change it. Use this when you are not sure how the work divides.

The first two differ only in how many messages you send.

Sometimes you are not sure what you want, not only how the work divides. Then let the worker interview you before there is a brief: "Interview me, one question at a time, until you could write this brief. Then give me the brief." Read the brief it writes, then run it in a fresh chat, so the work starts from the brief and not from the questions.

A checkpoint is a place where the worker stops and waits for you. Put each one where a human decision changes what follows. Keep each stage small enough to check, and let nothing that cannot be undone happen before the check. This book's first edition called this small reversible decomposition.[^v1-thesis] Decomposing is not micromanaging, which means telling someone every step. Each stage still gets an outcome, not a list of clicks.

![Under the title The payment run in two stages, four boxes in a row, joined by arrows. Stage 1, the AI Worker: identify exceptions, list each one, cite the policy or flag a gap, then stop and wait. The human checkpoint, in red: Maria reviews, confirms holds and next steps, and escalates the decisions reserved for Dave. Stage 2, the AI Worker: build the proposal CSV and the memo for Dave, using the policy and the recorded decisions. Final approval, in gold: on Thursday, Dave approves the whole run and records the invoice approvals it needs. Below, what Stage 1 must surface. Approval needed: Midwest 4519 for $6,480 needs Dave's approval under section 4. Duplicate copy: hold the second copy of Buckeye BO-22871, under section 6. Bank-change request: hold both Tri-County invoices, 5149 and 5161, and verify by callback, under section 5. Policy gap: Northern Maple NMP-3390 is in Canadian dollars, so refer it to Dave and do not convert it. A footer reads: the worker prepares, people decide and approve. This task proposes payments, it does not execute them.](img/two-stages.png)

*Figure 5.3. The payment run in two stages. Stage 1 lists the exceptions and stops. Maria decides each one, or passes it to Dave if it is his to decide. Stage 2 builds the run file and the memo from her decisions, and Dave approves the run on Thursday.*

### When the worker splits the job

A worker can split a job too. It becomes a **coordinator**: it hands parts of the job to helpers, and combines what they send back. Each helper is a second worker it starts for one part, called a **subagent**. Some products start helpers on their own when a job is complex.[^anthropic-cowork-start] Others usually start them only when you ask.[^openai-subagents] Either way, you may see them in the app as separate lines of work running at the same time. Your brief still governs the whole job, through the coordinator.

The coordinator briefs each helper. One AI vendor's research system gives each helper "an objective, an output format, guidance on the tools and sources to use, and clear task boundaries."[^anthropic-multi-agent] The first three are this chapter's outcome, format and context. The task boundaries say what each helper covers, so two helpers do not do the same work. When its descriptions of the work were not detailed, its helpers did the same work twice and left gaps.

The coordinator writes those briefs from yours. Do not assume a helper knows what the coordinator knows. Many helpers start fresh: they do not see your conversation, only the task the coordinator wrote, and perhaps the project's standing instructions. Some start with a copy of the whole conversation.[^claude-code-subagents] You usually cannot tell which kind ran. So brief as if each helper will see only its own task. A rule you said in passing, three messages ago, may not reach the helper that needs it.

**When to let it split.** Splitting helps when the parts of a job do not depend on each other. It hurts when each step needs the one before it.

| Let the worker split | Keep it in one piece |
| --- | --- |
| The same check on many separate items, such as each vendor's invoices against its vendor record | A job where each step uses the last step's result |
| Reading many long sources and reporting what each says | A small job, where splitting costs more than it saves |
| One question seen from several sides, such as policy, dates and approvals | A job where a mistake in one part would be hard to spot in the combined answer |

Some checks need every part at once. In the payment run, they are the total, the duplicate check and the exceptions list. A duplicate invoice can land in two different parts, and neither helper sees both copies. These checks can still be done, but only from all the checked rows, by the coordinator or by one named checker that receives them all. Checks between the parts are missed unless someone is responsible for them.

Splitting often uses more of your plan, even when it finishes sooner.[^openai-subagents] Each helper is a separate run of the model. How much more depends on the job.

**Brief the split, one line per part.** When a job is big enough that the worker may split it, add one line to each part:

- *Outcome.* The coordinator is responsible for the whole result. Every input is accounted for once, and every check across the parts uses all the checked rows.
- *Context.* Every rule the parts need is in the brief, not in an earlier message, and the governed source is named by its version. That way the coordinator has it to pass on.
- *Format.* Every part comes back in the same columns, so the results join cleanly. The worker says how it split the job, and lists every input by its identifier, so you can see that nothing was dropped or counted twice.
- *Constraints.* In the autonomy half, say whether the worker may split the job and how, and that every limit holds for every helper. A helper may not do what the worker may not do.

These are the lines Maria would add to 5.1's brief. "In parallel" means at the same time:

```markdown
Outcome:     You are responsible for the whole proposal. Every open
             invoice appears in it once. The total, the duplicate check
             and the exceptions list use every checked row.
Context:     Every part of the work follows this context.
Format:      Every part returns rows in the CSV's columns. Start by
             saying how you split the job. End with every invoice
             number you received, and the row or list it went to.
Constraints: You may check each vendor's invoices in parallel. Every
             limit in this brief holds for every part of the work.
```

For a small job, or one where each step needs the last, say the opposite in one line: "Do this yourself. Do not hand any part of it to a helper." While the work runs, you can also steer in plain words, such as "check these five sources in parallel."

A split does not move a checkpoint. Helpers work inside a stage. The stop after the exceptions list still waits for Maria. And words in a brief are instructions, not locks. State the limits in words, and set the product's permission controls to match, where it has them (5.8). [Chapter 7](../the-authority-envelope/overview.md) sets the outer limit.

Either of you can split a job. Split it yourself, in stages, when a person must decide between the parts. Let the worker split it when the parts can run side by side and you need only the combined result. Then check the combined result, not the worker's account of how it got there. Where the app shows each helper's work, look at it. Either way, count the inputs against what came back, and test a few rows against the governed source. [Chapter 6](../the-review-contract/overview.md) shows how to review the result.

**The working rule:** let the worker split a job only where the parts can run on their own. Put every rule the parts need in the brief, make the coordinator responsible for the whole result, and check that every input came back. Chapter 26 shows how a worker splits a job this way, and Chapter 28 shows what splitting costs.

[^anthropic-multi-agent]: How we built our multi-agent research system, Anthropic Engineering.
[^v1-thesis]: The Agent Factory Thesis, Panaversity, first edition.
[^anthropic-cowork-start]: Get started with Claude Cowork, Claude Help Center.
[^claude-code-subagents]: Create custom subagents, Claude Code Docs.
[^openai-subagents]: Subagents, ChatGPT Learn, OpenAI.