Two ways to run agents on one task

Plan-first orchestration vs parallel worktree sessions

There are two useful shapes for pointing coding agents at a piece of work. One fans out: several agents run at once, each in its own git worktree, and you watch the panes. The other plans first: the work becomes an ordered list of tasks you read and edit, and only then does anything run.

Both are legitimate. They fail in different places, and the difference matters most at the moment you stop watching. This page is the comparison I would want to read before picking, written by someone who builds one of the two.

Disclosure: I build Ordewell, the tool in the plan-first half of this page. It is free, Apache-2.0, with no paid tier, so my interest is that people pick the shape that fits rather than that they pick mine. Parallel session tools are described as a class, not as individual products, because I have not audited each one and will not put words in their mouths.

The two shapes

Parallel worktree sessions. You describe the work to N agents. Each gets its own branch or worktree so their edits cannot collide, usually in its own pane or window, and you supervise the set. Tools in this family tend to give you a board of sessions with statuses, diffs to review, and a way to send a steer into any pane mid-flight.

Plan-first orchestration. The work is turned into a plan before any of it executes. In Ordewell that plan is an ordered list of tasks, and each task names its runner (Claude Code, Codex, OpenCode), the model, the thinking effort, the mode, and its dependencies. You edit the plan as a whole, then execute it. The plan is a file on disk, not a message in a chat log.

Where the plan lives decides what you can correct

In a fan-out session, the decomposition lives in the prompt you typed and in each agent's context. That is fine while the work is independent and you are watching. The trouble arrives at step four, when you learn the agent misread step one. By then files exist. There is nothing to edit, only something to undo.

Plan-first moves that decomposition out of the context and into an artifact. A separate, read-only planner process does the research, then hands back the task list. It cannot write to your repo: the exploration envelope refuses mutating commands, so the planner's only output is the plan itself. Mutation starts when you approve it.

The practical difference is the cost of being wrong. A bad plan you can see and edit costs a minute. A bad plan that already executed costs an afternoon.

Fan-out has a version of this too. Many parallel-session tools let you review a diff before merging, and some stage a launch command for approval. That is real review of the result. Plan-first is review of the intent, which is cheaper because nothing has been written yet.

Who decides a task is done

This is the axis that separates the two shapes most sharply, and it is easy to miss when you are comparing screenshots.

In a fan-out setup, the completion signal is usually the session going quiet, an exit code, or the agent saying it finished. When a coordinator agent supervises workers, the coordinator reads their reports and decides. That is a model judging a model.

Agents are bad at grading themselves. They will announce success on a build that does not compile, in a confident paragraph. So in Ordewell a task gets its own unique marker, the prompt asks for that marker on the final line, and the verdict engine watches the runner's own output for it. Present means pass. Missing means fail, loudly, even when the session exited cleanly. These are the two messages a task card can carry:

verdict
Verified: completion marker detected in agent output. Task completed successfully.

Failed verification: agent exited cleanly but did not emit the completion marker.

The exit code is kept on the card as evidence. It never overturns the marker, in either direction. Nothing asks a model to rule on another model's work.

When fan-out is the right call

Parallel sessions win where the work is genuinely independent and you want options: three takes on the same refactor so you can pick the best, sweeping a large migration across many files at once, exploring an unfamiliar area of a codebase where the goal itself is still vague, or any task where watching and steering is the point.

Honest note: fan-out is also the shape the market currently rewards. More agents at once looks like more throughput, and on independent work it is.

When plan-first pays

The command

The loop, headless, is two commands. Nothing runs until the second one:

bash
ordewell plan --goal "Migrate the config loader from JSON to TOML"
# read the tasks, then reassign before running
ordewell task-runner 2 opencode
ordewell task-deps 3 1,2
ordewell run

Planning needs no API key: a coding agent you already pay for can be the planner, and it runs read-only. Install with npm install -g ordewell, or read the docs first.

Honest limits