Agent Kanban: a mission-control board where agents hold the assignee seat
An agent-first task board, Take human out of the loop.
At a glance
- What is it?
- saltbo/agent-kanban is a Cloudflare-hosted task board built around agents as first-class actors, with human review gates and signed execution provenance. The interesting part is not the Kanban columns, it is the claim and review model that decides who is allowed to change a task's state.
- Who is it for?
- Adopt Agent Kanban if you already run agents through Realmroot and Enbor and want task ownership, dependency ordering and review state held outside a chat window. Skip it if you want a standalone board, since full sign-in, agent, machine and session flows need those external services plus the secrets in .dev.vars.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The coordination gap this board fills
A coding agent can finish a task and still leave you with no durable record of who owned it, what it depended on, or who approved the result. Agent Kanban positions itself against that gap. The README states the project is a mission-control board for autonomous software agents, and that 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 machine-discoverable interfaces. The intended audience is a team already running agents across repositories, not someone experimenting with a single chat session. The product model reflects that. Assignment, execution provenance, dependencies, review and task communication are described as part of the model rather than conventions layered on top of a human-only board. The word Kanban in the name is almost incidental. What the project actually sells is a state machine with an audit trail attached.
Claims, review gates and the assignee rule
The lifecycle diagram in the README is the clearest statement of the design. A task starts in Todo. Assigning it keeps it in Todo but attaches an agent. The agent then claims the task, which moves it to In Progress. From there it submits for review, landing in In Review, where a reject sends it back to In Progress and a complete sends it to Done. A cancel path runs from Todo to Cancelled. Two rules carry most of the weight. First, assignment does not start a runtime session. The assigned agent claims the task from an already verified Enbor session, does the work, records notes and submits a review submission. Second, the assignee cannot accept or reject its own submission, and the README describes review as requiring an authorized actor other than the assignee. That is the human-in-the-loop mechanism, and it is enforced at the review transition rather than at execution time. The board also records what the README calls verified execution provenance: a Task Claim records the exact runtime and Enbor Session carried by the agent's signed binding. Note the boundary this draws. Agent Kanban owns boards, repositories, tasks, notes, dependency relationships, lifecycle state, review policy, public board views and task-to-session observation bindings. It does not own execution. Enbor owns projects, agent configuration, environments, runners, scheduling, sessions and execution, and the README states the dependency direction is always Agent Kanban to those services, with Enbor containing no Agent Kanban-specific behavior.
Running it locally and the secrets you cannot skip
The README lists Node.js 24 or newer, pnpm 10 and Wrangler 4 as requirements, with Wrangler installed as a project dependency. The local sequence is short: clone the repository, run pnpm install --frozen-lockfile, then pnpm db:migrate, then pnpm dev. The development server listens on port 6265. Local D1 runs through Wrangler, so the database side works offline. Everything past the board itself does not. Full sign-in, agent, machine, session and GitHub flows require access to the configured Realmroot and Enbor services plus secrets placed in .dev.vars. The README names four: OIDC_WEB_CLIENT_SECRET, OIDC_SERVICE_CLIENT_SECRET, AK_SESSION_ENCRYPTION_KEY and AK_SIGNING_KEY. The last two must each be canonical Base64 values encoding exactly 32 bytes, which is a constraint worth reading twice before generating them. GitHub App development adds GITHUB_APP_WEBHOOK_SECRET and GITHUB_APP_PRIVATE_KEY. The README says never to commit .dev.vars, and public configuration and binding names live in wrangler.toml. On the agent side, operations go through Realmroot Toolbox with generic verb-first commands, for example realmroot toolbox get agent-kanban/boards --json, or a POST to agent-kanban/tasks with an @task.json body. The README notes that task wait is the only generated resource-first convenience command, and that the published OpenAPI document is the source of truth for resources, schemas, scopes, pagination and generated commands. Toolbox v0.5.0 or newer generates required idempotency keys and reuses them across transient retries; supply an explicit key only when recovering an earlier invocation whose outcome stayed unknown.
What you inherit when you deploy it
The deployment story is narrow by design. The React application and the Hono API ship as one Worker backed by D1, and the README labels this Cloudflare-native. That single-Worker shape keeps the operational surface small, but it also means the project is not portable to a different host without work the README does not describe. The external dependency chain is the sharper constraint. Realmroot provides OIDC identity, agent actor chains, Toolbox access and delegated token exchange. Enbor provides sessions and execution. Without both, a local checkout gives you a board you cannot sign into and agents you cannot bind to sessions. The README is explicit that this is a requirement rather than an optional integration. Two further details matter for planning. Dependencies between tasks are checked: the README says cycles and cross-tenant relationships are rejected, which is the kind of validation you want but also a rule that will surface in any script that creates tasks in bulk. Public board views let you publish a read-only board and follow its updates without exposing the authenticated workspace, which is a separate exposure decision from ordinary access control and should be treated as one.
The licence question the metadata leaves open
The repository metadata reports the licence as NOASSERTION, while the README badge shows FSL-1.1-ALv2. Those two signals do not agree, and the discrepancy is the first thing to resolve before any commercial use. FSL-1.1-ALv2 is the Functional Source License with an Apache 2.0 future licence, a source-available model that typically restricts competing use for a period before converting. I cannot confirm the conversion terms, the permitted-use scope or the exact grant from the supplied material, and this is not legal advice. Read the LICENSE file at the repository root and, if the project matters to your product, have counsel read it too. The practical consequence is that the usual assumption behind a permissive licence does not apply here by default. Treat the licence as an adoption gate rather than a footnote.
Where a different tool is the better fit
A conventional project-management tool such as a self-hosted issue tracker assumes the assignee is a person with an account and a session. Agent Kanban inverts that: the assignee is an agent with a signed binding to a runtime session, and the review transition is restricted so the assignee cannot approve its own work. If your team wants humans to open tickets, move cards and close them, the agent-native machinery here is overhead you will pay for and not use, and the Realmroot and Enbor requirement is a cost with no return. The inverse case is equally clear. If you want agents to work unattended across repositories and you need a record of which session produced which change plus a separate approver before a task closes, a human-only board forces you to encode all of that in conventions that nothing enforces. The dependency direction the README describes is also a design commitment worth weighing. Agent Kanban depends on Enbor and Realmroot, and Enbor contains no Agent Kanban-specific behavior. That keeps the execution layer clean and reusable, but it means you cannot adopt this board alone and grow into the rest later without a second integration.
Maintenance cost and version cadence
The recent release list shows v1.13.2, v1.13.3 and v1.13.4 within roughly a week in May 2026, and the last push to the default branch is dated 2026-09-06. That is a fast patch cadence on a 1.x line, which usually means small fixes shipping quickly rather than a stable surface. Plan for the upgrade cost that comes with it. The Worker and D1 setup means schema changes arrive through pnpm db:migrate, so a version bump is not only a dependency update. The secrets in .dev.vars are another fixed cost: AK_SESSION_ENCRYPTION_KEY and AK_SIGNING_KEY are constrained to canonical Base64 encoding exactly 32 bytes, so rotating them is a deliberate operation, not a casual one. The repository also carries a skills directory with installable workflows, which the truncated README mentions without describing in full; I cannot confirm what those workflows do from the material available, so treat them as something to inspect in the repository rather than something to rely on.
Editorial conclusion
Adopt Agent Kanban if you already run agents through Realmroot and Enbor and want task ownership, dependency ordering and review state held outside a chat window. Skip it if you want a standalone board, since full sign-in, agent, machine and session flows need those external services plus the secrets in .dev.vars. Before committing, verify your Realmroot Toolbox version is at least 0.5.0 so idempotency keys are generated automatically, and read the LICENSE file at the repository root, because the badge says FSL-1.1-ALv2 while the repository metadata reports NOASSERTION.
Community notes