AI Kanban Workflow: A Practical Fix for Context Bloat in Agentic Coding

AI-assisted coding has a context problem, and an AI Kanban workflow may be one of the most practical ways to solve it. Rather than asking one long-running chat to remember every decision, file change, test result, and unresolved question, the workflow moves operational memory into structured work items that humans and agents can both read.

That is the central idea behind a recent r/SaaS post from developer u/Clean-Vermicelli-700. Their system uses a Kanban interface backed by Markdown files in the repository. A lightweight orchestrator reads the board and assigns work to specialist agents—a planner, an implementer, and an evaluator—while the task card becomes the persistent record of what happened, what remains unclear, and what must happen next. (reddit.com)

The post struck a nerve because it reframes a common frustration. Bigger context windows are useful, but they do not automatically create a reliable software-delivery process. If every plan, status update, false start, tool output, and implementation detail lives inside one chat session, the conversation becomes both expensive and difficult to audit. The better question is not simply, “How do we give an agent more context?” It is, “Which context should be durable, structured, retrievable, and reviewable outside the model?”

Why AI coding chats accumulate context bloat

A coding chat has an awkward dual role. It is supposed to be an interface for making decisions, but it often becomes the project database as well. Developers paste requirements, clarify edge cases, provide screenshots, discuss architecture, inspect errors, request edits, and then try to recover that history weeks later when a regression appears.

That model breaks down especially quickly when agents are doing multi-step work. The agent needs enough repository knowledge to act safely, but the user also needs a concise record of its assumptions. A raw chat log does neither job particularly well. It contains useful details, but those details are mixed with abandoned thoughts, repeated instructions, tool noise, and conversational filler.

Context bloat is not merely a token-cost problem. It creates four operational problems:

• Attention dilution: Important acceptance criteria get buried under implementation chatter.
• State ambiguity: A developer cannot easily tell whether the work is planned, blocked, tested, or ready to merge.
• Poor handoffs: A new agent—or a human returning the next day—must reconstruct the state from a transcript.
• Weak accountability: It is hard to identify which assumption led to a change, which test failed, or where a decision was approved.

Long context can also encourage a subtle failure mode: agents infer that prior discussion is still authoritative even after the codebase, task scope, or product decision has changed. A durable task record does not remove the need for context, but it narrows the active context to the material needed for the current decision.

The AI Kanban workflow proposed on Reddit

The Reddit workflow is straightforward in concept: store task state outside the chat, let agents write their findings back into that state, and keep the orchestrator relatively stateless. In the original example, the board is a collection of Markdown files in the repo that is rendered as a draggable Kanban board. (reddit.com)

That implementation choice matters. A Markdown-based board travels with the code, can be versioned in Git, works offline, and is not dependent on a third-party project-management database. It also gives an agent a simple file surface to read and update. The Kanban UI is helpful for humans, but the underlying task files are the real interface contract.

The author describes three broad agent responsibilities:

1. Planner: Turns a rough request into a concrete implementation plan, identifies relevant parts of the codebase, and raises questions that require human judgment.
2. Implementer: Executes an approved task, makes changes on a branch, runs relevant checks, and records outcomes.
3. Evaluator: Reviews the result, validates acceptance criteria, and can assess whether documentation or related references should be updated.

This resembles modern agent frameworks more than it may first appear. OpenAI’s Agents SDK documentation explicitly treats specialist ownership, handoffs, approval flows, tracing, and resumable work as first-class workflow concerns rather than assuming one model should own every step. (developers.openai.com)

The difference is that the Reddit setup uses a board as the external state machine. The chat can launch work, but it is not asked to retain the entire history of every task. That separation is the real design insight.

A Kanban board is not memory—it is a state machine

Calling a Kanban board “agent memory” is useful shorthand, but it can be misleading. A board should not become an unstructured dumping ground where agents write every observation. Its more valuable function is to model the lifecycle of work.

