Skip to lesson
AGENTIC
ACADEMY
INTERACTIVE LAB 01

One Prompt, A Tree of Agents

Learning mode

Why delegate

STEP 1 / 3
CHAPTER 01STEP 1 OF 3

One big job, or three focused ones?

Pull request #142 changes the sign-in code, its tests, and the docs. Watch what piles up in the main conversation.

MAIN CONVERSATIONOne agentReviews the sign-in code, the tests, and the docs itself.
CONTEXT USED
  • Request
  • Predict first
PREDICT BEFORE YOU CONTINUE

One agent reviews all three areas itself. When it finishes, what is in its conversation?

Choose an answer. You can change your mind after seeing the explanation.

1

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.

Go deeper

For a quick change to one file, stay in the main conversation. A fresh specialist has to gather context before it can start.

Delegation is not free: the parent writes briefs and combines reports, and every specialist makes its own model calls. Chapter 4 compares time and cost.

The Claude Code documentation lists more reasons to delegate: limiting which tools a specialist can use, reusing an agent across projects, and routing work to a faster, lower-cost model.

Claude Code documentation ↗

Documentation reviewed 6 October 2026. Product behavior can change; lesson limits and durations are illustrative.
01 / 21Doing it alone
READ AT YOUR OWN PACE

The complete lesson

All seven chapters in text. Switch between English and your second language anytime. No account or API key is needed.

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 ↑

A reusable delegation brief

Review pull request #142 for authentication defects.
Scope: src/auth.ts and tests/auth.test.ts.
Constraint: review only; do not change files.
Tools: Read, Grep, Glob.
Return: findings with file and line, evidence, and a suggested test.
Stop after reviewing this scope. Report uncertainty and missing evidence.
The parent will combine your findings with the other reviews.

Or select the text above to copy it manually.

Inspired by the original Subagents deck. Claude Code examples, reviewed 6 October 2026. Agentic SDLC home ↗