I went HAM on git worktrees when I learned they were a thing.

For a while, they felt like the obvious answer to multi-agent coding. One agent per worktree. One isolated checkout per task. No branch stepping on another branch. Clean separation everywhere.

Then I slowly drifted back to single-branch flows.

Worktrees are still useful.^[1] But in my day-to-day agent workflow, they created a different kind of tax:

• More duplicated setup.
• More context drift between checkouts.
• More repeated work when two agents solved nearby problems.
• More time spent reconciling branches after the work was "done."

I did not need more git ops.

I needed better coordination.

TLDR; here is the flow

Plan
  -> Ask for non-obvious questions
  -> Resolve ambiguity
  -> Build directed task graph
  -> Assign unblocked work
      -> Agent A reserves files
      -> Agent B reserves files
      -> Agent C reserves files
  -> Agents coordinate through mail
  -> Verification pass
  -> Summary and QA plan

flowchart TD
  Plan[1. Start with the general idea and craft a solid plan] --> Clarify[2. Surface hidden questions]
  Clarify --> Graph[3. Generate directed task graph from plan]
  Graph --> Swarm{4. Swarm or /goal knocks out the unblocked work}
  Swarm --> A[Agent A]
  Swarm --> B[Agent B]
  Swarm --> C[Agent C]
  A --> Review[5. Verification pass]
  B --> Review
  C --> Review
  Review --> Summary[6. Summary and QA plan]
  Reservations[(File reservations)] -. prevent collisions .-> Swarm
  Mail[(Agent mail)] -. coordinate blockers .-> Swarm

1. Start with the general idea and craft a solid plan

The failure mode everyone is worried about is real:

How do you make sure multiple agents do not collide?

That is the question that actually matters. Branch shape is secondary.

If five agents all wake up, scan the repo, and start editing whatever looks useful, you are going to have a bad time. Worktrees can hide the collision for a while, but they do not remove it. They defer it until merge time.

The better answer is boring and old:

Plan the work.

Measure twice, cut once has never been more true than it is with AI coding agents. The faster the workers get, the more expensive a vague plan becomes.

Before I let agents touch code, I want a concrete plan that says:

• What are we changing?
• What are we explicitly not changing?
• Which files or modules are likely involved?
• What order should the work happen in?
• What are the risky edge cases?
• What should be verified at the end?

Then I do one more pass that sounds almost too simple:

Do you feel 100% confident to generate this, or do you have questions to ask me?

Read the <Files> and interview me in detail using the AskUserQuestionTool about literally anything:
technical implementation, UI & UX, concerns, tradeoffs, etc. but make sure the questions are not obvious

be very in-depth and continue interviewing me continually until it's complete, then write the spec to the file

That prompt is valuable because it makes the model stop performing confidence and start looking for ambiguity.

Do this before implementation. The point is to find the places where the plan can still break.

Once those questions are answered, the plan gets sharper. The agents now have constraints, acceptance criteria, and a shared understanding of the job.

2. Surface hidden questions

The first plan usually looks good until the model is forced to ask what it still does not know.

This is where you find missing constraints, unclear ownership boundaries, UX edge cases, and weird deployment assumptions before they become expensive edits.

3. Generate directed task graph from plan

Now turn the plan into a directed graph of tasks.

A flat checklist is not enough. Use a graph.

I like Beads for this because it treats tasks as a local-first dependency graph instead of a vague todo list. Beads Viewer makes the graph easier to inspect when the work fans out.

Some tasks can run in parallel. Some tasks must wait for another task to finish. Some tasks should never run at the same time because they touch the same files or depend on the same decision.

A good task graph says:

• Task B depends on Task A.
• Task C and Task D can run independently.
• Task E needs the output from both C and D.
• Task F is verification and should happen after implementation.

The graph becomes the source of truth.

The agents are not freelancing. They are picking up unblocked nodes from a shared work graph.

4. Swarm or /goal knocks out the unblocked work

Once the graph is clear, I feed it into a swarm of tmux sessions running whatever coding harness I want for that job.

Use Codex, Claude Code, Gemini, Aider, your own scripts, or whatever else works for you. The harness matters less than the coordination layer around it.

For tmux orchestration, ntm is the kind of thing I mean: a top-level tool that can spawn panes, keep track of sessions, and let a coordinator agent nudge the swarm instead of manually babysitting every terminal.

At the top sits a coordinator agent. I usually think of this as the ring leader.

The ring leader is not writing all the code. Its job is to keep the swarm moving:

• Read the task graph.
• Find unblocked tasks.
• Assign work to idle agent sessions.
• Check whether agents are stuck.
• Nudge them toward the next task.
• Keep duplicate work from happening.
• Collect final summaries and verification notes.