The original workflow uses stages similar to New, To Refine, Waiting, Ready to Start, In Progress, Require Input, Test, Merge, and Done. Each column is paired with an explicit rule about what the agent may do next. (reddit.com)

That turns a visual project board into a controlled state machine:

The key rule is simple: a status must communicate both current condition and permitted next action. If a card’s column does not change what the agent is allowed to do, it is probably a decorative label rather than useful workflow control.

Why “Require Input” is the most important column

The community discussion around the post repeatedly focused on the “Require Input” stage. One commenter noted that many agent workflows skip this pause point and simply let the model guess, drift, or continue with an unvalidated assumption. (reddit.com)

That criticism is exactly right. A competent coding agent can decide many technical details, but it should not silently decide every product or business detail. Whether a CSV import should overwrite data, whether an account should be deleted after a failed payment, or whether analytics consent must be opt-in are not routine implementation choices. They are decisions with customer, legal, commercial, or security consequences.

A proper blocked state makes uncertainty visible. The agent should commit safe partial work, record the question in a specific format, list reasonable options, explain the consequence of each option, and stop. When a human responds, a fresh agent can resume from the branch and task record rather than relying on an aging conversation.

What should go inside an agent-readable task card

The difference between a useful AI Kanban workflow and a glorified to-do list is task-card quality. “Fix onboarding” is a poor input for an agent. It invites broad interpretation, excessive exploration, and an unclear definition of done.

A stronger task card works like a compact execution brief. It should contain enough evidence for an agent to act, while avoiding a massive pasted history that recreates context bloat in another format.

Recommended task-card template

# TASK-142: Add domain verification status to onboarding

## Goal
Show a domain-verification state after a customer adds a sending domain.

## Why it matters
Users need to know whether they can send production email before launching.

## Scope
- Add verification status to the onboarding screen.
- Poll existing verification endpoint every 15 seconds while pending.
- Stop polling after verified or failed.

## Non-goals
- Do not redesign domain management.
- Do not change DNS verification logic.

## Acceptance checks
- Pending, verified, and failed states render correctly.
- Polling stops when the page unmounts.
- Existing onboarding tests pass.
- Add a test for the failed state.

## Relevant files and references
- apps/web/src/onboarding/domain.tsx
- packages/api/src/domains/verify.ts
- docs/domain-verification.md

## Decisions / constraints
- Use existing status copy from docs.
- Do not expose raw provider errors to end users.

## Agent log
- Planner: [timestamp, findings, implementation plan]
- Implementer: [branch, commits, commands run, results]
- Evaluator: [checks performed, defects, approval/rejection]

## Open questions
- [Only populated when human input is required]

This structure solves several recurring problems. The goal prevents an agent from optimizing an irrelevant detail. Non-goals control scope creep. Acceptance checks give the evaluator something objective to verify. File references reduce discovery time. The agent log creates a lightweight audit trail without requiring the primary chat to carry all prior reasoning.

For transactional product work, acceptance checks should also cover operational concerns: error states, permission boundaries, analytics events, retries, rollback behavior, and documentation. A feature is not “done” merely because the happy-path UI renders.

Separate documentation from operational history

One commenter in the Reddit thread made an important distinction: the board is not necessarily the complete documentation system. The implementation agent can update actual docs, while an evaluator verifies whether a change requires related documentation updates. (reddit.com)

That is a healthy boundary. Task cards should preserve the decision trail for a work item. Product documentation should explain enduring behavior. Architecture records should capture significant technical decisions. Runbooks should explain operations. Trying to make one Kanban card serve all four purposes guarantees clutter.

How to run multiple AI agents without creating merge chaos

Parallelism is the feature that turns this from a personal productivity habit into a potentially high-throughput engineering system. It is also where careless setups fail. Multiple agents editing the same repository can create conflicting changes, port collisions, polluted dependency caches, database contention, and confusing test results.

