winget install --id=phodal.Routa -e Routa is a multi-agent coordination platform built around a workspace-scoped Kanban model. It is designed for software delivery workflows where planning, implementation, review, traces, tools, and repo context need to stay visible and durable instead of being hidden inside a single chat thread.
Workspace-first multi-agent coordination platform for software delivery
Demo • Architecture • How It Works • Why Routa • Quick Start • Docs • 中文
Routa is a workspace-first multi-agent coordination platform for software delivery. It keeps goals, tasks, sessions, traces, evidence, and review state visible on a board instead of burying them inside a single chat thread.
Releases · Architecture · Feature Tree · Quick Start · Docs Site · Slack · Contributing
The current implementation is intentionally dual-backend, not two separate products.
src/apps/desktop/ backed by the Axum server in crates/routa-server/api-contract.yaml
The delivery gate is a stacked decision path, not a single reviewer persona.
You: "Build a user auth system with login, registration, and password reset"
↓
Workspace + Kanban Board
↓
Backlog Todo Dev Review Done
Backlog Refiner -> Todo Orchestrator -> Dev Crafter -> Review Guard -> Done Reporter
↘
Blocked Resolver
Routa treats the board as both the planning surface and the coordination bus. The important detail is that each lane is backed by a different specialist prompt, and each downstream lane is deliberately stricter than the previous one.
At a high level, two specialist layers work together:
| Lane | Specialist | What the prompt enforces | What gets written to the card | Typical handoff |
|---|---|---|---|---|
| Backlog | Backlog Refiner | Clarify scope, do not code, and do not move forward until the card contains exactly one canonical YAML story block | Canonical YAML story with problem statement, acceptance criteria, constraints, dependencies, out-of-scope items, and INVEST checks | Move to Todo only when the story parses and is independently executable |
| Todo | Todo Orchestrator | Re-validate Backlog output, reject malformed or vague cards, and turn a valid story into an execution-ready brief | Execution Plan, Key Files and Entry Points, Dependency Plan, Risk Notes | Move to Dev only when implementation can start within minutes |
| Dev | Dev Crafter | Re-check that the card is executable, implement only the scoped change, run verification, commit the work, and keep git clean | Dev Evidence with changed files, work summary, tests run, per-AC verification, caveats | Move to Review only after commit exists and the worktree is clean |
| Review | Review Guard | Independently verify every acceptance criterion, reject missing evidence, reject scope creep, reject dirty git state, reject broken lint or type checks | Review Findings with verdict, per-AC status, issues found, reviewer notes | Move to Done only with APPROVED verdict |
| Done | Done Reporter | Treat Done as terminal, do not advance further, and leave behind a concise completion record | Completion Summary with what shipped, key evidence, and completion date | Stay in Done |
| Blocked | Blocked Resolver | Classify the blocker, explain root cause, and route back only when there is a concrete next step | Blocker Analysis with blocker type, root cause, resolution, and routing decision | Return to Backlog, Todo, Dev, Review, or remain Blocked |
The same card becomes stricter over time:
This is why the board is not just visual status. Each column changes what the next specialist is allowed to trust.
The built-in lane prompts live under resources/specialists/workflows/kanban/*.yaml, and the core role prompts live under resources/specialists/core/{routa,crafter,gate}.yaml.
Single-agent chat works for isolated tasks. It breaks down when the same thread has to do decomposition, implementation, review, evidence collection, and release decisions.
Routa makes those responsibilities explicit:
Choose the shortest path that matches how you want to use Routa.
| Surface | Best for | Start |
|---|---|---|
| Desktop | Full product experience, visual workflows, local-first usage | Download from GitHub Releases |
| CLI | Terminal-first workflows and scripting | npm install -g routa-cli |
| Web | Self-hosting or browser-first access | Run from source |
npm install -g routa-cli
routa --help
routa -p "Explain the architecture of this repository"
routa acp list
routa workspace list
npm install --legacy-peer-deps
npm run dev
Open http://localhost:3000.
npm install --legacy-peer-deps
npm run dev
npm install --legacy-peer-deps
npm --prefix apps/desktop install
npm run tauri:dev
docker compose up --build
docker compose --profile postgres up --build
The Tauri smoke path uses http://127.0.0.1:3210/ behind the desktop shell.
Use docs/fitness/README.md as the canonical validation rulebook.
cargo build -p entrix
entrix run --dry-run
entrix run --tier fast
entrix run --tier normal
npm run test
npm run test:e2e
npm run api:test
npm run lint
| Path | Purpose |
|---|---|
src/app/ | Next.js App Router pages and API routes |
src/client/ | Client components, hooks, view models, and UI protocol helpers |
src/core/ | TypeScript domain services for ACP/MCP, Kanban, workflows, traces, review, harness, and stores |
apps/desktop/ | Tauri shell and desktop packaging |
crates/routa-core/ | Shared Rust runtime foundation |
crates/routa-server/ | Axum backend used by desktop and local server mode |
crates/routa-cli/ | CLI entrypoints and ACP serving commands |
crates/harness-monitor/ | Run observation, evaluation, and operator-facing harness monitor |
docs/ARCHITECTURE.md | Canonical architecture boundaries and invariants |
docs/adr/ | Architecture decision records |
docs/product-specs/FEATURE_TREE.md | Generated route and endpoint inventory |
docs/fitness/ | Validation and quality gates |
MIT. See LICENSE.