# MoAI-ADK: a verification harness for Claude Code, and what Kanban Mode changes

> MoAI-ADK wraps Claude Code in a SPEC-driven plan, run and sync chain with TRUST 5 quality gates and per-column model routing. The interesting part is not the feature list but the four-terminal Kanban Mode that splits one unit of work across separate context windows.

**modu-ai/moai-adk** — Agentic development harness for Claude Code — SPEC-driven plan/run/sync, TRUST 5 quality gates, model+effort routing, and Claude×GLM multi-LLM cost control. Single Go binary, 16 languages, zero deps.

- Repository: https://github.com/modu-ai/moai-adk
- Website: https://adk.mo.ai.kr
- Stars: 1,227 · Forks: 226
- Language: Go
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/modu-ai-moai-adk

## The problem MoAI-ADK names, and who it is aimed at

The README opens with a claim about the model rather than about the tool: a model "cannot remember, turn to turn, what it used this turn and how much, whether the result is good, or how far the last session got." MoAI-ADK's answer is to enforce those three things from outside the model, in a harness. That framing tells you who the project is for. If you use Claude Code for single-file edits or exploratory questions, nothing here applies. The target user is someone running long, multi-phase work through Claude Code, where a SPEC document grows large enough that the plan, the implementation and the review all end up competing for one context window.

The project calls itself a verification-driven agent orchestration harness. The pieces it advertises are SPEC-driven plan/run/sync, TRUST 5 quality gates, model and effort routing, and Claude plus GLM multi-LLM cost control. It ships as a single Go binary, and the README claims 16 languages and zero dependencies. The Apache-2.0 licence and the presence of README files in Korean, Japanese and Chinese suggest the maintainers expect a non-English audience as well.

## How the harness is put together

The repository layout is a Go project of the conventional shape: cmd/ holds the moai entry point, internal/ and pkg/ hold the implementation, and .moai/ holds runtime state. The Makefile builds with a templ-generate step first, then go build -o bin/moai ./cmd/moai, stamping the version, commit and date through ldflags into pkg/version. The dependency list in go.mod shows what the binary actually carries: Cobra for the command tree, the Charm stack (bubbletea, lipgloss, huh, glamour, fang) for the terminal interface, mcp-go for MCP integration, go-tree-sitter for parsing, and fsnotify for file watching. That is a TUI-heavy dependency set for something described as a harness, and it is the reason the binary is not small.

The orchestration model is the part worth understanding. In Kanban Mode, a lead session drives a chain and three companion sessions each own one column, plan, run or sync. Each companion carries only that column's context. Review is not a column of its own; the README states the sync gate absorbs it and runs the review lenses itself to reach a verdict. The board has five columns, backlog through plan, run, sync, done, and backlog has no owning session by design, so cards enter through a command rather than appearing on their own. The lead advances a card only on evidence it read from that card's progress.md, not on a companion's reply, because a reply is a claim.

Factory Mode is the second form. Instead of a card hopping between columns, a card goes whole to one lane and that lane carries it through plan, run and sync serially in-session, each phase spawned as an Agent() subagent. Lanes are labelled lane-1 through lane-N. A lane runs up to 10 concurrent subagents, and write-capable spawns are isolated in their own worktree.

## Installing MoAI-ADK and running a first Kanban chain

The repository ships install.sh, install.ps1 and install.bat at the top level, so the platform-appropriate script is the documented entry point. The README itself does not print a curl-piped install line, so check the script contents before running it rather than assuming a flag or a target directory.

The first real use is Kanban Mode. One terminal takes the lead, which announces a run-id and seeds the chain:

```bash
moai cc -k
```

Then each companion is launched by hand, in its own terminal, one per role. The README is explicit that a session never spawns a peer, so these are three separate windows:

```bash
moai cc -k --name plan
moai cc -k --name run
moai cc -k --name sync
```

Companions are named by their bare role. The run-id belongs to the lead and never rides a companion name, and a second live session claiming the same role takes the next free number. Substituting moai glm for moai cc on any one of those lines puts just that column on the GLM backend, which is how the per-column routing is expressed at launch.

Work enters the board through a slash command rather than through a companion. The README gives these two forms:

```text
/moai todo "fix the stale rename hint"   # append a card
/moai todo                               # list the queue
```

A card you append lands in backlog and waits for the lead to move it. Factory Mode is a different launch. The lead takes a lane count, and lanes are brought up separately:

```bash
moai cc -f 4
moai cc -f lane-1
moai glm -f lane-3
```

One caveat the README states directly: never bring every lane up at once. Start the first, confirm it is actually producing output, then activate the rest.

## The default backend split, and where it breaks down

The bootstrap notice recommends a specific mix when a Kanban run opens: lead on moai glm -k, plan on moai cc -k --name plan, run on moai glm -k --name run, sync on moai cc -k --name sync. The reasoning given is about the kind of thinking each lane needs. Plan and sync involve judgment and review, so they sit on Claude. Run is implementation-heavy, so GLM keeps cost down. The lead is not the seat that renders verdicts, it watches the queue and moves cards, so a cheaper model suits a session that mostly waits.

The design has a sharp edge here. When a Claude verdict is needed under a GLM lead, the README says you escape through a session named judge, and describes that as the only route by which a GLM lead uses Claude. That is a real constraint on the routing model, not a footnote. It also means the recommended default is not a neutral starting point: it commits you to a specific division of labour, and deviating means understanding the judge escape hatch. The README does concede that a different combination, or unifying every session on one backend, is equally fine.

