Taming AI Context Bloat with Kanban: A Practical Guide to Parallel Agent Workflows

Why AI Context Bloat Has Become an Unavoidable Pain Point

As large language model coding assistants become deeply embedded in everyday development, an increasingly common frustration has surfaced: context bloat. As projects grow more complex and conversations get longer, AI assistants must cram ever more historical information, code snippets, and task states into their limited context windows. The result is often a sharp drop in efficiency, lost memory, and logical inconsistencies.

To understand the root of this problem, you need to understand the context window mechanism of large language models. The context window is the total text length—measured in tokens—that a model can "see" during a single inference. GPT-4, for example, expanded from an initial 8K tokens to 128K tokens, while the Claude 3 series supports 200K tokens. But increasing token counts doesn't fundamentally solve the problem. On one hand, the self-attention computation in Transformer architectures has O(n²) complexity. As context grows longer, models tend to exhibit a "middle forgetting" phenomenon—maintaining good attention to information at the beginning and end of the context but showing significantly reduced recall for middle sections. Researchers call this the "Lost in the Middle" effect. On the other hand, longer contexts mean higher API call costs and inference latency. So even as context windows keep expanding, sound context management strategies remain essential in engineering practice.

A Reddit developer shared their solution in Part 2 of their "Kanban governance approach": use a Kanban board to organize projects, persist memory, and shift context pressure away from the conversation window onto a structured task board. They emphasized that the solution is entirely open-source, doesn't promote any services, and is purely a distillation of their personal workflow. At the community's request, they extracted it from their own project and published it on GitHub.

Kanban board solution interface

The value of this approach lies in a simple insight: instead of piling all state into successive conversations, let the AI write work items to a Kanban board and read them back on demand. The board becomes a shared, persistent external memory layer that fundamentally alleviates the context burden of any single conversation.

Core Design: Making AI Agents Work in Tandem with a Kanban Board

Kanban Methodology: From Manufacturing to AI Agent Collaboration

Before diving into technical details, it's worth revisiting the origins of the Kanban methodology. Kanban originated in the Toyota Production System (TPS), proposed by Taiichi Ohno in the late 1940s to enable just-in-time (JIT) production. "Kanban" means "signal card" or "visual board" in Japanese, and its core philosophy is to visualize workflow, limit work in progress (WIP limit), and drive task flow through a pull-based system. In 2004, David J. Anderson adapted it for software development, formalizing the "Kanban Method." Borrowing Kanban for AI Agent engineering essentially extends it from a collaboration tool between humans into a state synchronization mechanism between humans and AI Agents—each card on the board is both a task state visible to humans and structured data that Agents can programmatically read and write.

A Project Entry Point That Agents Can Directly Read

The author specifically designed an AI_SETUP.md file whose purpose is to let you point your AI assistant at it so the AI can understand how to integrate this Kanban system into an existing project. This is a highly practical engineering detail—rather than verbally explaining a bunch of rules to the AI, give it a structured onboarding document to make the integration process standardized and reusable.

The accompanying README.md contains a more complete system description. The entire solution turns "how the AI uses the Kanban board" into a specification that machines can directly consume, not just documentation meant for humans.

All Work Must Be Recorded on the Board

The author repeatedly emphasizes one principle: all work should be recorded on the board, even minor fixes. In their own words—if half the work is on the board and half is off the board, then it's nearly impossible to keep the whole system coherent.

This highlights a key constraint of external memory approaches: memory completeness depends on discipline. As the AI's persistent memory, the Kanban board can only truly replace ever-expanding conversation context when all state changes are faithfully recorded. Any omission creates blind spots in the AI's world view.

Parallel Agent Execution: The Most Hardcore Part of This Solution

The real engineering substance of this solution is its support for parallel Agent execution—multiple AI workflows can simultaneously advance tasks in isolated environments without interfering with each other. The author implemented complete workspace lifecycle management through a set of PowerShell scripts.

This also echoes broader industry exploration in concurrent AI Agent execution. Between 2024 and 2025, Anthropic's Claude Code, OpenAI's Codex Agent, Devin, and other AI coding assistants have all been exploring multi-Agent collaboration patterns. The industry has several main approaches: long-context solutions rely on ever-expanding context windows; RAG (Retrieval-Augmented Generation) solutions retrieve information snippets on demand via vector databases; and the structured external memory approach shown here uses an explicit task management system as the Agent's "working memory." Microsoft's AutoGen framework and LangChain's LangGraph are also exploring multi-Agent orchestration. The common challenge across these approaches is: how to ensure state consistency and human observability while maintaining Agent autonomy. The Kanban approach has a natural advantage in observability—the board itself is a visual state management interface.

Workspace Isolation via git worktree

git worktree is an important feature introduced in Git 2.5 (released 2015) that allows multiple working directories to be checked out simultaneously from the same repository, each corresponding to a different branch. Traditionally, developers who needed to work on multiple branches simultaneously either had to frequently switch branches (risking conflicts with uncommitted changes) or clone multiple copies of the repository (wasting disk space and not sharing .git history). The advantage of git worktree is that all worktrees share the same .git object store, so disk overhead is minimal; each worktree is completely isolated at the filesystem level, preventing mutual interference; and branch locking prevents two worktrees from accidentally checking out the same branch.

In this solution, each AI Agent task is assigned an independent worktree, with each workspace having:

