PATTERN Cited by 1 source

Three-workspace parallel agent workflow¶

Intent¶

Run N parallel checkouts (three, in the canonical instance), each on its own branch, each with its own agent working. The human is a dispatcher — reading each agent's thinking, anticipating when it will return, and having the next task queued. The productivity metric is agents-busy ratio, not human keystrokes-per-minute.

Canonical articulation — Atlassian Fireworks, 2026-04-24:

"Three workspaces, each checked out on a different branch, each with an agent working. Split terminal: agent on one side, a shell on the other so I can poke at things while it works. Always have something running. If your agents are idle, you're leaving productivity on the table."

"Queue prompts. Read what it's doing and anticipate when it will return and what the next task will be." (Source: sources/2026-04-24-atlassian-rovo-dev-driven-development)

Shape¶

                  ┌──────────────┐
                  │    Human     │  ← dispatcher
                  │ (reading +   │
                  │  queueing)   │
                  └──────┬───────┘
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
   ┌────────────┐ ┌────────────┐ ┌────────────┐
   │ Workspace A│ │ Workspace B│ │ Workspace C│
   │ branch-A   │ │ branch-B   │ │ branch-C   │
   │ agent-A    │ │ agent-B    │ │ agent-C    │
   └────────────┘ └────────────┘ └────────────┘

   Split terminal per workspace:
   [agent conversation | shell for human to poke]

Why parallel workspaces, not parallel agents in one workspace¶

Three practical reasons:

Git state isolation. Each workspace has its own checkout, its own git HEAD, its own index. Agents can commit, branch, and experiment without colliding. A single workspace with multiple concurrent agents would fight over the index.
Branch independence. Each agent is on a different branch; the change sets don't interfere until they're explicitly merged. Each agent can assume its workspace state matches its branch.
Context independence. Each agent has its own conversation context, its own task, its own error stream. The human dispatches tasks based on which agent is done — not on which agent to ignore right now.

The human's role — dispatcher, not coder¶

Three skills the dispatcher exercises:

Reading thinking as it happens. "Read what it's doing and anticipate when it will return." Reading the agent's reasoning stream tells you when the agent is stuck, when it's about to be done, and whether it's heading in a wrong direction.
Queueing the next task. When an agent finishes, the next task should be ready — otherwise the agent sits idle. "If your agents are idle, you're leaving productivity on the table."
Poking with the side terminal. "Split terminal: agent on one side, a shell on the other so I can poke at things while it works." The human's shell is for investigating, validating, and occasionally correcting — but in the side-channel, not by replacing the agent's work.

Why three¶

Three is the instance; the principle is N > 1 where N is the human's context-switching capacity. Fireworks author works with three. At N = 1, the human serialises; at very large N, the human loses track of which agent is doing what. Three is a pragmatic middle ground for a single developer, constrained by how many streams of reasoning a person can keep straight.

Parallelism without context-switching cost¶

The pattern works only if context-switching between workspaces is cheap. Three enablers:

Split terminal / tmux discipline. Each workspace pinned to a predictable terminal pane; the human's eyes know where to look.
Queued task lists per agent. The human doesn't have to reconstruct "what was agent B working on" on every switch — the conversation itself is the task list.
Independent dev shards. Each agent gets its own dev shard (see patterns/dev-shard-iteration-loop) so validation doesn't collide across agents.

When it fits¶

Heavy agent-driven work. The pattern's whole point is keeping agents busy; if agent utilisation is low, the human dispatcher overhead isn't justified.
Independent tasks. If three tasks are deeply entangled (all modifying the same file, all requiring the same design decision), the parallelism doesn't help.
Single developer. The pattern is framed at the individual- workflow level, not the team-workflow level.

When it doesn't fit¶

Tightly-coupled PR sequence. If PR-B depends on PR-A's merge, there's no parallelism to exploit.
Agent latency >> task switching cost. If each agent takes hours to respond, the human can do something else entirely; parallel workspaces are unnecessary.
Small / focused scope. One task, one agent, one workspace — the pattern is over-engineered for a single small feature.

Relation to agent-spawn-parallel-exploration¶

patterns/agent-spawn-parallel-exploration is a related but distinct pattern: one human task dispatched to N parallel agents to explore different approaches, with results synthesised. The three-workspace pattern is N independent tasks each assigned to its own agent — no synthesis, no cross-agent communication. Both are parallel-agent patterns; they solve different problems.

Seen in¶

sources/2026-04-24-atlassian-rovo-dev-driven-development — canonical articulation; the author's daily workflow while building Fireworks.