I have lately been experimenting with an agentic workflow where one agent coordinates a large coding task, while short-lived worktree agents implement isolated phases in their own branches.
#The orchestration layer
It uses workmux's primitives as the control plane for spinning off work into multiple worktrees, and consult-llm to have other models review the plan, suggest approaches, and check the final diff.
As workmux builds on tmux, each worktree agent runs its own window, so the fan-out stays visible. The major benefit of this compared to say, a single Claude agent orchestrating multiple worktrees behind the scenes, is that the work is observable. You can tab into any worktree, see what the agent is doing, read its output, and intervene if it goes off track.
The coordinator agent idea in itself is not very new, but the way this workflow combines it with external review is in my opinion very powerful. consult-llm is used to challenge the plan before implementation, shape the phase breakdown, and verify the result after the agents have done the work. For a long-running agent task, that outside input acts as a guardrail. It doesn't prove the result is correct, but it gives the workflow a few chances to course-correct and prevent a mistake from compounding.
#Why split the work?
One key problem solved by orchestration is context management. A single agent would eventually accumulate too much history, but a coordinator only needs to keep track of the plan, phase state, review decisions, and merge results. That fits comfortably even in a 200K context window, while each worktree agent, where the actual code changes happen, starts fresh with a focused prompt.
Another benefit is parallelism. The coordinator agent can start independent phases at the same time, while the DAG keeps phases with dependencies in the right order. That lets work proceed concurrently without turning the main working tree into a shared mutable mess.
#Where it fits
Because the goal is to leave agents working alone for extended periods, it's important for the overall task to be well-specified and have minimal ambiguity, so that LLMs don't need to make assumptions about business logic or invent requirements.
As such, a great use case I've noticed for this is refactoring. With refactoring work, the success criteria are clear and you are not adding new behavior. Critically, with multiple LLMs proposing approaches, the results tend to be more robust because the approach has been refined from multiple perspectives.
A well-refined plan for a new feature can work too, but only if the behavior, boundaries, and acceptance criteria are already clear enough that the agents are mostly executing rather than deciding what should be built.
#The phased workflow
At a high level, the /phased-implement workflow looks like this:
- The coordinator creates a master plan with a DAGDirected Acyclic Graph: a dependency graph where later phases can depend on earlier phases, but cycles are not allowed. .
- The coordinator can use consult-llm to help produce that plan, challenge the phase breakdown, and later review the result.
- The coordinator starts every phase whose dependencies are satisfied.
- Each phase runs in its own worktree with a narrow prompt.
- Inside that worktree, the agent runs
/implementto plan, review, implement, validate, and commit its scoped change. - Completed phases merge back into the integration branch.
- Dependent phases start only after their prerequisites have merged.
- Failed phases block only the parts of the graph that depend on them.
The workflow is not meant for every change. For a small task, it's comically overkill. It starts to make sense when the work is large enough that a single agent would accumulate too much context, but structured enough that the task can be split into clear phases.
The full workflow lives in the consult-llm repo as the phased-implement skill, which coordinates the per-worktree /implement and /merge steps.