Runs, and the tool behind them
A run is an agent working on its own — it survives a closed terminal, keeps its own log, and can be stopped. Here's how you drive one, and how each agent picks what it runs on.
Updated September 4, 2026
Everything in the daily loop is a card. The rest of what the board app's
buttons do can be asked for just as plainly, and your agent runs the matching command — the
runs panel and akb run are the same list either way.
| You say | What happens |
|---|---|
| "what's running?" | the runs going now, and what ran lately |
| "show me that run's log" | its log, or --follow to watch it go |
| "stop it" | the run ends and the card comes back |
| "that run died — carry on" | it resumes the agent's own session, counted as a fresh run |
| "use Codex instead" / "switch to Opus" | the board's agent, model, reasoning effort |
| "check my setup works" | one small message through the setup, so a bad login turns up here rather than on your next card |
| "save my API key" | it hands you the command to type yourself |
A key is the one thing your agent hands back instead of running: a key it types lands in its transcript and in your shell history, and the board never reads a saved key back.
When an ask can't run, the answer names the one line that fixes it — akb install for a project
with no board, npm install -g ai4kanban@latest for an akb that is behind, akb agent test for
an agent that isn't installed, akb agent for a key or provider that isn't set.
Which runtime each agent runs on
Every run belongs to one agent: a flow is run by the role that owns it — planner, builder, reviewer, or writer on a marketing board — and a spec run by the specialist it names. Each of them names a runtime, which is the whole answer to what that run runs as: the coding tool, the provider, the endpoint, the key, the model id, the reasoning level and any extra arguments. So the planner can think on a stronger model than the builder writes with, and two agents on the same tool can sit on two different gateways.
akb agent # every runtime, then every agent and the row it runs
akb agent runtime add "My gateway" claude-code
akb agent set --runtime my_gateway baseUrl https://my-gateway.example.com
akb agent bind builder my_gateway # give one agent a runtime of its own
The first row is Global default — what an agent naming no runtime runs. It is the default because it is first, not because anything marks it, and it can be neither renamed nor deleted.
A runtime's SHAPE travels with the repository, in docs/kanban/ui.config.json, so every checkout
runs each agent as the same thing. Its API key does not: it is one line per runtime in
docs/kanban/.env, which git does not carry. Clone the repo somewhere else and every runtime is
there, each waiting for its own key.
On screen, Configuration → Agents is where each agent picks its runtime, and
Configuration → Runtimes opens each coding tool onto how to reach it and a Test that says
whether it answers. Rows themselves are added, renamed and deleted with akb agent runtime.
Which tool to put behind an agent — what each of the eight reports back, what a run may touch, and the settings each takes — is What each coding agent can do.