Running Multiple AI Coding Agents in Parallel: What Becomes Hard

Multiple sessions multiply the things you have to track. The agent is not the bottleneck; your attention is.

The hard part of running multiple AI coding agents in parallel is not picking them. It is what happens after the second chat starts. Isolation, context, attention, and intervention become first-class problems, and the workflow that worked for one agent starts to buckle under three.

Why developers start running multiple coding agents

The reasons are concrete, not ideological:

• Parallelize independent work. A refactor, a test suite, and a docs sweep that don't share files can run in parallel.
• Reduce idle time. While one agent waits on a long compile, another can be writing tests.
• Different tasks in different sessions. A bug fix and a feature on different branches should not share an agent's context window.
• Different agents for different workflows. Claude Code for one task, Codex for another, an OpenCode build for a third — each tuned to a job.
• Review one task while another continues. Move from "watch the agent" to "read the diff".

Running two agents is rarely the goal. Running three or four, on independent tasks, in different repositories, across a working day — that is what the search intent behind "multiple AI coding agents" and "parallel coding agents" is pointing at.

The first problem is isolation, not agent intelligence

Every parallel failure traces back to the same root: two agents sharing a workspace. The principle is non-negotiable:

one task → one workspace → one branch → one session

When the principle breaks, the symptoms stack up fast:

The fix is not a better prompt. The fix is one filesystem, one branch, one agent. Git worktrees make this mechanical: each agent runs in its own worktree, on its own branch, off the same main. See /gtw fix one-shot fixes for the worktree workflow that drops a branch per agent and pushes it as its own PR when it is done.

The second problem is context

Isolation solves the filesystem. It does not solve your head. Once you have three sessions in flight, the questions that matter move to a different layer:

• Which agent is doing what?
• Which project or worktree does this session belong to?
• Why is this session waiting — on me, on a tool, or on a test?
• What changed in this branch since I last looked?
• Which of these tasks is safe to merge right now?

Without an answer to each of those, you spend the time you saved by parallelising on remembering which chat is which. The "scrolling through three terminals" workflow is the predictable failure mode here.

The status card pattern — one line per session carrying agent name, CWD, git state, and token count — is the smallest fix. It does not need a dashboard. It needs a glance-able line you can read in two seconds. The mechanics of reading those cards live in Run agents in parallel; the principle is what matters here.

The third problem is attention

This is the part that does not show up in any tool comparison.

More agents
   ↓
More parallel work
   ↓
More sessions to observe
   ↓
Human attention becomes the scarce resource

A typing bottleneck can be parallelised. An attention bottleneck cannot. Every additional agent does not just consume compute — it consumes a slice of your context window for "what is this session doing right now". Three sessions in flight is comfortable. Six is a part-time job. The curve is not linear because every new session adds both its own tracking cost and an interaction term with the others.

The implication is uncomfortable: scaling parallel agents past a small number does not speed you up, it slows you down. The optimum is usually two to four in-flight tasks, each on a different worktree, each on a different branch, each with a clear "done" condition you can recognise in under a minute.

What happens when one agent needs you?

Parallel agents do not remove the human-agent loop; they multiply it. Each running session is a queue of possible interruptions:

• A permission prompt that needs a yes or no.
• A clarifying question the agent cannot answer alone.
• A clarification on which approach to take.
• A failed command with a stack trace the agent cannot diagnose.
• A test failure that needs your judgement, not the agent's.
• A task completion that needs your sign-off before it merges.

Each of these is a context switch. Six sessions, each asking once an hour, is six context switches an hour. The same interruption loop that you used to handle by walking back to the laptop does not get cheaper when the laptop is closed — it gets more expensive, because the interruption now competes with whatever else you were doing. The intervention surface — what the agent is allowed to ask, and how you answer it — is the second-deepest problem in the parallel-agents workflow.

Manage Multiple / Parallel Coding Agents — internal page planned; link will be added when published. When Your Coding Agent Needs You — internal page planned; link will be added when published.

Safe patterns for running agents in parallel

The patterns that survive contact with three or more in-flight agents are not exotic. They are mechanical.

Git worktrees

One worktree per agent. Each worktree is a separate directory, a separate branch, a separate checkout. git worktree add ../repo-fix-x -b fix/x main is the smallest unit of isolation. The agent in that worktree cannot see the files in another worktree because the files are not there. The branch in that worktree cannot collide with the branch in another worktree because they share no working tree. The full loop — branch, run agent, push, PR — lives in /gtw fix one-shot fixes.

Independent tasks

Tasks that touch disjoint files can run in parallel. Tasks that touch the same files should run in series. The first half of "should I parallelise this?" is "do the file sets overlap?". If they overlap, the merge cost will exceed the parallel speed-up.

Clear task boundaries

A task with a fuzzy "done" condition forces you to babysit it to know when to stop. A task with a concrete "done" — "add a failing test that fails on the current bug, then make it pass" — finishes itself. Parallel agents multiply the cost of fuzzy task definitions by the number of in-flight sessions.

