---

name: workflow-parallel-agents description: Run multiple agents in parallel via git worktrees, cloud agents, or multi-model comparison. Use for "run agents in parallel", "best-of-N", "compare approaches", "multi-model", "parallel worktrees". license: MIT

Parallel Agents & Worktrees

Degree of freedom: MIXED. What to split, how to brief, and which model or effort [HIGH freedom]; isolated worktrees and no shared-file writes [LOW freedom — run exactly].

How to reason

1. Observe — independent tasks vs one shared file
2. Interpret — worktree / cloud / best-of-N
3. Classify — parallel-safe / must-serialize
4. Severity — two agents editing one path is a conflict, not speed

Worked example

Observe: "fix tests" and "write the README" touch different trees. Interpret: two worktrees, two agents. Classify: parallel-safe; do not also give both package.json. Merge: integrate one result at a time; compare best-of-N on the same prompt.

Self-critique before reporting

• Isolation — no two agents owned the same files
• Prompt named — each delegate had a concrete done-check
• Compared if best-of-N — a winner was picked with a reason
• Right owner — one sequential feature → workflow-build-feature

Why Run Agents in Parallel? [HIGH freedom]

• Compare approaches: same brief to several agents (Cursor: different models; Claude Code: subagents, optionally at different effort) → pick the best result
• Isolate work: Each agent edits its own files without conflicts
• Delegate background tasks: Offload bug fixes, tests, docs while you work on something else
• Speed: Multiple independent tasks done simultaneously

When delegation pays [HIGH freedom]

Delegate when a track is independent, sizeable, and can run beside the others, or when its output is verbose and you do not need it in the main context (log reads, wide exploration, a full test run). A handful of tool calls is cheaper to do yourself than to brief.

Brief each delegate once and precisely — goal, files, constraints, the done-check, and what to report back — then commit to the delegation: do not redo its work in parallel. Launch independent agents in one message so they run at the same time; integrate results one at a time.

Claude Code: each delegate is a subagent (built-in Explore for read-only work; a general agent or one from agents/ for edits). A subagent that writes files gets isolation: worktree in its agent frontmatter, or its own git worktree add, so two delegates never own the same path. Cursor: the worktree and cloud options below.

Git Worktrees (Local Parallel Agents) [LOW freedom — run exactly]

How It Works

Cursor creates an isolated git worktree per agent from the agent dropdown; in Claude Code the equivalent is isolation: worktree on the subagent (see above). Each has its own:

• File system (changes don't affect other agents)
• Build/test environment
• Branch

When an agent finishes, click Apply to merge changes back.

Starting a Worktree Agent

1. Open the agent dropdown
2. Select the worktree option
3. Submit your prompt
4. While it runs, start another agent in a different worktree

Best Use Cases

• Running the same hard problem across 3 models simultaneously
• Implementing 2 independent features at once
• Having one agent write tests while another writes implementation
• Trying 2 different architectural approaches before choosing

After Agents Finish

• Review diffs side-by-side
• Cursor suggests which solution it recommends (multi-agent judging)
• Click Apply on the winner
• Discard the others

Cloud Agents (Background Delegation) [HIGH freedom]

When to Use

Delegate tasks you'd otherwise put on a todo list:

• Bug fixes that came up while working on something else
• Writing tests for existing code
• Documentation updates
• Refactoring recent changes
• Dependency updates

Starting a Cloud Agent

• From Cursor editor: agent dropdown → cloud option
• From web: cursor.com/agents
• From phone: Cursor mobile app
• From Slack: @Cursor <task description>

How Cloud Agents Work

1. Describe the task + relevant context
2. Agent clones your repo, creates a branch
3. Works autonomously (you can close your laptop)
4. Opens a PR when finished
5. You get notified (Slack, email, or web)
6. Review and merge

Writing Good Delegation Prompts

# Good delegation prompt
Fix the bug where users see a 500 error when they submit the onboarding form
with a duplicate email. The error should show an inline message "Email already
in use" instead of crashing. See `app/onboarding/actions.ts` for the server
action and `app/onboarding/page.tsx` for the form.

# Bad delegation prompt
Fix the email bug

Include:

• Exact behaviour (current vs expected)
• File paths if known
• Acceptance criteria
• Any constraints ("don't change the API contract")
• A time signal when the run is clocked: "Time matters here: do not spend time that can be avoided." Delegates weight it.

Running Multiple Models on the Same Prompt [LOW freedom — run exactly]

1. Open agent dropdown
2. Select multiple models
3. Submit prompt once
4. Cursor runs all models in parallel
5. Compare results; Cursor recommends the best

Claude Code: send the same brief to N subagents in one message (different effort levels, or a different approach named in each brief); compare the candidates yourself or hand them to a fresh-context reviewer that flags only correctness and requirement gaps.

Best for:

• Architecturally significant decisions
• Hard bugs where different models take different approaches
• When you want to verify the solution is correct

Notifications [LOW freedom — run exactly]

When running many agents, configure:

• Settings → notifications → agent completion
• Sounds for agent completion (hear it finish across the room)
• Slack integration for cloud agents

Patterns [HIGH freedom]

The Parallel Spike

Run 2-3 agents with different approaches to a hard problem:

• Agent A: "Use optimistic updates with TanStack Query"
• Agent B: "Use server-sent events for real-time sync"
• Agent C: "Use Supabase Realtime subscriptions" Compare all three, pick the cleanest.

The Background Test Writer

While implementing feature X locally:

• Cloud agent: "Write tests for the auth flow in features/auth/"
• You: implement feature X
• Merge both when done

The Parallel Review

One agent reviews for security, another for performance:

• Agent A: "Review app/api/ for security issues (auth, input validation, RLS)"
• Agent B: "Review app/api/ for performance (N+1s, missing indexes, large payloads)"

Each reviewer reports only findings in its lane, with file:line evidence — not style or general cleanups.

Worktree Tips [LOW freedom — run exactly]

• Each worktree needs its own node_modules if deps differ
• Share .env by symlinking or copying to each worktree
• Worktrees share git history — easy to cherry-pick between them
• Clean up finished worktrees: git worktree remove <path>