The original poster said parallel runs are enabled through task leasing and isolated workspaces: each run takes a specific task, uses its own workspace and ports, hosts its own worktree, then closes the workspace after a merge. A paused workspace can sleep until input arrives, with a new agent resuming later. (reddit.com)

This is a sensible pattern because it treats an agent run as an isolated job rather than an invisible background conversation. Git worktrees are particularly useful here: GitHub documents them as separate working directories that can support work on different branches without stashing or abandoning incomplete changes in the current directory. (docs.github.com)

GitHub’s current Copilot app documentation similarly describes isolated agent sessions that can run simultaneously, each with its own branch and controllable session configuration. (docs.github.com)

Practical rules for safe parallelism

Do not start by launching ten agents at once. Start with one implementer and one evaluator, then add parallel capacity only after your task cards, tests, branch conventions, and cleanup process are reliable.

Use these guardrails:

• Lease one card per worker. A lease should include task ID, branch name, workspace path, start time, and expiration or heartbeat.
• Give each worker an isolated worktree. Never let concurrent agents modify the same checkout.
• Allocate unique runtime resources. Ports, local databases, queues, containers, and temporary directories need task-specific names or ranges.
• Classify tasks by collision risk. Two CSS changes may be safe in parallel; two migrations or auth-system edits are not.
• Require small, focused branches. Large multi-purpose changes are difficult for humans and agents to review.
• Make CI the final arbiter. A task may be marked ready for review, but merge should remain conditional on automated checks.
• Clean up aggressively. Remove finished worktrees, stop containers, revoke temporary credentials, and archive finished task files on a schedule.

Parallelism should be based on dependency topology, not enthusiasm. If two tasks share a central interface, migration, or high-churn file, serializing them may be faster than resolving a complicated merge later.

Markdown board, GitHub Issues, Jira, or a custom app?

The Reddit post uses local Markdown task files, but the commenters raised a reasonable counterpoint: why build custom infrastructure when Jira or GitHub Issues already provide familiar Kanban workflows and agent integrations? (reddit.com)

There is no universal winner. The right system depends on where your team’s source of truth already lives and how much control you need over agent execution.

Option 1: Markdown files in the repository

This is ideal for solo builders, small product teams, open-source projects, and code-centric workflows. Tasks can be reviewed in pull requests, remain available offline, and evolve alongside the code.

The downside is that you must build or adopt the renderer, task parser, locking, archive process, and any reporting you need. You also need conventions that prevent task files from becoming noisy merge-conflict magnets.

Option 2: GitHub Issues and Projects

GitHub-native workflows reduce tool switching for teams already using pull requests, Actions, Issues, and Projects. It can be a strong default when every task should point to a PR, CI run, release, or discussion.

GitHub Actions is designed to automate and customize workflows directly in repositories, making it a natural place to run validation, status updates, or follow-up automation around agent-generated pull requests. (docs.github.com)

The trade-off is that GitHub Issues are not a local-first artifact. Agents need authenticated API access, and the detailed operational log may be scattered across issues, PR comments, commits, workflow output, and external traces.

Option 3: Jira with MCP

For larger teams, the “just use Jira” reaction is not frivolous. Atlassian’s Rovo MCP Server can provide AI clients with secure, permission-aware access to Jira, Confluence, Bitbucket, and other Atlassian Cloud data. It can search, summarize, create, and update work items through supported AI clients. (support.atlassian.com)

That makes Jira a practical external state layer if the company already runs planning, approvals, and reporting there. But an MCP connector is not a workflow design. You still need explicit status semantics, permissions, approval boundaries, and a policy for what agents may update automatically. The official server also respects existing user permissions, which is helpful for governance but means access design remains your responsibility. (developer.atlassian.com)

Option 4: A custom orchestrator and board

A custom system gives you the most precise control over task leasing, workspace creation, model routing, queue behavior, cost controls, and structured logs. It is attractive when AI execution itself is part of the product or when your engineering process has unusual constraints.

