01Why delegate
Pull request #142 changes the sign-in code, its tests, and the docs. Watch what piles up in the main conversation.
Doing it alone. One agent reviews the sign-in code, the tests, and the docs by itself. Predict what its conversation holds when it finishes, then watch it fill.
Hand off focused jobs. The parent gives each specialist a short brief. Each specialist reads files in its own separate conversation, so that reading never reaches the parent. Select a specialist to see its brief.
Get short reports back. Each specialist returns a short report with file and line. The parent holds three reports instead of all that reading, and still decides what to recommend.
Takeaway: Delegate a job that is self-contained and creates a lot of reading you don’t need to keep. You get a short report back; the decision stays with you.
Prediction explained: Everything the agent opens stays in its conversation. By the time it writes the recommendation, most of what it holds is raw reading it no longer needs.
Open this chapter ↑02What crosses the boundary
A fresh reviewer gets its own configured context and a task brief. Your earlier conversation is a separate source of information.
Predict the boundary. Earlier, the user said “review only; do not change files.” Will a fresh subagent know that conversation-only instruction if the parent leaves it out of the brief?
Deliver the brief. Follow the task brief across the boundary. Try omitting the review constraint, then repair the brief. A path helps the reviewer start, but access to tools may also let it discover files.
Compare a fork. Switch between Fresh and Fork. A conversation fork inherits the conversation at the branching point. Later work still has its own history. Context isolation alone does not create an isolated file system.
Takeaway: Make the brief self-contained. Choose a fork deliberately when the task needs the existing conversation.
Prediction explained: A fresh subagent does not inherit that conversation. Shared project guidance or permission rules may still apply independently. A conversation fork is a different mode.
Open this chapter ↑03Define the specialist
Instructions describe the work. Tools determine which actions are available. A skill can supply a reusable review method.
Choose the role. Choose a security, test, or documentation reviewer. Its task, expected evidence, and configuration change together. A useful description tells the parent when this specialist is a good match.
Try a capability. Keep the reviewer read-only, then attempt a file edit in the simulation. Enable Edit and try again. Tool availability and permission approval are separate checks.
Add a review method. Preload the review checklist to add a repeatable method to the agent’s starting context. Open Technical details to inspect the corresponding agent file and invocation patterns.
Takeaway: Pair a clear task with the smallest useful tool set, and specify what evidence should come back.
Open this chapter ↑04Coordinate the work
Independent reviews can overlap. The final recommendation still needs their results.
Predict the trade-off. Before comparing the schedules, decide whether parallel work necessarily reduces the total amount of work billed across agents.
Compare the timelines. Switch Sequential and Parallel. These illustrative reviews take 30, 20, and 10 seconds. Both schedules add 5 seconds to brief the workers and 3 seconds to synthesize their reports.
Let the parent continue. Switch Foreground and Background. Background lets the parent prepare an independent release-note outline. It still waits for all review evidence before writing the final recommendation.
Takeaway: Concurrency changes elapsed time. Background execution changes what the parent can do while it waits.
Prediction explained: Overlapping requests can reduce elapsed time while leaving total work unchanged or increasing it through coordination. The timeline below isolates scheduling; it does not estimate API charges.
Open this chapter ↑05Bound the tree
The security reviewer wants a verifier for one finding. Explore how depth, capacity, and a small work budget change the plan.
Set the boundaries. Concurrency is simultaneous workers. Depth is layers below the parent. The budget here reserves invented work units before admitting each job. It is a teaching scheduler, not live billing.
Run the bounded plan. Change one limit at a time. With depth 1, the security reviewer performs verification itself. With depth 2, it can request a separate verifier after its initial review.
Inspect unfinished work. If the budget cannot admit a job, its work remains unfinished. The parent must report the gap instead of turning a partial review into an all-clear. Reset restores the complete example.
Takeaway: A limit should produce a visible change of plan or an honest partial result.
Open this chapter ↑06Return and resume
The reviewer found a missing expired-token test. The parent receives the evidence and asks a follow-up.
Return the findings. The review report names the issue, its location, and a suggested verification. The parent evaluates the evidence. A subagent’s report is not a new user instruction or approval.
Continue the investigation. Compare Resume and New agent. A resumed reviewer has its earlier available transcript. A new reviewer needs a brief and must gather any missing evidence again.
Own the recommendation. The parent combines all reports, records the missing test, and recommends a fix before approval. The human reviewer retains the final decision. Read the transcript below for a text version of every scene.
Takeaway: Ask for evidence in the report. Resume an eligible agent when earlier investigation is useful.
Open this chapter ↑07Make the call
A pull request changes authentication, tests, and docs. You have three independent review questions and want evidence before approving.
Choose a plan. Select the plan that gives each reviewer enough context and keeps the final decision with the parent. You can revisit any chapter before answering.
Explain the choice. A good plan bounds the work, includes important constraints, and requests file-level evidence. Parallelism is useful here because the investigations can proceed independently.
Take it into your work. For your next delegation, name the goal, relevant files, constraints, available tools, expected evidence, and stopping condition. Use the brief below as a starting point.
Takeaway: Useful delegation begins with a bounded question and ends with checked evidence.
Prediction explained: Focused read-only reviews avoid conflicting edits and can run independently. The parent compares their evidence, identifies gaps, and owns the recommendation. For a one-line typo, a single agent would usually be enough.
Open this chapter ↑