In the lesson on branches and worktrees, we kept two agents' game features in separate folders, reviewed their changes, and merged them into main. This gave us a way to work on two features at once without mixing their edits. This video explains how to do that in Claude Code. We'll look at subagents, at running several sessions side by side, and at how your own time for answering questions and reviewing results limits how many agents you can usefully run.
There is one operator in this example, and that is you. The other participants are agents that you start yourself or ask another agent to start.
The first approach stays within one session. The agent you talk to is the main agent, and it can start other agents for pieces of the work. These are called subagents. You give the task to the main agent, and it coordinates their work.
The second way is to open several sessions yourself, one terminal each, and run them side by side. Each of those is an ordinary session with its own agent, and you talk to each one directly.
These two ways of running several agents suit different tasks. By the end of the video, you should be able to choose between delegating a task and following it in a separate session.
Here is your session. The agent you are talking to in it is the main agent. It has its context window, with the conversation so far in it, and when it has a question, it stops and asks you.
When the main agent delegates a task, it starts a second agent and gives it a brief describing the work. For a fresh subagent, that brief supplies the task-specific background from your conversation.
The fresh subagent has its own context window. It does not inherit your earlier conversation or the contents of files the main agent read. Its setup also supplies instructions and tools, and may load project instructions. The brief therefore needs to include the earlier decisions that matter to this task.
An ordinary subagent works from that brief and the information it reads for itself. It cannot use the normal question tool to stop and interview you. If the brief leaves a decision open, it may make an assumption or report that it could not finish.
When it finishes, it sends a report back to the main agent, not to you. The main agent reads the report and decides what to tell you. That second agent is what we call a subagent. It is a second agent that the main agent starts for one delegated task.
The point of the separate window shows up when you look at what the subagent puts in it. It starts with the brief.
Then it reads files, runs commands, hits errors, and tries again. All of that lands in its own window, and by the time it is done the window can be quite full.
The report comes back into the main agent's window. The file reading, commands, errors, and retries stay in the subagent's separate context rather than being copied into the main conversation. Its transcript can remain available if we need to inspect or resume the work.
This separation is useful because the context window is limited. A large codebase can contain far more information than fits in one window. Each subtask can gather the context it needs, while the main agent keeps the conclusions it needs to coordinate the work. Subagents therefore help manage context even when their work runs one task at a time. Running independent subtasks in parallel can also save time.
There are two starting points to distinguish. A fresh subagent starts with a task brief and its configured instructions, without the earlier conversation. That suits a self-contained task that needs a small, focused context.
The other kind is called a fork. A fork starts with a copy of the whole conversation so far. It has the same history, the same tools and the same model as the main agent, so you can hand it a task that depends on everything already discussed, without writing any of that into a brief. In the version shown here, you can start a fork by typing slash subtask followed by the task. The main agent can also start one when the work needs the full history.
Either way, the fork's own reading and trial and error stay out of the main agent's window, and only its result comes back. So the choice is about the starting point. A task that stands on its own gets a fresh subagent. A task that needs what you have already worked out together gets a fork.
So how do you actually ask for several subagents? You say so, in words. Here is a prompt for a website we are building. Please open four subagents, one per variant of the landing page, minimal, bold, dark and playful. Run them in parallel, each on its own branch in its own worktree, and report back when all four are done.
The main agent starts the four subagents and writes a brief for each variant. You can request this in ordinary language, then check that the four tasks and their separate worktrees match what you asked for.
Let's look at what that one prompt sets in motion. It asked for four variants in parallel, one subagent each, each on its own branch in its own worktree, without touching main.
The main agent starts four subagents, and each one gets a brief describing its own variant.
Each subagent works on its own branch in its own worktree. Ask the main agent to arrange those folders before the subagents start editing. This uses the same separation as the two game features in the branches and worktrees lesson. Here we have four alternative landing pages, so we can compare them and choose what to keep. We do not need to merge all four alternatives.
The instruction is to leave main unchanged and wait for your review before merging. Check the four results and choose which work to keep. Give each subagent a complete brief so it can work without needing a conversation. If you leave the same decision open, the four agents may make four different choices.
While the subagents run, you can see them in two places. The first is the transcript. It shows a row named Agent, with the task in brackets, and under it a progress line with how many tools it has used and how many tokens it has consumed.
The second is a panel that appears under the prompt while subagents are running. It has one row for the main agent and one row per subagent, each with its status. The up and down arrows move between the rows, Enter opens the transcript of the selected subagent, x stops it, and Escape takes you back to the prompt.
The panel shows the running subagents in this session. A successfully finished subagent disappears from the panel, and its report reaches the main agent.
There is one more list, and it is wider than subagents. The command slash tasks shows everything the session is running in the background. That includes the subagents, running or recently finished, and also background commands, like a build or a test run that the agent started and did not wait for.
Use slash tasks when you want to check the background work associated with this session, including its commands and subagents.
You can still give a subagent a correction while it works. Open its row with Enter, read its transcript, and type a message. The subagent receives that message and can use it as it continues.
The main agent can do the same. While a subagent runs, the main agent can send it messages, and when the subagent finishes, the main agent is notified and receives its report. That is how a correction you give the main agent can reach a subagent that is already halfway through.
A subagent can also need permission for an action. That prompt appears in your main session with the subagent's name. You can approve or deny the action. If you deny it, the agent may find another approach or report that it is blocked.
A complete brief lets an ordinary subagent work without an interview, while messages let you or the main agent correct it during the run. A fork keeps all of the main agent's tools, including the question tool that an ordinary subagent loses.
The second way to run several agents is simpler to describe. You open more than one session. Here is one, in its own terminal, working on the site's contact form.
Here are two more, each in a terminal of its own, one on the pricing page and one on the blog layout. These are ordinary sessions, exactly like the one you have been using since week one, only there are several of them at the same time.
Each session has its own terminal, context window, and permission mode. One can be in plan mode while another accepts edits. These sessions work independently, so you need to tell each one about decisions that affect its task.
A session you follow can stop and wait whenever it needs your answer. Two of the three sessions here are waiting, one at a permission prompt and one on a question.
To help you follow several sessions, Claude Code provides a screen called agent view. Pressing the left arrow on an empty prompt moves the current session to the background and opens that view. Other terminal sessions appear after you background them too. Each row is a session, grouped by state. The first rows show sessions needing input and sessions still working.
Pressing Enter on a row opens that session in your terminal, and the left arrow on an empty prompt brings you back to the list. Pressing Space instead shows a peek at the session's recent output, and you can type a reply right there without leaving the list. From the same screen you can also start a new session. You type a task at the bottom and press Enter, and a new session begins on it. Before it edits anything, it moves into a worktree of its own.
Check the group that needs your input regularly. These sessions have paused for a question or approval, so answering them lets their work continue.
If two sessions edit the same folder, they can change the same files at the same time. One may overwrite a change the other just made, or continue from contents that have already changed. The combined file may be something neither agent intended.
With one worktree per session, each agent edits its own working files on its own branch. The worktrees share the repository's history and references, but file edits in one working folder do not change the other's working files. You decide when to merge their changes. A worktree separates edits, but it is not a security sandbox.
Ask the agent to set up its worktree before starting the task. Check the folder before it edits, because creating a worktree later does not separate changes it already made in the shared folder.
Now, which tasks go to a subagent, and which get a session of their own? A task whose brief is complete can be fanned out. If you can describe a footer with the address, a favicon, or a cookie banner well enough that nothing will need asking, a subagent can build it without you.
A task that will need a conversation gets a session you follow. A pricing page raises questions before it can be built, a signup flow needs decisions along the way, and a colour scheme has to be shown to you and adjusted. Those need you in the loop, so give each one a session and stay with it.
The question to ask is simply whether the task will need you during the run. If it will not, delegate it. If it will, keep it where you can answer.
This diagram illustrates how questions can limit parallel work. Blue stretches represent agent work, and amber stretches represent waiting for your answer. With one session in this example, you answer quickly and the waits are short.
With three sessions in the example, you answer one while the others wait. Their waiting periods grow because their questions join the same queue for your attention.
With five sessions in the example, the last two spend most of their time waiting. The fifth asked a question early and has not yet received an answer. Opening those extra sessions has added little completed work.
When a session pauses for your answer or approval, that work waits until you respond. If several sessions need you at once, adding more can lengthen the queue instead of increasing the amount of work completed. Your attention is therefore one limit on useful parallelism, alongside the tool's capacity and usage limits. Try different numbers of sessions and find how many you can answer and review without a growing backlog.
The command slash cost shows session usage information. The example includes an estimated cost of fifty-five cents and two durations. With included subscription usage, an API-priced estimate is not an extra bill, though separately enabled extra usage can incur charges. The durations help us examine how the session spent its time.
The A-P-I duration measures time spent on model requests, while wall duration measures elapsed session time. Here they are six minutes twenty seconds and forty-one minutes ten seconds. The display also records two hundred and twelve lines added and thirty-eight removed.
The difference is thirty-four minutes fifty seconds, roughly thirty-five minutes outside model requests. That can include waiting for you, but also tool execution and other delays, so it is not a direct measure of your response time. Collect these durations across parallel sessions and compare them with the questions left waiting. Together, they can help you judge how many sessions you can follow.
A subagent is useful when you can give it a complete task and review its report. A separate session is useful when you expect a conversation and want to answer decisions as they arise. Subagents also keep their detailed work out of the main agent's context.
For parallel editing, give each agent its own worktree before it changes files. Then watch how much work is waiting for your answers and review, because extra agents help only when you can keep up with those decisions. You can now choose how to divide the work: delegate tasks with clear briefs, follow tasks that need discussion in separate sessions, and use worktrees to keep their edits separate until review.