Scale the Workflow with Planners, Isolated Implementers, Reviewers, and Mergers

A dependency-aware backlog can be executed by multiple agents in parallel. The scalable architecture is not a group of agents sharing one conversation. It is an orchestrated pipeline in which a planner selects unblocked issues, each implementer works in an isolated branch and sandbox, reviewers inspect the resulting commits, and a merger integrates accepted work.

The Kanban dependency graph provides the execution model. The planner reads the backlog and determines which issues can be worked on now. If one foundational issue blocks two independent issues, the first phase contains one task and the next phase contains two parallel tasks.

For each selected issue, the orchestrator creates an isolated working environment. A practical environment includes:

• A git branch or worktree dedicated to the issue.
• A sandboxed container for the agent process.
• The issue title, description, and dependency context.
• The repository state required to implement and test the change.

The implementer runs the bounded coding loop and produces commits. If commits were created, a separate reviewer inspects them. The reviewer can use a stronger model or a more demanding prompt because review is treated as a high-reasoning task.

After review, a merger agent receives the branches and issue metadata. It integrates the work and resolves failures exposed by types, tests, or merge conflicts. The merger is not merely concatenating patches. It is responsible for producing a combined state that passes the repository's feedback loops.

The full cycle is therefore:

1. Planner selects currently valid issues.
2. Orchestrator creates one isolated workspace per issue.
3. Implementers work in parallel.
4. Reviewers evaluate the commits in fresh contexts.
5. Merger integrates the accepted branches.
6. Tests and types validate the combined result.
7. Human QA and code review generate further issues when necessary.

This architecture preserves context isolation. Each agent receives the information required for its role rather than the full history of every other agent's work.

A sequential numbered plan can normally be executed by only one agent because each phase assumes the previous phase's context and completion. A dependency graph exposes concurrency. Parallel agents can reduce elapsed implementation time without forcing unrelated tasks into the same context.

Isolation also limits interference. Separate worktrees and containers prevent agents from editing the same working directory or inheriting accidental local state. Commits create explicit handoff points for review and merge.

Build parallel execution only after the sequential loop is reliable:

1. Confirm that one agent can select, implement, test, and commit one issue correctly.
2. Add dependency metadata to every issue.
3. Create a planner that returns a bounded set of unblocked issues.
4. Allocate one branch, worktree, and sandbox per issue.
5. Run an implementer in each environment.
6. Reject empty or failed runs before review.
7. Start a fresh reviewer for every resulting commit set and push the coding standards into

that review.

1. Merge branches through a dedicated integration step.
2. Run types and tests after integration, not only inside each isolated branch.
3. Return integration defects and QA findings to the backlog.

Do not parallelize human alignment merely because implementation can be parallelized. The early phases remain collaborative and arguable. The team may move back and forth among idea clarification, research, prototyping, and destination design until it knows where it is going.

Parallelism increases merge and review complexity. Two issues that appeared independent may touch the same code or make incompatible assumptions. Accurate dependency modeling and post-merge feedback loops are required.

Higher throughput can overwhelm human review. Parallel agents can produce code faster than a team can examine it. This creates an unresolved capacity problem: parallel agents can generate more review work even while they reduce implementation time.

The merger can repair mechanical integration failures, but it cannot decide whether the combined product has taste or satisfies an unstated expectation. Manual QA remains part of the system.

Scale by separating roles and state: a planner chooses unblocked work, isolated implementers create commits, fresh reviewers criticize them, and a merger validates the combined result. Parallel execution is safe only when dependency planning, feedback loops, and human validation remain intact.

The complete workflow is a controlled loop:

1. Start with a small persistent context and monitor token usage.
2. Explore the repository with isolated subagents when broad investigation is required.
3. Interview the humans until a shared design concept exists.
4. Summarize the destination in a product requirements document that includes module and

testing decisions.

1. Decompose the destination into vertical-slice issues with explicit blockers.
2. Validate one implementation iteration under human observation.
3. Run bounded AFK implementation sessions with TDD, tests, types, commits, and stop

conditions.

1. Review each result in a fresh context with coding standards pushed to the reviewer.
2. Perform human code review and manual QA, then turn findings into new issues.
3. Preserve deep module boundaries and refactor weak architecture so that feedback remains

meaningful.

1. Parallelize only independent issues in isolated worktrees and sandboxes.
2. Merge, rerun feedback loops, obtain team review, and continue until the destination is

satisfied.

The workflow succeeds by refusing two extremes. It does not require a human to type every line of implementation, and it does not permit an agent to convert a vague specification directly into unreviewed software. It uses agents for speed while retaining human control over meaning, structure, and quality.