It is also the most expensive option to maintain. Before building it, prove that a conventional board plus a disciplined task schema cannot meet your needs. In many cases, the durable insight is the workflow, not the interface.

The human approval layer is a feature, not a bottleneck

The temptation in agentic development is to eliminate humans from the loop. In practice, the highest-leverage approach is to place humans at the decisions where their judgment is uniquely valuable.

A good AI Kanban workflow should ask for approval at moments such as:

1. Before implementation: Approve the plan, scope, data model changes, and known trade-offs.
2. At genuine ambiguity: Decide product behavior, security posture, UX copy, rollout policy, or compatibility strategy.
3. Before merge or release: Confirm tests, visual behavior, operational impacts, and rollback readiness.

This does not mean a person must review every line of routine code. It means the system should distinguish between reversible implementation detail and consequential decisions. A planner can choose a sensible helper-function name. It should not decide to expose customer data in a new API response because it seems convenient.

OpenAI’s current agent documentation includes resumable approval flows and human review as explicit workflow capabilities, reinforcing the broader principle that reliable automation often needs deliberate pause points rather than uninterrupted autonomy. (developers.openai.com)

The board helps because it makes those pauses visible to everyone. “Waiting” is not failed automation. It is controlled escalation.

Evaluation must be more than asking another model if the code looks good

The evaluator role in the original workflow is promising, but it needs rigor. An evaluator agent that simply reads a diff and says “looks good” adds little value. The evaluator should operate against concrete evidence.

A robust evaluation pass can include:

• Comparing the implementation against acceptance checks.
• Running unit, integration, type, lint, and build checks.
• Inspecting the diff for unrelated changes.
• Confirming migrations, configuration changes, and feature flags.
• Verifying documentation or changelog updates where applicable.
• Checking test coverage for previously untested behavior.
• Identifying risks that require human review rather than trying to resolve them silently.

Agent observability should support this process. OpenAI’s documentation recommends using traces to inspect agent workflows and trace grading to test whether the right tools, handoffs, and policies were used. (developers.openai.com)

The board and the trace serve different purposes. The board answers, “What is the state of this work and what should happen next?” The trace answers, “What did the system actually do while carrying it out?” Teams need both once their automation becomes consequential.

Build a definition of done that agents cannot game

Avoid acceptance criteria such as “works correctly” or “improves performance.” They leave too much room for a model to declare success based on superficial evidence.

Instead, use observable outcomes:

• “A user with no verified domain sees the pending state within one second of page load.”
• “The API returns HTTP 403 when a workspace member attempts an owner-only action.”
• “The import rejects files larger than 10 MB with the documented error code.”
• “The retry job stops after three failures and emits an alerting event.”

The more observable the criterion, the easier it is for a human, test suite, or evaluator agent to validate it.

Where this workflow can fail

Moving memory out of chat is useful, but it does not make agents reliable by default. It can even create a false sense of control if teams mistake a tidy board for genuine engineering discipline.

The most common failure modes are predictable:

The board becomes a second chat transcript

If every agent dumps long reasoning chains, raw command output, and repeated repository summaries into task cards, the board inherits the exact clutter it was meant to remove. Store decisions, evidence, links, concise findings, and next actions—not every thought.

Statuses are vague or easy to skip

A column named “Review” means different things to different people. Is code review required? Has CI passed? Is design review complete? Can the agent keep changing the branch? Write transition rules and enforce them in tooling where possible.

Agents have too much authority

An agent that can move cards, edit production configuration, merge code, and deploy without policy controls may turn a workflow convenience into an incident generator. Separate permissions for planning, implementation, merge, and production operations.

The tasks are too large

AI agents can appear productive on broad tasks while quietly making architectural choices that should have been reviewed. Smaller tasks reduce context requirements, make failures easier to isolate, and create cleaner evaluation boundaries.

