How It Works

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.