
One lane per task
Every lane is its own git worktree — its own branch, files, and sessions. That isolation is the whole game: two agents in two lanes can’t touch each other’s working tree, so they run in parallel without stashing, rebasing, or fighting over the same files.Good task splits
A clean split has slices that touch different files and can be reviewed on their own.| Goal | Better split |
|---|---|
| ”Improve onboarding” | Copy fixes, provider validation, first-run UI, tests. |
| ”Fix checkout bugs” | Repro the failing case, patch backend, patch UI, add regression tests. |
| ”Ship mobile sync polish” | Desktop status, iOS display, reconnect behavior, docs. |
Watch for collisions
Parallel agents stay safe as long as their work doesn’t overlap. Most collisions come from scope creep, not from the tool.- Don’t send two agents into the same lane for unrelated work.
- Avoid broad prompts that invite repo-wide edits — keep each agent narrow.
- Use child lanes when one task genuinely depends on another, rather than racing them.
- Merge parent work before rebasing children when possible.
- Use History to see exactly what each session changed.
Grid vs. separate lanes
Both run agents in parallel, but they answer different questions.Grid view
Same task, several models — race a narrow, well-specified change and keep the best diff. Each tile is a full chat.
Separate lanes
Different tasks — give each its own worktree so broad, multi-step work never competes for the same files.

Grid & multi-model
Run several agents at once and compare side by side.
Lanes overview
Isolate each task in its own worktree.