Done cards accumulate forever

The thread also surfaced a mundane but real issue: completed cards eventually bloat the board. The original poster described a housekeeping script that archives older completed tasks, while another commenter reported needing to archive a large Done column regularly. (reddit.com)

Archive completed work based on policy—for example, after 30 or 60 days—while preserving searchable history in Git, your issue tracker, or a documentation store.

A lightweight implementation plan for founders and small teams

You do not need a multi-agent platform to test the idea. A small team can implement the core process in an afternoon and improve it gradually.

Week-one setup

1. Create a tasks/ directory in the repository or a dedicated project board.
2. Define six to nine statuses with one-sentence transition rules.
3. Create a task-card template with goal, scope, non-goals, acceptance checks, references, log, and open questions.
4. Start with a single planner prompt and a single implementer prompt.
5. Require implementation on a dedicated branch or worktree.
6. Add a human checkpoint before merge.
7. Record what failed: unclear tasks, repeated questions, broken tests, merge conflicts, and excessive token use.

The goal is not to automate every movement immediately. In the early version, a human can move cards manually while agents only read and update the task file. That still captures most of the benefit: persistent state, visible blocks, and focused context.

What to automate next

Once the manual process works, automate the boring and deterministic pieces:

• Create branches and worktrees when a task enters In Progress.
• Attach task IDs to branch names and commits.
• Post CI results back to the card.
• Prevent status changes when required fields are missing.
• Archive old Done tasks.
• Alert a human when a task remains in Require Input or In Progress beyond a time threshold.

Do not automate judgment before you automate housekeeping. The latter is lower risk and tends to produce clearer operational gains.

The bigger lesson: externalize state, not just prompts

The most useful takeaway from this Reddit discussion is not “everyone needs a custom Kanban app.” It is that agentic coding needs an external operating system for work.

Chats are excellent for exploration, explanation, and immediate steering. They are weak as the permanent home of project state. Boards, issue trackers, task files, branches, CI results, documentation, and traces each hold a different kind of durable context. The trick is to give every artifact a clear job.

An AI Kanban workflow creates a practical division of labor:

• The chat is for directing work and resolving immediate questions.
• The task card is for state, scope, decisions, and acceptance criteria.
• The branch and worktree are for isolated implementation.
• The test suite and CI are for repeatable evidence.
• The evaluator and reviewer are for validation and escalation.
• The documentation is for enduring product and engineering knowledge.

That architecture reduces the pressure on any one model session to remember everything. It also creates a process that survives a closed laptop, a model switch, a failed run, or a new teammate taking over the task.

For teams building quickly with AI, that durability may be more valuable than another marginal increase in context-window size.

FAQ

What is an AI Kanban workflow?

An AI Kanban workflow uses a Kanban board or structured task system as the persistent state layer for AI-assisted work. Agents read task requirements, update plans and outcomes, move work through defined statuses, and pause when human judgment is required.

Does an AI Kanban workflow eliminate the need for long context windows?

No. Agents still need relevant code, task details, and recent decisions. The workflow reduces unnecessary conversational history by storing durable state in task cards, Git branches, tests, and documentation instead of one expanding chat thread.

Can I use Jira instead of a Markdown-based board?

Yes. Jira can be a strong choice for teams already managing work there, especially because Atlassian’s Rovo MCP Server can connect supported AI clients to Jira and related Atlassian Cloud data with existing permission controls. (support.atlassian.com)

Should AI agents be allowed to merge code automatically?

Only for low-risk changes with strong automated tests, explicit policy controls, and a rollback path. For high-impact changes involving security, billing, data migrations, permissions, or customer-facing behavior, require human approval before merge or release.

What is the single most important status to add?

Add a visible “Require Input” or “Waiting for Decision” status. It prevents agents from guessing when they encounter a real product, architecture, security, or business ambiguity—and preserves the exact question for a human to answer.