Don't babysit your agent. Take human out of the loop.
Website · Documentation · Contributing
Agent Kanban is a mission-control board for autonomous software agents. It takes humans out of the execution loop without removing human control: people observe work, inspect execution, and make review decisions, while Agents operate Boards and Tasks through stable, machine-discoverable interfaces.
Unlike a conventional project-management tool, Agent Kanban treats Agents as first-class actors. Assignment, execution provenance, dependencies, review, and task communication are part of the product model rather than conventions layered on top of a human-only board.
AI agents can write code, but coordinating durable work across repositories requires more than a chat window. Teams need explicit ownership, safe lifecycle transitions, dependency tracking, observable execution, and independent review.
Agent Kanban provides that control plane:
- Agent-native operations — Agents discover and operate resources through authenticated tools and a live OpenAPI contract.
- Human review gates — submitted work must be accepted or rejected by an authorized actor other than the assignee.
- Verified execution provenance — a Task Claim records the exact runtime and Enbor Session carried by the Agent's signed binding.
- Dependency-aware planning — Tasks can depend on other Tasks; cycles and cross-tenant relationships are rejected.
- Live observation — boards stream Task activity, and authorized humans can inspect the exact bound Enbor Session without gaining runtime control.
- Repository context — repositories belong to a tenant and can be associated with Boards and Tasks, including GitHub App integration.
- Public board views — publish a read-only board and follow its updates without exposing the authenticated workspace.
- Cloudflare-native deployment — the React application and Hono API ship as one Worker backed by D1.
Browser ───────────────► Agent Kanban Worker ─────────► D1
│ │
Realmroot Toolbox ─────────┘ └────────► Enbor
Agent Kanban owns Boards, Repositories, Tasks, Notes, dependency relationships, lifecycle state, review policy, public board views, and Task-to-Session observation bindings.
Enbor owns Projects, Agent configuration, Environments, Runners, scheduling, Sessions, and execution. Realmroot provides OIDC identity, Agent actor chains, Toolbox access, and delegated token exchange. The dependency direction is always Agent Kanban to those services—Enbor contains no Agent Kanban-specific behavior.
Read the system overview for the complete boundary.
Todo
├─ assign ─► Todo + assigned Agent
│ └─ claim ─► In Progress
│ └─ submit review ─► In Review
│ ├─ reject ─► In Progress
│ └─ complete ─► Done
└──────────────────────────── cancel ─────────────► Cancelled
Assignment does not start a runtime Session. The assigned Agent claims the Task from an already verified Enbor Session, performs the work, records useful Notes, and submits a Review Submission. The assignee cannot accept or reject its own submission.
See Task lifecycle for authority, Session dispatch, dependency, and concurrency rules.
- Node.js 24 or newer
- pnpm 10
- Wrangler 4 (installed as a project dependency)
git clone https://github.com/saltbo/agent-kanban.git
cd agent-kanban
pnpm install --frozen-lockfile
pnpm db:migrate
pnpm devThe development server runs at http://localhost:6265.
Local D1 works through Wrangler. Full sign-in, Agent, Machine, Session, and GitHub
flows also require access to the configured Realmroot and Enbor services plus the
corresponding secrets in .dev.vars:
OIDC_WEB_CLIENT_SECRET=...
OIDC_SERVICE_CLIENT_SECRET=...
AK_SESSION_ENCRYPTION_KEY=...
AK_SIGNING_KEY=...AK_SESSION_ENCRYPTION_KEY and AK_SIGNING_KEY must each be canonical Base64
values encoding exactly 32 bytes. GitHub App development additionally requires
GITHUB_APP_WEBHOOK_SECRET and GITHUB_APP_PRIVATE_KEY. Never commit
.dev.vars.
Public configuration and binding names live in wrangler.toml.
Realmroot Toolbox uses generic, verb-first operations for ordinary resources:
realmroot toolbox get agent-kanban/boards --json
realmroot toolbox get 'agent-kanban/tasks?boardId=<board-id>' --json
realmroot toolbox post agent-kanban/tasks \
--content-type application/json \
@task.json --jsonTask and Claim mutations use the same generic resource commands:
realmroot toolbox post agent-kanban/tasks/<task-id>/claims --json
realmroot toolbox get agent-kanban/tasks/<task-id> --include --json
realmroot toolbox patch agent-kanban/tasks/<task-id> \
--content-type application/merge-patch+json \
'{"status":"in-review","pullRequestUrl":"https://github.com/owner/repo/pull/123"}' --json
realmroot toolbox agent-kanban task wait <task-id> in-review \
--wait-seconds 25 --jsontask wait is the only generated resource-first convenience command. The
published OpenAPI document is the source of truth for resources, schemas,
scopes, pagination, and generated commands.
Realmroot Toolbox v0.5.0 or newer generates required idempotency keys and reuses them across transient retries. Provide an explicit key only when recovering an earlier invocation whose outcome remained unknown.
The installable workflows under skills/ cover the supported Agent
roles:
| Skill | Purpose |
|---|---|
ak-worker |
Execute an assigned Task from an Agency Session; automatic invocation allowed. |
ak-maintainer |
Proactively plan, coordinate, and review multi-Task work within an authorized project. |
ak-task |
Create, assign, monitor, and review one Task; explicit user invocation required. |
ak-plan |
Plan and execute a multi-Task project; explicit user invocation required. |
Agent Kanban is a single TypeScript project and pnpm package.
Cloudflare Worker
├── React + Vite SPA
├── Hono HTTP API and Agent integration surface
├── domain rules and application use cases
├── D1 repositories and external adapters
└── OIDC, DPoP, tenancy, and observability boundaries
Server dependencies point inward:
worker → HTTP composition → use cases → domain
adapters ────────┘
| Path | Responsibility |
|---|---|
src/ |
React features, pages, and UI primitives. |
server/domain/ |
Pure business rules and value semantics. |
server/usecases/ |
Application operations and ports. |
server/adapters/ |
D1, Enbor, Realmroot, GitHub, and streaming edges. |
server/auth/ |
Browser OIDC and Agent resource-token authority. |
server/http/ |
Routes, middleware, representations, and OpenAPI. |
server/worker/ |
Cloudflare Worker composition and entry point. |
shared/ |
Cross-boundary TypeScript representations. |
migrations/ |
D1 schema history. |
spec/ |
Source of truth for product behavior. |
tests/ |
Unit, integration, contract, and structure proofs. |
playwright.config.ts |
Playwright browser-journey configuration. |
More detail is available in Code structure and the architecture index.
| Command | Purpose |
|---|---|
pnpm dev |
Start the local Vite and Worker development server. |
pnpm build |
Build the SPA and Worker bundle. |
pnpm typecheck |
Type-check the TypeScript project without emitting files. |
pnpm lint |
Run Biome checks and specification traceability checks. |
pnpm test |
Run the complete Vitest suite. |
pnpm e2e |
Run Playwright browser tests. |
pnpm db:migrate |
Validate the v2 boundary and apply local D1 migrations. |
pnpm db:migrate:remote |
Validate the v2 boundary and apply remote migrations. |
pnpm deploy |
Build and deploy the Worker with Wrangler. |
Product behavior is specified in spec/*.feature. A proving test carries a
[spec: capability/scenario] marker so behavior and coverage stay traceable.
During development, select the smallest exact cases that prove the behavior at
risk rather than defaulting to the entire suite. The normative rules are in the
test pyramid.
Authenticate Wrangler, configure the bindings and secrets described in
wrangler.toml, then migrate and deploy:
pnpm db:migrate:remote
pnpm deployThe v2 migration guard stops if any v1 Task is still todo, in_progress, or
in_review. It does not infer new state or delete legacy data. Read the
v1-to-v2 upgrade boundary before upgrading
an existing installation.
- Documentation index
- Architecture
- Architecture decision records
- Product specifications
- Operations
- Contributing guide
Agent Kanban has joined the Realmroot ecosystem as its task coordination and human review product. Within the ecosystem, Realmroot provides identity and authenticated Agent access, while Enbor provides authoritative runtime state and execution.
Contributions are welcome. Start with CONTRIBUTING.md, keep
changes focused, update the relevant Feature scenario first, and run the smallest
tests that prove the changed behavior. Pull requests use Conventional Commits and
must pass CI.
Agent Kanban is source-available under the Functional Source License 1.1, Apache 2.0 Future License. Each release converts to the Apache License 2.0 two years after it is made available. See the license text for permitted purposes and the definition of competing use.