Put bounded agent work on a reviewable path.
The Kanbus Issue Router turns an eligible, labeled issue into one controlled coding-agent run—then returns the result as a pull request and an In Review item. Your team stays in charge of what starts, what ships, and what gets merged.
The question
Can we let an agent do real work without turning the board into an opaque automation queue?
Yes. The Issue Router is an optional Kanbus reconciliation loop that starts only work your workflow has made eligible. It gives the agent a bounded package and an isolated Git worktree, validates a structured result, and opens or updates a GitHub pull request. A completed run goes to your configured review state; it does not close the issue or merge the PR.
Kanbus remains Git-native throughout. Issue data, event history, checkpoints, and router-owned status changes are durable and inspectable. The model is an executor inside a deterministic workflow—not the system that decides what work exists or whether it is accepted.
What changes for a team
A small routing label is the opt-in. Everything else stays familiar.
Mark the package
agent-class:… or agent-provider:… label to an issue. Its untagged descendants travel with it as one bounded package.Run with guardrails
Review ordinary Git work
How a run works
A deliberate sequence that preserves the project’s source of truth.
- 1
Plan
The router reads the configured pending state and produces a deterministic list of eligible and deferred packages.
- 2
Claim
It records a claim with a unique ID and revision, using the project’s configured coordination level.
- 3
Execute
The agent (Codex or OpenCode) works in a run-specific Git worktree and returns one structured result rather than directly changing Kanbus issue data.
- 4
Validate
Kanbus verifies package scope, workflow transitions, claim ownership, checkpoints, and result shape before accepting anything.
- 5
Publish
Accepted work updates the dedicated router-state Git branch, creates or updates the pull request, and moves the package to Review.
The safe default
One call processes at most one eligible package. Start by looking at the plan; then dispatch deliberately.
kanbus router plan
kanbus router run --once
For continuous operation, watch mode reconciles immediately and on the configured interval. It also polls GitHub pull-request state for work already in review.
kanbus router run --watch
Progressive coordination
Start simple. Add coordination only when the number of workers demands it.
One worker: Git
For a single worker, Git-backed state is enough. The router’s watch loop polls the shared router-state branch at its bounded interval.
No MQTT or mutex service is required to begin.
Faster visibility: MQTT + Git
MQTT can wake routers sooner when another worker publishes an update. Git remains the durable record and polling fallback.
This is soft coordination: duplicate starts remain possible during a visibility gap.
Hard exclusion: Mutex API
Put the Mutex API first when workers must not concurrently start the same package. A live lease is then required before an adapter starts.
If the mutex service is unavailable, the router fails closed instead of silently weakening coordination.
What the router will not do
Clear boundaries make automated work easier to trust and easier to operate.
It does not replace human review
It does not let an agent rewrite the board
It does not require a cloud queue
It does not hide failure
Questions teams ask
The operational answers, without hand-waving.
Can I choose which work is routed?
Can I cap agent activity?
What happens when a PR needs changes?
What happens if a worker dies?
Ready to operate it?
Configure one route, inspect the plan, and keep the normal pull-request review loop intact.
Read the operator guide for the configuration contract and the design document for exact routing, fencing, retry, and lifecycle semantics.