It just sits there on a loop, checking in every few minutes.

Something like:

Every 5 minutes:
  1. Check task graph status.
  2. Find unblocked tasks.
  3. Check active agent sessions.
  4. Assign idle agents to available work.
  5. Ask stuck agents for blockers.
  6. Update the graph.
  7. Repeat until all tasks are done.

Nothing mystical here. It is a practical production line.

4a. Prevent collisions with reservations

File reservations make this work on a single branch.

Before an agent edits files, it reserves them.

MCP Agent Mail gives agents a shared coordination layer for this kind of workflow: file reservations, inboxes, and explicit messages instead of vibes and git status archaeology.

A reservation looks like this:

agent: agent-3
task: mobile-search-layout
files:
  - src/fragments/Search/SearchPanel.jsx
  - src/fragments/Search/Search.module.css
reason: Mobile search layout fixes
expires: When the task is complete or explicitly released

Now another agent can see that those files are in use and avoid starting a conflicting edit.

People often try to outsource this problem to worktrees. Worktrees separate the edits, but they do not answer the more important question:

Should two agents be editing this area at the same time?

File reservations make the answer explicit.

4b. Give agents a mailbox

Reservations prevent obvious collisions. Agent mail prevents silent confusion.

Agents need a way to say:

• "I am blocked because Task 4 depends on your CSS change."
• "I found the helper you need in this file."
• "I am releasing these files."
• "This task is bigger than expected and should be split."
• "I changed the API shape, downstream task needs to know."

This does not need to be fancy. It only needs to be durable enough that the ring leader and the other sessions can read it.

The key is that communication is explicit. Agents should not infer coordination from git status alone.

To: agent-4
Subject: Search panel API changed

I added `onClose` to SearchPanel and wired it through SearchModal.

You can build on that for the mobile close-button task, but avoid editing
SearchPanel until I release the reservation.

5. Verification pass

Once agents say they are done, the next agent or human should verify the work against the original plan, not against whatever the implementation happened to become.

That means checking:

• Did the task graph complete?
• Did agents release their reservations?
• Did the final diff match the plan?
• Did tests, typechecks, builds, screenshots, or manual QA cover the risky parts?
• Did any agent leave an unresolved blocker in mail?

6. Summary and QA plan

When the swarm finishes, "is it done?" is not enough.

I ask for:

Summarize the work completed.

Include:
- Files changed.
- Decisions made.
- Tests or checks run.
- Known risks.
- Anything that still needs human QA.
- A recommended QA plan.

Multi-agent work can move extremely fast, so the final summary matters. You need a clean handoff back to human review or another verification agent.

The output should make it obvious what changed and how to inspect it.

The Ralph loop, turned way up

This feels like the "Ralph loop" pushed way past the original version.^[2]

One agent loops on a problem, checks its work, and keeps improving. That is already useful.

But a coordinated swarm with a task graph, file reservations, and a ring leader can chew through work that would have taken weeks a year ago. I have had sessions where a pile of implementation, polish, and verification work gets compressed into a couple of hours.

The leverage comes from structured parallelism, not sheer agent count.

Worktrees ain't all bad

Worktrees still have a place.

If I am testing two radically different implementations, reviewing a risky branch, or doing long-running isolated experiments, they are useful.

But for most multi-agent product work, I prefer a single branch with:

• A strong plan.
• A directed task graph.
• File reservations.
• Agent-to-agent messages.
• A coordinator loop.
• A final QA pass.

This flow is easier to manage. It produces less repeated work and keeps the whole team of agents operating against one current view of the codebase.

The tradeoff is that you need discipline up front.

You cannot just yell "go build the thing" into five terminals and expect elegance to fall out.

The part that clicked

The thing that clicked: opening more terminals is not a system.

The system needs an operating model: Beads for the task graph, Beads Viewer when the graph needs inspection, MCP Agent Mail for reservations and coordination, and ntm for the tmux swarm.

You give the agents a graph, a way to claim files, a mailbox, and a coordinator that keeps checking for unblocked work.

That separates parallel motion from parallel chaos.

Where I found the pattern

This sounded too hard to manage until I saw what Jeffrey Emanuel was doing through one of John Lindquist's AI workshops.

Then Jeffrey released his skills: https://jeffreys-skills.md

That was when the pieces snapped together.

Worktrees are still a great git feature. But for multi-agent coding, the bigger win has been moving coordination out of branches and into the workflow itself.

That is the leverage.

Source thread: https://x.com/DavidWells/status/2062729167784087914^[3]

Notes