Reviewable diffs

The output of a parallel agent is a diff. The smaller and more focused the diff, the cheaper the review. "Refactor the parser" produces a diff you have to read. "Add a single helper that handles CRLF in config files" produces a diff you can skim. Pre-define the shape of the diff before the agent starts.

One agent per task

Sharing an agent across tasks sounds efficient. In practice it is a context-window tax and a memory tax: each task pollutes the other's context, and "which agent is doing what" loses meaning. A fresh agent on a fresh worktree is faster, even at the cost of a warm-up.

Mixed agents: Claude Code, Codex, OpenCode and others

Different agents can run side by side. Claude Code for one chat, Codex for another, an OpenCode build for a third — the underlying CLI does not change the principles above. Isolation, context, attention, intervention: all of these live at the session layer, not at the agent layer.

What does change is ergonomics. Different agents have different permission models, different tool-call surfaces, different response lengths, different ways of asking for clarification. The session-management pattern stays the same; the agent-specific knobs you have to learn multiply by N. Plan for that.

This is also why vendor-agnostic session tooling has value. When the underlying agent changes, the workflow you built around it should not. The control layer should let you switch agents without rebuilding your status surfaces, your interruption handling, or your merge queue.

Monitoring without staring at terminals

What you actually need from a "dashboard" is small:

• Know what is running, on which worktree, with which agent.
• Know what needs your attention, and why.
• Intervene only when needed — yes / no / redirect / stop.
• Return to the right context when you come back.

The terminal-scrolling workflow fails the second requirement: it tells you nothing about what is waiting on you. The "open five browser tabs" workflow fails the fourth: when you come back to the loop, you do not know which tab is which.

The right shape is one control surface per in-flight agent, with a glance-able status line and an interrupt mechanism that does not require opening a new tab. The implementation can be a chat app, a vendor control surface, a browser tab, or a phone notification — the requirement is the same: low-latency status, low-friction intervention, low cost to return.

Where NightMe fits

NightMe is a chat-based control layer for local coding agents. It does not auto-orchestrate agents, and it does not replace your judgement about which task to run next.

What it does:

• One conversation per session. One chat, one CWD, one agent, one branch. The four-axis mental model is the whole architecture.
• Multiple agent sessions, one control layer. Three chats, three Claude Code processes, three worktrees, one /chat list. Switching is a message, not a tab.
• Human-controlled stop / steer / continue. /stop cancels in-flight work, /steer <msg> queues a redirect, the next message continues. The human is the loop.
• Proactive status reporting. The status card on the last message of each chat tells you what the agent is doing, where it is, and what is left to do.
• Worktree workflow where it helps. /gtw fix -n <branch> opens a fresh worktree off main, hands it to a one-shot agent, lets you /gtw close --push --pr when the diff is good.

NightMe does not decide which agents to run, in what order, or how many. That decision is yours, and the value of the parallel-agents workflow depends on it staying yours.

When parallel agents are actually worth it

Worth it:

• Independent bug fixes. Two distinct crashes on disjoint files, two worktrees, two PRs.
• Tests plus implementation. One agent writes the failing test, another writes the implementation, both on the same branch (sequenced, not parallel — but on the same worktree).
• Docs plus implementation. A feature PR plus a docs PR for the same feature, on different worktrees.
• Multiple PRs in flight. The everyday case for any maintainer with a backlog.
• Exploratory alternatives. Two agents taking different approaches to the same problem on different branches; pick the diff you prefer, drop the other.

Not worth it:

• Same files, same task. Two agents editing the same lines in the same branch. Guaranteed merge hell.
• Tightly coupled sequential work. If step B's input is step A's output, serialise them. The context tax of sharing state across sessions exceeds the parallel speed-up.
• Tasks requiring shared mutable state. A database migration that another agent is reading, a config file another agent is rewriting — every shared mutable object is a race condition waiting to fire.

The rule of thumb: parallel agents are an answer to throughput on independent tasks. They are not a substitute for clear task definitions, and they cannot rescue a workflow whose steps are not actually parallel.

The bottleneck moves from typing to attention

Once agents can work in parallel, the scarce resource is no longer keystrokes. It is developer attention. The trade-off stops being "how fast can I type?" and becomes "how much of my working memory can I give to keeping three sessions in flight?". The honest answer for most developers is two or three, on a good day, with clear boundaries.

The category-level framing of this — what it means to live with always-on coding agents, how to keep them useful without letting them consume the day — lives in Coding agents without babysitting. The remote-control surface (phone, browser, chat) that lets you step away from the desk and still meet your attention budget lives in How to run AI coding agents from your phone.

What's next

• Run agents in parallel — the NightMe-specific patterns: one chat per project, four-axis mental model, /share, token budgets.
• /gtw fix one-shot fixes — the worktree loop that turns a chat into a one-shot PR, the safe unit of parallel agents.
• Coding agents without babysitting — the category framing behind NightMe's design.

Remote / Continue Coding Agents — internal page planned; link will be added when published.