Agents Kanban: A Jira Board for AI Agents

In October 2025, I built Agents Kanban at the Tech: Europe Munich Hackathon. The idea was simple: keep the familiar kanban workflow, but you can assign AI agents to complete the work.

The motivation for this project, were the frequents requests I receive from PMs and non-technical people at work. I often copy and paste the exact request into an agent, and get the expected result. With Agents Kanban, PMs would be able to do this through the usual kanban interface they love, with no need to set up GitHub SSH, cloning repos, learning git, etc.

You connect a GitHub repository, create a ticket with a description, and move the card across the board.

  • In planning, an agent writes an implementation plan.
  • In progress, it works in the repo, runs checks, and opens a pull request.
  • Engineers can then review the PR through the usual GitHub interface.
Agents Kanban board showing tickets in different stages with AI agent status badges

from ticket to pull request

Because of the short hackathon deadline, the flow was intentionally small:

  1. Create a project with a repo URL.
  2. Create a ticket with a description of the feature.
  3. Move it to planning to generate a plan with affected files, likely changes, and test strategy.
  4. Review the plan before letting the agent touch code.
  5. Move it to in progress so the agent clones the repo, makes the changes, runs checks, commits, and opens a PR.

The ticket then links back to the pull request, so the human review step stays exactly where developers already expect it.

stack choices

We optimized for speed with the usual stack:

  • Next.js + React for the interface and board interactions
  • Convex for real-time tickets, status changes, and agent updates
  • OpenCode AI for the planning and implementation workflow inside real repositories
  • GitHub for the final output and review process

Convex did most of the heavy lifting on the collaboration side. Every mutation showed up on the board immediately, which made the agent activity legible instead of feeling like a background job with a spinner.

The OpenCode SDK handled the part that would have taken too long to build from scratch during a weekend: repo access, code edits, terminal steps, and pull-request creation. That let us focus on the workflow around the agent rather than on LLM orchestration.

what made it work

Three product decisions carried the project:

Planning before implementation The extra step slowed the happy path slightly, but it made the system much easier to trust. A short, reviewable plan is much easier to evaluate than a surprise pull request.

Real-time visibility Showing ticket state, agent state, and PR links live on the board made the system understandable for everyone watching it. That was especially important in a hackathon setting where people were seeing the product for the first time.

Using GitHub as the handoff We did not invent a new review interface. The agent produced ordinary pull requests, and developers reviewed them in the same place they already review human-written code.

why I still like the idea

Agents Kanban was built in a weekend, so it was obviously incomplete. But the main workflow held up: a ticket can be the entry point for real implementation if the system has three things around it:

  • a clear plan
  • access to the codebase and checks
  • a human review step at the end

That combination felt practical. It turned the project from "AI can code" into a tool that fit a normal development process.