An independent git worktree and branch: Different tasks are physically isolated to prevent code contamination. Multiple Agents can simultaneously modify code on different branches, compile, and run their own dev servers without any file conflicts.
An independent frontend/backend port pair: The author's frontend and backend services are separated (with support for merging), and the system automatically claims an unused port pair for each workspace.
An independent DEV build and service instance: Once a workspace starts, it runs a dev build on its dedicated ports, and the Kanban board displays the status of all active workspaces in real time.

Scripted Provisioning and Teardown to Control Token Costs

The author specifically mentions that workspace provisioning and teardown are fully scripted, so they consume virtually no tokens—a very pragmatic cost consideration, since having the AI handle these management actions would burn through quota unnecessarily. The core scripts include:

scripts/new_workspace.ps1: Creates an isolated workspace including worktree, branch, and port pair, then starts two services; if a "parked" branch of the same name exists, it automatically remounts it.
scripts/sleep_workspace.ps1: Stops the workspace's two services to free memory but preserves the worktree, branch, port slot, and URL; can be restarted with the -Wake parameter.
scripts/remove_workspace.ps1: Completely tears down the workspace—stops services, deletes the worktree and branch, and releases the port slot; refuses to execute if there's uncommitted or unmerged work. -Park is a lighter option that returns the worktree and slot but preserves the branch.
scripts/workspace_common.ps1: A shared utility library, referenced by the above three scripts via dot-sourcing.

Regarding dot-sourcing, this is a script loading method in PowerShell with the syntax . .\script.ps1 (note the dot and space at the beginning). Unlike a normal script invocation, dot-sourcing injects the functions, variables, and aliases defined in the referenced script directly into the current scope, rather than executing them in a child scope and discarding them. This is similar to the source command in Bash or #include in C. In this solution, workspace_common.ps1 serves as a shared utility library that's dot-sourced, ensuring that common logic like port management, path resolution, and status checks only needs to be maintained in one place, while these shared functions can execute directly in the calling script's context.

Automated "Garbage Collection"

Even more commendable is the automated cleanup mechanism. The .githooks/post-merge git hook automatically sweeps idle workspaces after each merge lands: it puts workspaces idle for more than 15 minutes to sleep and cleans up workspaces whose branches have been merged.

Git hooks are Git's built-in event-driven scripting mechanism, triggered automatically before or after specific Git operations. Git supports about 20 types of hooks, divided into client-side hooks (such as pre-commit, post-merge, prepare-commit-msg) and server-side hooks (such as pre-receive, post-receive). The post-merge hook used in this solution triggers after every successful git merge. Notably, git hooks are not propagated with repository clones by default—this is a security measure to prevent malicious repositories from automatically executing code. Therefore, this solution places hooks in a .githooks/ directory that requires manual configuration (via git config core.hooksPath .githooks), which is common industry practice. Using post-merge to automatically clean up workspaces corresponding to merged branches is an elegant design—it ties resource reclamation to the natural milestone of code merging, requiring no manual intervention.

Additionally, the author uses Windows Task Scheduler to run some patrol checks, ensuring no services are left hanging indefinitely—and thoughtfully notes that if you don't need these checks, you can simply "pull the plug."

Getting Started and Some Pragmatic Reminders

The entire workflow is launched via the /backlog-auto skill. The author notes that apart from some pre-flight checks, this skill doesn't return anything in the chat window—all progress is written to the Kanban board, so from a conversation perspective it will "look like nothing happened." This is precisely the design intent: stripping state out of the conversation is the core of treating context bloat.

The author is also very candid about the solution's boundaries:

The UI isn't polished: The board interface is functional but "won't win any beauty contests"—the author didn't invest much effort in aesthetics.
It's not a mature product: Despite continuous refinement, edge cases that break the workflow may still exist.
Discipline comes first: Once again emphasizing that all work should go on the board to avoid a split between on-board and off-board work.

The author jokingly notes that extracting this system from their own project to publish as a standalone GitHub repository "used up their entire Claude Code 5x session quota"—which also reflects how costly it can be to abstract a deeply coupled personal workflow into a general-purpose solution.

External Memory Is a Critical Direction for AI Agent Engineering

Looking beyond this specific project, it reflects a larger trend: as AI Agents take on more and more actual development work, managing Agent state, memory, and concurrency is becoming a genuine engineering problem.

The approach of stuffing everything into conversation context has a natural ceiling, while the combination of "Kanban + git worktree + scripted lifecycle management" essentially builds structured external memory and execution sandboxes for AI. It lets multiple Agents work in parallel, isolated, and reclaimable environments, while humans observe and intervene through a visual board rather than staring at an endlessly scrolling plain-text window.

From a broader perspective, solutions like this sit within the spectrum of AI Agent memory management. Current industry exploration roughly covers three layers: short-term memory (the context window itself), medium-term memory (such as conversation summaries and session caches), and long-term memory (persistent external storage). The Kanban approach is essentially a structured implementation of long-term memory. Its difference from RAG is that RAG focuses on retrieving unstructured knowledge, while Kanban focuses on structured management of task states and workflows. The two aren't mutually exclusive—in fact, they're complementary: one manages "what you know," the other manages "what you're doing."

The author's own assessment is refreshingly modest: having a full board you can freely manipulate is "much more fun" than just having a plain-text window. For developers currently struggling with context bloat, this is at least an approach worth learning from—the answer may not lie in bigger context windows, but in smarter ways of organizing memory.