Parallel Agents: When to Run Them and When to Stay Serial

Key takeaways

• Parallelize only tickets that pass all four rubric criteria: isolation, checkable acceptance criteria, small blast radius, and a diff reviewable in under 15 minutes.
• Give every agent its own git worktree and its own branch named after its Linear ticket; two agents on one branch is the main failure mode once file collision is solved.
• Review bandwidth is the real bottleneck: budget 10-20 minutes of review per agent-hour of output, so one reviewer saturates around three steady agents.
• Refactors touching shared files and tasks with fuzzy done-conditions should stay serial until they are split by module boundary or given written acceptance criteria.
• Start with two rubric-passing tickets in parallel this week and scale only if the diffs were worth reviewing.

Parallel agents pay off when your tasks are isolated, fully specified, and cheap to review; they cost you when work touches shared files, specs are vague, or every diff needs your full attention. This guide gives you a four-criterion rubric to score any Linear ticket before you queue it, plus worked examples of tasks that pass and fail.

When do parallel agents actually pay off?

Parallel agents beat one serial agent when your queue has more independent, well-specified tickets than one agent can chew through, and each task touches separate files or repos so agents don't collide. Cursor's background agents are built for exactly this: they run in remote environments so you can launch several at once and review the diffs as they land (Cursor docs). The math flips when tasks share files, need sequential context from each other, or produce more diff to review than you have attention for. Coordination overhead, not agent speed, is what usually eats the gains. Aerunit's Cursor background agents guide covers the setup side of this.

What makes a task safe to parallelize?

Before you hand a ticket to a parallel agent, it needs four properties. If a task fails any one of them, running it in parallel costs more than it saves, because you become the bottleneck again.

The four-criteria rubric

Criterion	Question to ask	Pass looks like	Fail looks like
Isolation	Can the agent work without touching files another agent needs?	Own module, own git worktree, no shared migrations	Two agents editing the same service
Acceptance criteria	Can you state "done" in checkable terms?	Tests pass, endpoint returns X	"Make the code better"
Blast radius	What breaks if the agent gets it wrong?	One feature, easy revert	Schema change touching every table
Review load	Can you review the diff in under 15 minutes?	Small, mechanical diff	900-line refactor across repos

Score each task honestly. Three passes and one marginal is workable; two or fewer means keep it serial. The rubric applies to your own tooling too, and we run Aerunit through it in the comparison section, including where it falls short.

Scoring a real backlog ticket