The other stated pressure is rate limits. When one account starts hitting 429 responses, the README's workable move is to spread lanes across accounts. Nothing in the README describes automatic backoff or account rotation, so this reads as a manual operational response.

## Where the harness gets in the way

The clearest limitation is stated by the project itself: nothing is uncapped. Each session still has its own context limit. Kanban Mode does not remove the ceiling, it stops any one session from carrying three phases of history so the same budget goes further. If your SPEC is large enough that a single column overflows on its own, splitting the phases does not help you.

The second limitation is operational. Companion sessions are launched by hand, one per terminal. There is no supervisor that starts them for you, and a session never spawns a peer. For a solo developer on a laptop this means four terminal windows and four backend configurations kept in sync with your own memory. Factory Mode adds a state file at .moai/state/factory/workers.json that records which lane numbers are held, and the README points there as the place to clear stale claims. That is a manual recovery path, and the README does not document what happens to a card whose companion dies mid-column.

Third, the launch rules are narrow. A number is skipped only while a live session holds it, and a dead lane's number is released and reused. Passing -k together with -f is an error because one launch takes one entry token, and moai cg refuses factory mode outright. Cards are never split across lanes. These are reasonable invariants, but they mean the tool does not degrade gracefully if you try to use it as a general-purpose parallel runner.

Finally, the front-end weight is worth naming. A Cobra plus full Charm TUI stack plus tree-sitter plus an MCP client is a lot of surface for a harness whose value proposition is discipline. You are adopting a fairly large Go program to enforce a workflow, not a thin script.

## MoAI-ADK against running Claude Code directly

The honest alternative is Claude Code on its own, with /clear as your context management strategy. That is what the README is arguing against. The difference in approach is where the structure lives. Running Claude Code directly, the workflow is whatever you type, and the context window is managed by clearing it and losing the thread. MoAI-ADK moves the workflow into a board with named columns, a progress.md per card that the lead reads as evidence, and quality gates that run at the sync stage. The cost of that move is the four-terminal setup and the backend routing rules described above.

The comparison is not really about capability. A careful engineer with a disciplined habit of writing a SPEC first and reviewing before merging gets much of the same outcome from plain Claude Code. What MoAI-ADK adds is that the discipline is enforced by a program rather than by the person, and that the enforcement is visible in files on disk. Whether that trade is worth four terminals depends on how often you have watched a long session drift and had no record of where it went.

## Maintenance, releases and licence

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent and versioned: v3.1.0 on 2026-08-15, v3.1.1 on 2026-08-20, v3.1.2 on 2026-08-21, with the README badge pointing at v3.1.3. That cadence matters for upgrade cost. Kanban Mode arrived in v3.1, and the README frames it as a change to how work is shaped, not a patch. Anyone who adopted an earlier workflow should expect to re-read the Kanban Mode documentation rather than assume the old session model still applies.

The Makefile exposes a release-local target that copies the built binary into $HOME/.moai/releases under a platform-qualified name, which suggests the project supports local development updates outside the normal release channel. That is useful if you want to track main, and a reason to pin a version if you do not.

The licence is Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices and state changes. It does not impose copyleft obligations on your own code. This is a description of the licence identifier in the repository, not legal advice; if you are redistributing the binary or embedding it in a product, read the LICENSE file and get your own counsel.

## Conclusion

Adopt MoAI-ADK if you already drive Claude Code on long, multi-phase work and keep losing the thread to context limits, and if you are willing to run three extra terminals by hand. Do not adopt it for short one-shot edits; the SPEC and gate machinery costs more than it returns there. Before committing, verify the install path for your platform in install.sh, install.ps1 or install.bat, read the Kanban Mode page at adk.mo.ai.kr/en/advanced/kanban-mode for the factory worker-state file, and check what happens to a card when a companion session dies mid-column, since the README does not document recovery.

## FAQ

### What does MoAI-ADK add on top of Claude Code?

It wraps Claude Code in a SPEC-driven plan, run and sync chain with TRUST 5 quality gates and model plus effort routing. The README describes it as a verification-driven agent orchestration harness that enforces from outside the model what a model cannot track turn to turn.

### How do I install MoAI-ADK?

The repository ships install.sh, install.ps1 and install.bat at the top level, so use the script for your platform. The README does not print a one-line install command, so read the script before running it.

### What is Kanban Mode in MoAI-ADK?

It splits one unit of work across four terminals instead of one. A lead session drives the chain while three companion sessions each own a single column, plan, run or sync, and carry only that column's context.

### Does MoAI-ADK remove the context window limit?

No. The README states that nothing is uncapped and each session still has its own limit. What changes is that no session carries three phases of history, so the same budget goes further.

### What licence does MoAI-ADK use?

The repository is Apache-2.0, which is permissive and includes an explicit patent grant. It does not place copyleft obligations on your own code, but read the LICENSE file if you plan to redistribute the binary.

## Sources

- [License: Apache-2.0](https://github.com/modu-ai/moai-adk/blob/main/LICENSE)
- [modu-ai/moai-adk on GitHub](https://github.com/modu-ai/moai-adk)
- [Project website](https://adk.mo.ai.kr)
- [README](https://github.com/modu-ai/moai-adk/blob/main/README.md)
- [Releases](https://github.com/modu-ai/moai-adk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/modu-ai-moai-adk
