Background Agents and Parallel Execution: Run Eight Tasks at Once Without Conflicts

You can spin up eight coding agents in one session. Cursor productized that ceiling with isolated Git worktrees and cloud Background Agents. Claude Code added background tasks, subagents, and experimental Agent Teams with shared task lists and dependency unblocking.

The hard problem is not concurrency. It is isolation of the working tree, dependency-aware scheduling, and recombination without silent corruption.

Worktrees convert invisible overwrites into normal git conflicts. They do not remove merge work, shared ports, databases, or token cost. If you treat "eight agents" as a speed dial and skip ownership rules, you get thrash with a higher bill.

What productized parallel actually looks like

Cursor's pattern is straightforward: each agent gets its own workspace (local worktree or remote VM), so two attempts cannot clobber the same index. Cloud Background Agents can run tests, capture screenshots, and open a PR. One catch for client work: cloud paths usually require privacy mode off. That is a policy decision, not a UI detail.

Claude Code's experimental Agent Teams push further toward orchestration. A lead session plus teammates share a task list (pending, in progress, completed). Tasks can declare depends_on, so blocked work cannot be claimed. Claims use file locking to reduce double-claim races. Completing a task unblocks dependents. Teammates get mailboxes under a team directory. That is a Kanban board for agents, not magic concurrency.

incident.io published a useful human-scale case (June 2025). Their engineers moved from multiple Claude sessions on one checkout to Git worktrees, then built a small launcher so starting a feature branch plus Claude was low friction. They routinely run four to five parallel agents. One tooling win: about $8 of Claude spend and five minutes of human work for an 18% faster API client generation path. Another: a JS editor feature planned as roughly two hours landed about 90% working in about ten minutes. Architecture stayed human-owned. Shared ports and local DBs still limited true parallel environments.

Those are the anchors. The rest of this post is how you keep parallel work reliable.

Isolation is layered. Worktrees are only layer one.

A worktree creates a separate checkout that shares the object store. Creation is cheap (on the order of a second). Disk cost is not. You pay for a full working tree plus whatever that tree installs: node_modules, build caches, virtualenvs.

A real Cursor forum report on a ~2 GB repo (IsaacLab) is worth internalizing: two auto-created worktrees used about 9.82 GB in twenty minutes. Over a week, 20+ worktrees approached ~140 GB. Product defaults often keep many worktrees per workspace and clean on a timer. Cleanup lags. Cap concurrency and prune dead trees on purpose.

Here is what each isolation layer actually buys you:

Layer	Mechanism	Prevents	Does not prevent
Working tree	Git worktree / cloud VM	File overwrites, index corruption	Merge conflicts later
Branch	One branch per agent/task	Shared HEAD chaos	Same-feature design drift
Claim / lock	Task list + file locks	Two agents claiming one ticket	Overlapping file edits
Scope policy	Directory ownership, single-writer	Hotspot thrash	Bad architecture
Runtime	Ports, DB name, Docker project	Env collisions	Repo-level merge issues

Filesystem isolation is not environment isolation. Port 3000, Postgres on 5432, Docker container names, and monorepo caches are still shared on one machine. The second agent's dev server fails. Two migrations hit one database. The hybrid pattern that holds up: worktree plus port offset by worktree index, or a DB (or container project) per worktree.

Research systems rhyme with the product story. SwarmResearch and CAID-style managers put agents on per-agent branches or worktrees and treat merge as a completion signal. Claim Plane (2026) frames concurrent agents as a pre-write admission problem: isolation alone does not stop integration-time interference or scope expansion. You still need rules before anyone writes.

Schedule with a dependency graph, not a pile of tickets

Parallel agents work when tasks are independent mergeable units. Sequential or same-file work should stay in one session or cheap subagents. Anthropic's own Agent Teams guidance is blunt: start with three to five teammates; token cost scales roughly linearly; prefer independent work.

Decompose features into directory-owned slices with explicit dependencies:

Wave 1: schema and shared types (single writer).
Wave 2: API and worker code that depend on the schema landing.
Wave 3: UI and tests that depend on the API contracts.

Vague splits like "do auth" and "do frontend" fail because both touch the same route registry and session types. Prefer "you own src/api/billing/**" and "you own src/web/billing/**."

Subagents that return a summary to a parent are cheaper than full teammate sessions. Use full teammates when you need long independent sessions with their own tools and mailboxes. Use subagents for research, review, or short side quests.

Gartner (March 2026, cited in industry writeups) estimates agentic models can burn 5–30× more tokens per task than a standard chatbot. CORAL-style multi-agent research harnesses show four-agent runs often land around 3–4× the API cost of a matched wall-clock single agent. Parallelism multiplies waste when scope is loose. Default to two or three implementers, not eight, unless the work is truly independent and you have an integration plan.

Merge conflict prevention is planning, not luck

Worktrees stop silent runtime clobbering. They do not stop two agents from rewriting the same logical feature and colliding at PR time. Hotspots: lockfiles, route registries, shared types, migrations, generated clients.