Take a Linear ticket like "add rate limiting to the export endpoint." Isolation: yes, one route handler plus a middleware file. Acceptance criteria: yes, requests over N per minute return 429. Blast radius: low, one endpoint. Review load: small diff. Four passes, hand it to a Cursor Cloud Agent and queue the next prompt while it runs (see Aerunit's background agents walkthrough for how background agents behave).

Now take "migrate auth to the new session model." Shared files, vague done-state, touches every route. That one stays serial, with you in the loop.

Which tasks should stay serial?

Refactors that touch shared files

Anything that rewrites shared modules, types, or interfaces belongs in a single lane. Two agents refactoring the same file produce merge conflicts that cost more to resolve than the parallelism saved. Even with git worktrees giving each agent an isolated checkout, the merge at the end is where the work piles up. Run these one at a time, or split by module boundary first.

Tasks with fuzzy done-conditions

"Improve the onboarding flow" fails the rubric. Without acceptance criteria, an agent's finished work is a guess, and you become the glue between every step, pasting follow-up prompts and re-explaining intent. Serial execution is cheaper here: one session, tight feedback loop, you steer. Parallelize only after the ticket has a reviewable diff and a definition of done you could check without asking the agent what it meant.

How do you isolate parallel agents from each other?

Git worktrees as the baseline

Give every agent its own checkout and its own branch. git worktree add ../feature-auth feature/auth creates a second working directory that shares the repo's history but has its own files, so two agents editing the same repo never touch each other's uncommitted state. This is the default isolation for running parallel agents, and Cursor Cloud Agents already run each task in its own container, so the main risk is not file collision but branch collision: two agents committing to the same branch or rebasing over each other. One branch per Linear ticket, named after the ticket, keeps the mapping obvious when you review the diff.

When worktrees are not enough

Worktrees isolate files, not intent. If two tasks touch the same module, the second agent will build on stale assumptions and the merge becomes yours to untangle. Split by blast radius instead: assign tasks so overlapping files live in one serial chain, or carve shared code into its own repo or package with a stable interface. If you cannot state which files a task owns, it is not ready to parallelize. Aerunit's cross-repo awareness exists for this reason; see the German-language overview of parallel coding agents.

How much review bandwidth does an agent fleet need?

Review as the real bottleneck

If agents cut coding time by half but you still review every diff serially, review becomes the new bottleneck, and it arrives faster than most teams expect. Budget it explicitly: one agent-hour of output typically costs 10-20 minutes of human review, so six parallel agents can outpace a single reviewer within an hour, and once you fall behind, the queue grows monotonically rather than draining. The failure is quiet at first, because each individual diff still looks reviewable, but the accumulated pile means you start rubber-stamping diffs you would have rejected on day one, which is how a bad merge reaches main. If you cannot review the diff carefully, do not queue the next prompt behind it. The rubric's review-load criterion exists for exactly this reason, and it applies to Aerunit's own workflow: batching PRs from parallel agents concentrates review into blocks, which helps, but a bad batch still costs you the same focused time.

Batching and gating strategies

Two levers keep review sustainable. First, batch: merge small, independent PRs in one sitting instead of context-switching per ticket. Second, gate: only promote work that meets written acceptance criteria, so agents that fail a check never reach your review queue. Orchestration tools like Conductor and Aerunit (see the Swedish-language guide to parallel coding agents) differ mainly in where that gate lives; the principle is the same either way.

What does coordination overhead look like in practice?

The glue work shows up in two places: keeping context clean across chained steps, and the manual routine around each session. Both cost you the same thing, the hours you thought the agents bought back.

Context degradation between chained steps

When one agent hands off to the next, errors compound. If the model misreads the file structure in step one, every queued prompt inherits that mistake, and by step four you are debugging a chain instead of reviewing a diff. Anthropic's docs on subagents and context management describe the problem directly: each subagent starts with a fresh context window, so anything it needs must be passed in explicitly (Anthropic docs). Scoping each step and writing its inputs down is the fix, and it is work you do per task.

The glue-work tax

The routine around the agent is often the slow part: pasting the next prompt, checking whether the branch is actually done, updating the Linear ticket. One developer running chained sessions described it plainly: "I was the glue between every step, I did it slightly differently each time, and when something went wrong I had no record of where" (dev.to).

Aerunit's honest take on itself: it removes the glue-work tax for Linear-plus-Cursor teams, but it does not solve context degradation for you. Badly scoped tickets still produce badly degraded chains.

A worked example: parallelizing one week of Linear tickets

Take a realistic week: five tickets. "Upgrade Postgres driver" fails the rubric immediately, because every other branch touches the same config and the blast radius is the whole app. "Fix pagination off-by-one" passes isolation and has clear acceptance criteria, so it goes in the queue. "Add OAuth login" has a small blast radius but vague acceptance criteria, so it stays serial until you write down what "done" means. "Refactor billing module" and "Migrate the design tokens" both touch shared files, so running them in parallel means two agents stepping on each other's diffs and you spending your afternoon untangling merge conflicts instead of reviewing output.

That long paragraph is the decision in miniature: two tickets parallelize cleanly, two need re-sequencing, one needs better acceptance criteria before any agent touches it. The review load matters as much as the task list. Three agents running at once means three diffs waiting when you come back, and if you queued the fourth prompt before reading the first diff, a small mistake in step one propagates through everything behind it. The honest version of this week ends with two agents busy and you reviewing, not six terminals and a pile of conflicts.

How do orchestration tools compare on this decision?

Most tools skip the suitability question entirely and assume you have already decided. Devin (Cognition) takes whole tickets end to end, so the rubric lives in how you scope the ticket (Devin). Conductor wraps Claude Code in a desktop app and leaves task selection to you. Factory and Agentastic sit at the platform layer, above the decision. Cursor Cloud Agents assume you will queue work yourself.

Where Aerunit fits, and where it does not

Aerunit assumes Linear issues and Cursor Cloud Agents, and it enforces the rubric at intake: isolation, acceptance criteria, and review load get checked before an agent starts. That helps if your plan already lives in Linear. It does not help if you use Jira, run Codex or Devin instead of Cursor, or want an autonomous agent that picks its own tickets. Aerunit schedules work you deemed safe; it does not decide what is safe.

What is the simplest way to start running parallel agents?

Pick two Linear tickets that pass the rubric: isolated, clear acceptance criteria, small blast radius. Run each in its own git worktree or Cursor Cloud Agent, review the diff yourself, merge, and note where you lost time. That baseline tells you whether coordination overhead is eating the gains before you buy anything.

If it works, the next step is a queue so agents stay busy instead of you polling terminals. Aerunit does this for Linear + Cursor Cloud Agents: it scopes tickets, keeps a shared credit pool for the team, and gives cross-repo awareness when agents touch more than one repo. Honest limitation: it presupposes both tools, so if you run Claude Code locally or plan outside Linear, a local-first workbench may fit better. Start with two agents this week; scale only if the diffs were worth reviewing.

FAQ

How many parallel agents can one developer realistically supervise?

Budget 10-20 minutes of review per agent-hour of output, so a single reviewer saturates around three agents working steadily. Six parallel agents can outpace you within an hour. The honest ceiling depends on diff size: small, mechanical changes let you batch three or four PRs in one sitting, while anything larger drops your review capacity fast.

Do parallel agents cost more in tokens than they save in time?

Usually not, if tasks pass the rubric, because re-running a failed isolated task is cheap and bounded. The real cost is coordination overhead, not tokens: re-explaining intent, re-queuing prompts, and untangling merge conflicts. A vague ticket burns tokens on guesswork across every chained step, so scoping quality matters more to your bill than parallelism itself.

Can I run parallel agents on the same branch?

No. Give each agent its own branch, named after its Linear ticket, and its own checkout via a git worktree or a container-based agent. Two agents committing to one branch or rebasing over each other is the main failure mode once file collision is solved. Merge each branch separately and review the diffs as they land.

How do I know when an agent's implementation is actually complete?

Only if you wrote checkable acceptance criteria before queuing: tests pass, an endpoint returns a specific response, or a specific behavior exists. If "done" needs the agent to explain what it meant, the task was too vague to hand off. Gate promotion to your review queue on those written criteria, not on the agent's own summary of its work.

Should I parallelize bug fixes or feature work?

Neither category decides it; the rubric does. A pagination off-by-one fix parallelizes cleanly because it is isolated with clear acceptance criteria. An OAuth login feature can too, if its blast radius is small and "done" is written down. A bug fix touching shared config stays serial. Score each ticket on isolation, criteria, blast radius, and review load.