Run Your First Parallel Task

Parallel delegation end to end: two worktrees from one base, an agent in each, both results reviewed separately, then integrated and cleaned up.

Updated Sep 5, 2026

Reviewed Sep 5, 2026

Everything up to here was the setup. Do this once deliberately, before you need it: learning what the isolation covers halfway through real work is a bad time to find out.

Before you start — about 15 minutes

Daintree installed, with at least one agent CLI that launches.
A Git repository with an initial commit, open as a project, and one you do not mind experimenting in. Worktrees need the commit. See Open your first project if the folder you opened is not a repository yet.
Two small, independent tasks. This page uses "add a README badge" and "rename a helper". Pick tasks that touch different files, so the first thing you learn is the workflow rather than conflict resolution.
Worth having, not required: a clean working tree on your base branch. It makes the diffs at the end easier to read.

Both branches start from the same commit, so both diffs are measured from the same place. That is what makes each result readable on its own.

Create two worktrees

A worktree is a second checkout of the same repository, on its own branch, in its own directory. Two agents in two worktrees edit two separate sets of files on disk. Neither writes over the other's working copy, and neither waits for the other.

The Create New Worktree dialog. A Link Issue field sits above a two-segment New Branch and Existing Branch toggle with New Branch selected. Below it, Base Branch reading main (current), a New Branch Name field with the placeholder feature/add-user-auth, and a Worktree Path field with a folder-picker button beside it. A Create from remote branch checkbox sits at the foot, above Cancel and a green Create button. — The dialog opens in New Branch mode, with your current branch already chosen as the base

Open the New Worktree dialog. Press Command-K, then Command-N Control-K, then Control-N Control-K, then Control-N , or click + at the top of the worktree sidebar.
Check the base branch. The Base Branch field names what this worktree forks from. Both tasks have to start from the same one, so whatever it says now, it needs to say the same thing the second time through.
Name the branch feature/readme-badge. As you type, Daintree suggests type prefixes. The Worktree Path fills in from your path pattern — leave it alone.
Click Create. Daintree makes the branch, checks it out into its own directory, and selects it.
Do it again for chore/rename-helper, from the same base branch.

You should now see

Two new cards in the worktree sidebar, named feature/readme-badge and chore/rename-helper. Each is a real directory on disk with its own checkout — run git worktree list in a terminal if you want to see them from outside Daintree.

Warning

A worktree isolates changes, not processes. Each agent runs as your user account and can reach the rest of the filesystem, the same as it would in a terminal. Separate checkouts stop two agents editing the same working copy. They are not a sandbox. See Remote Compute for actual process isolation.

Launch an agent in each

The launcher is the + at the head of the toolbar. It is not the + in the worktree sidebar you just used — that one makes worktrees, this one starts agents, panels and recipes.

The launcher popover hanging off the toolbar plus button. Under a Search agents, panels, and recipes field, a Pinned band lists Claude, OpenCode, Gemini, Antigravity and Codex, each an Agent row with an installed-state pip, a shortcut chip on the ones that have one, and a trailing pin toggle. An Other band of further agents follows, then a Launch panel band holding Terminal, Browser and Dev Preview. — One searchable launcher covers agents, panels and recipes

Select the feature/readme-badge card in the worktree sidebar. Click it by name — sidebar position shifts as the list re-sorts.
Open the launcher and start an agent. Claude Code has a default shortcut of Option-Command-C Control-Alt-C Control-Alt-C ; Codex is Option-Command-X Control-Alt-X Control-Alt-X . Any agent works.
Give it the first task. The agent is already in that worktree's directory, on that worktree's branch. You do not cd anywhere and you do not check anything out.
Select the chore/rename-helper card and do the same with the second task.

You should now see

Two agents running at once. Switching between the cards changes which panels you are looking at; it does not stop anything. The first agent keeps working while you set up the second, and that is worth watching happen once.

Watch the states, not the output

Two agents are running and you have one screen. Rather than switching between them to check, let the states come to you. The worktree cards carry agent state on each row, aggregated into a single status when the card is collapsed.

The worktree sidebar for a project named atlas-ledger. A search field and filter button sit above the project row, then a tab strip reading All 4 with three state-filter counts. Four worktree cards follow — dependency-bump, rounding-drift, reconciliation and multi-currency — each with an icon, a branch name, an elapsed time, and a status row carrying a commit summary or a changed-file count with added and removed line numbers. — Each card's status row is the signal: a commit summary, or a changed-file count with its added and removed lines

A Waiting for input popover headed with a count of 3 agents. Three rows follow, each naming a run and its project: Settlement migration on atlas-ledger with an amber Approval tag and 40s, Statement importer on atlas-ledger with a red Error tag and 23s, and Currency table on atlas-ledger marked now. — An agent that is waiting names what it wants — an approval, or an error to look at

Watch the two cards rather than the two terminals.
Answer whichever agent asks first. The other keeps working while you do. Nothing is queued behind your attention.
Wait for both to finish. Not every agent stops to ask a question; some run straight through.

You should now see

