Discussion

Introducing VS Code Agent Kanban: Task Management for the AI-Assisted Developer

h4ch1: There's also https://github.com/openai/symphony that's being developed following a similar Kanban pattern based agent manager (though yours is more sophisticated at the moment imo)Interesting to see the Kanban workflow being adapted to managing agents, makes sense; each item having the same UX as a Github Issue.

maurelius2: I can certainly see the appeal of distributing the context with vc. However, I have always imagined this to be integrated into an existing kanban workflow, similar to a Jira or gh issue board. Perhaps agent specific, perhaps not.Furthermore, an existing kanban (ticket) workflow will expect you to refine the context into something more ... concentrated, or at least something that we are used to seeing as developers working with tickets, at least more so than the chat history that seem to be favored.Have you put any thought into how this would integrate into such a process?

gbro3n: I did - GitHub and Trello (and I expect Jira) have APIs that could be used to hook up an MCP server. I liked the idea of conversing with the agent in the ticket, but I decided against that because I'd have to keep refreshing the issues, and it seemed a bit janky moving in and out of the IDE.I also considered a full harness that could stream / sync the responses, but as per my comment below, implementing a full harness meant loosing a lot of the IDE integration features that come with the hand off to GitHub Copilot.> I went down the route of implementing a full harness for a while like Vibe Kanban, but the issue was that it was unlikely (without significant effort) to be as good as Github Copilot chat, and it meant forfeiting all of the IDE integrations etc (like diff visualisation for the agents actions etc).Having worked with a flow similar to this for a while - the markdown files become quite valuable as a history of planning and decisions for features. I didn't want to loose that. I just needed some help with managing the plan files I was maintaining - which the kanban board tooling does. A few command shortcuts via @kanban help tooRegarding what goes into the files, the agent tends to be quite concise - you don't see the whole train of thought that some of the harnesses surface.

gbro3n: Intro: https://www.appsoftware.com/blog/introducing-vs-code-agent-k...Youtube (Quick demo): https://www.youtube.com/watch?v=Y4a3FnFftKwGitHub: https://github.com/appsoftwareltd/vscode-agent-kanban

wek: This is interesting. We've seen markdown as the app. This is markdown as the database for your tasks.

ssgodderidge: Great to see more products in this space! Definitely going to try this out on desktop.I’m doing a fair amount of work on mobile, and prompting remote agents. I would love someone to build an OSS cross-platform kanban. It’d probably be complex to add triggers of workflows both locally and remotely though.

Zigurd: For a long time I've been an agile fundamentalist. I welcome agent assisted coding because it reduces team size and increases autonomy, experimentation, and generally makes self organizing teams a more obvious choice.Highly structured pseudo agile practices like scrum, never mind SAfE, make even less sense now than they did before. Flat collegial teams for the win.

gbro3n: I would say that a kanban board is not synonymous with scrum. In this workflow, the tasks are a way of organising task threads and recording the consideration, decisions and actions taken while working with an AI agent.

ebiester: I mean, this is a task board and not a Kanban board - Kanban implies things like Work In Progress limits, continuous improvement, and measuring flow to get rid of blockers.But you're right - you can visualize your workflow without using Kanban - I think it's weird how the term gets appropriated here.

guerython: the markdown-as-database framing is the right one. we ran into the same Jira friction for our agent fleet and ended up with a simple REST task board instead.the key insight: agents need a shared state store they can both read and mutate without human-mediated handoffs. markdown files work fine for single-agent. once you have multiple agents racing on tasks you want atomic PATCH semantics, not file locks.

gbro3n: Agreed. Also multiple humans. One task per person works great (no Git conflicts). I'll think about this more. I'm thinking that having the agent work through an MCP server might be a means of mitigating the issue. I'd rather keep the sync process in Git if I can.