Practitioner consensus is boring and correct:

Map file ownership before you spawn anyone.
Single-writer rule for schemas, lockfiles, and shared types.
Prefer additive prompts: new files, routes, and exports instead of editing the same hub files.
Merge early. Rebase remaining branches onto updated main.
Pre-flight with git merge-tree (or similar) between in-flight branches before long runs finish.
Treat each agent output as a PR: test, then integrate one at a time.

The marketing story is eight agents. The real bottleneck moves from typing to review and integration. Budget human (or dedicated integrator) time as first-class work.

Prompt patterns that make concurrent agent execution reliable

Teammates and subagents do not inherit your full chat history. They get project instructions (CLAUDE.md, rules files) plus whatever you put in the spawn prompt. Incomplete spawns produce confident wrong work.

The Prompt:

You are Agent B on feature branch `hippy/billing-api` in an isolated git worktree.

## Ownership (hard rules)
- You own ONLY: `src/api/billing/**` and `tests/api/billing/**`
- You MUST NOT edit: `src/types/**`, `package-lock.json`, `pnpm-lock.yaml`, `src/routes/index.ts`, `migrations/**`
- If you need a shared type or route registration, stop coding that part. Write a short `NEEDS.md` in your worktree with the exact change another agent (or I) must make. Do not invent types in hub files.

## Task
Implement POST /billing/invoices (create draft invoice) and GET /billing/invoices/:id.
Depend on existing auth middleware patterns in `src/api/_shared/auth.ts` (read-only).
Schema for Invoice already landed on main (branch is rebased). Do not change the schema.

## Done definition
- Handlers + tests green for the two endpoints
- No edits outside ownership paths
- Open a short PR description in `PR.md`: summary, test commands, residual risks

## Out of scope
UI, webhooks, payment provider wiring, migrations.

Why This Works: The prompt encodes single-writer ownership, additive boundaries, and a forced escape hatch (NEEDS.md) instead of letting the agent "helpfully" edit shared hubs. Done definition and out-of-scope cut the usual expansion that causes merge fights.

Expected Output:

Agent B implements handlers under src/api/billing/, adds tests, leaves lockfiles and types alone, and produces PR.md plus a NEEDS.md noting that src/routes/index.ts still needs a one-line registration from the integrator. No silent edits outside the owned tree.

For ambiguous bugs, use competing hypotheses instead of one agent that commits early:

The Prompt:

You are one of five investigator agents. You do NOT coordinate with the others until final reports.

Bug: intermittent 500 on checkout when cart has a promo code. Repro is flaky.

Your assigned hypothesis to try to CONFIRM, then actively try to DISPROVE:
[H3] Race between promo validation and inventory reservation under concurrent checkouts.

Rules:
- Work only in your worktree. No pushes to main.
- Prefer failing tests and logs over speculative refactors.
- Final report must include: evidence for, evidence against, confidence 0-100, smallest next experiment.
- Do not "fix" production code unless a single-line guard is proven by a new regression test.

Why This Works: Forced disconfirmation reduces premature consensus. Isolation keeps five theories from overwriting one another. You pick the strongest report, not the loudest agent.

Expected Output:

Five short reports with conflicting confidences. One hypothesis dies on a missing race window in logs. Another survives with a deterministic stress test. You integrate that path only.

Other durable patterns:

Role + lens on the same PR surface: security review vs performance vs tests, with disjoint write scopes (or review-only).
Plan approval required before write when using agent teams.
Frontmatter or spawn flags for worktree isolation when your tool supports it (isolation: worktree style).
Spawn with full task context every time. Assume amnesia.

Cost, disk, and when not to parallelize

Eight unconstrained agents can torch a monthly budget and fill a disk. Policy fixes this without abandoning the technique:

Cap concurrent worktrees (practical ops ceiling often sits near 8–10 before management overhead dominates).
Prefer subagents for cheap fan-out; full teammates for independent long work.
Name worktrees and branches with project and owner prefixes so cleanup is scriptable.
Never share one local DB across agents writing migrations.
For MSP and client repos, decide cloud Background Agents vs privacy mode before you start, not after a PR opens on a remote VM.

Do not parallelize trivial work. One good agent with a tight prompt beats three agents fighting over a single file.

Put it together

Reliable concurrent agent execution looks like junior contractors on a board: private desks (worktrees), a shared ticket system with dependencies (task graph), and a hard "don't touch each other's folders" rule (prompts + single-writer). You bill merge and review as real work.

Cursor made "eight agents" easy to click. Claude Code made background tasks and experimental teams share a task list. The orchestration patterns that matter are still ownership maps, wave scheduling, and additive prompts. Use the product ceilings when the work is independent. Use two or three agents when you want speed without chaos.

If your team wants live practice on agent orchestration patterns (spawn prompts, ownership maps, worktree hygiene, and integration discipline), connect with Kief Studio on Discord or schedule a session.

background agents

Background Agents and Parallel Execution: Run Eight Tasks at Once Without Conflicts