Both cards show a finished run with changed files against them, and neither is still asking you for anything.

Two other surfaces exist for when this stops scaling, and neither is worth configuring on your first run. Pilot (Option-Command-O Control-Alt-O Control-Alt-O ) lists every run across every project, ordered by what needs attention; Option-Command-I Control-Alt-I Control-Alt-I narrows it to this project and groups it by worktree. With two agents it is overkill; with twenty it is the view that scales. Notifications can tell you when an agent blocks or finishes, so you can look away entirely — completion popups are off by default and OS notifications need Watch enabled.

Review each result separately

When an agent finishes a run that changed files, a banner appears at the bottom of its pane reading "N files changed, review when ready."

The Review and Commit surface in Working tree mode. A branch chip reads feature/reconciliation beside a No PR chip, with a Working tree and vs main toggle at the right. A Ready status line sits above a Staged section listing two files with their added and removed line counts and Viewed checkboxes, then an empty Changes section reading All changes staged, then a commit message box and a Commit and Push button. — Working tree mode: staged files, unstaged changes, and the commit composer, scoped to one worktree

Click Review on the feature/readme-badge pane to open Review Hub for that worktree. It opens in Working tree mode.
Open each changed file and read the diff. This is the step the whole arrangement exists for. Check the change against the task you actually asked for.
Discard anything you did not want, then stage what is left.
Write a commit message and commit. Push if you intend to open a pull request.
Switch to chore/rename-helper and do the same. Because the two tasks ran in separate worktrees, you are reading one agent's work at a time, with nothing of the other's mixed in.

You should now see

Both branches carry a commit you have read. Review Hub shows no unstaged changes you did not mean to leave behind.

Warning

Review is the point of the arrangement, not a formality. Two agents can produce two plausible diffs in the time it takes to read one, and Daintree does not gate git: an agent can run git itself in its own terminal. The separation buys you the ability to judge each result on its own. It does not judge them for you.

Integrate the reviewed branches

Committing and pushing does not merge a task branch. Until you integrate, the work exists only on its own branch, and deleting the worktree is the point at which that becomes a problem.

Warning

Merging changes the branch you merge into. Confirm you have reviewed the diff and that your checks pass before you merge, and confirm which branch is the target — this is the step that puts an agent's work in front of everyone else.

Confirm the target branch — the branch both tasks started from.
Integrate feature/readme-badge, by whichever route you use. On a forge: push the branch, open a pull request against the target, and merge it. Locally: merge the branch into the target from the worktree that already has the target checked out — usually your original one. Git will not let you check the target out a second time in a task worktree, because it is checked out somewhere already.
Do the same for chore/rename-helper. Two separately reviewed branches, integrated one at a time.

You should now see

Both changes are present on the target branch — the README badge and the renamed helper, together, in code you read before it got there.

Clean up

A merged worktree has done its job.

Warning

Deleting a worktree removes its directory from disk, and anything in it you never committed goes with it. Commits are safer than that — they live in the repository, not in the checkout, so they survive as long as some reference still points at them. The branch is usually that reference, which is why deleting it is the part worth thinking about: Daintree asks Git to delete the branch safely, so Git refuses if the branch holds work that was never merged. Doing this after the work is integrated means the question never comes up.

Open the card's menu and choose to delete the worktree.
Read what it says will happen before you confirm. The dialog spells the consequences out rather than asking you to remember them.
Decide about the branch. The directory goes either way; the branch goes only if you ask for it. Close all terminals is checked by default.
Uncheck Close all terminals if you want the agents to survive. The row stays in the sidebar as a deleted-worktree card with a countdown, and you can drag a terminal from it onto a live worktree to keep the session. The directory is still gone, so this rescues the running sessions rather than the files. See Deleted Worktrees for the full behavior.
Confirm. Then do the same for the second worktree.

A deleted-worktree card in the sidebar. It names the branch bugfix/rounding-drift beside a Deleted badge, with a struck-through directory path under it, a countdown reading 58s and a trash icon on the right. A row below reads 1 active with a waiting-agent indicator. — With Close all terminals unchecked, the row stays behind as a deleted-worktree card: the directory is gone, the agent is not

You're done when…

Both tasks ran at the same time, in separate worktrees.
You read each diff on its own before it went anywhere.
Both changes are on your target branch.
Cleanup is housekeeping, not proof. Delegation worked the moment both reviewed changes landed — whether or not you deleted the worktrees afterward.

What you just learned

The habit	What replaces it
One agent at a time, so two cannot tread on each other	One worktree per task, so their working copies are separate
Checking each terminal to see if it needs you	States on the cards, and Pilot when there are too many cards
`git diff` in whichever terminal is current	Review Hub, scoped to one worktree's changes
Merging when the agent says it is done	Merging when you have read it

Two is the demonstration. The arrangement does not change at five or at twenty: you add worktrees, and the attention surfaces do the sorting. The next thing worth doing is Recipes, which turns the workspace you just set up by hand into one click. Fleet is for when you want to send one instruction to several agents at once instead of one at a time.