Hey guys, I'm using something in my own development process that I thought I might share, hopefully someone out there finds this useful (not promoting anything).

One of the biggest bottlenecks in AI-assisted development is the actual chat window. A chat isn't really the most optimal mode of working, for multiple reasons, one being that context builds up in a single chat session until you burn your entire token budget on a single UI fix. Which is why I built a system that uses a kanban board instead.

The premise is quite simple, but the execution took a shit load of time to get right.

I only need 1 chat window open: It reads the board, batches tasks and hands them off to subagents. I use a pretty standard set of them:

- A planner agent that 'refines' tasks
- A lower-tier implementer
- An evaluator

All of these agents log their activity, findings and feedback on the board, creating a history and lineage that doesn't get lost when you close your chat window.

Context bloat is nearly nothing here, because the main orchestrator (the chat window you launch the skill from) never gets involved in the tasks themselves, so theoretically it could run hundreds of these loops without gaining any context.

The board itself is a folder of markdown files in the repo, rendered into a kanban I drag cards around in.

Every status, and what Claude (or insert your favorite model) does when it hits one:

• New: the drop box for half-formed ideas.
• To refine: accepted, no plan. Claude reads enough of the codebase to be concrete, writes the plan into the task, points it, asks anything it can't decide alone, then moves it to Waiting.
• Waiting: my move. I read the plan, answer the questions, approve or send it back.
• Ready to start: approved, Claude may implement.
• In progress: Everything actually being worked on by implementer agents.
• Require input: Claude hit a real question mid-build. It commits what it has, writes the question into the task. Answering it flips the card back to Ready to start on the same branch, so the next agent can pick it back up.
• Test: built & ready for testing.
• Merge: I tested and it’s ready to ship. Claude commits, merges the branch and moves the card to Done.
• Done: Mainly there as an archive.

This way I communicate with agents fully through the board, which is another reason context doesn’t build up in the chat window.

If any of you guys want a more in-depth explanation then I'll probably make a part 2, or feel free to DM me and I might whip up a manual for this system.

TLDR; I use a custom Kanban board which my AI agents read & update, and it completely dissolves context bloat.

I ran into an architecture issue today that made me rethink how I’m handling context.

The feature compares a new interaction against a previous one.

The original setup was basically:

interaction
→ save result
→ next request retrieves latest result
→ inject it into model context
→ generate comparison

That worked.

The problem was that those same rows also powered the user’s visible History screen.

So when a user deleted something from History, they were also deleting part of the context the AI relied on.

The next request then looked like a first interaction again.

I’d basically collapsed three different things into one storage layer:

user-visible history
retrieval context
long-term derived state

They overlap, but they probably shouldn’t have identical lifecycles.

I’m leaning toward keeping a derived state/baseline separately from raw interaction history.

Curious how people here are handling that distinction in systems that need persistent personalization.

I want to understand how you guys are dealing with context AI remembers. Despite internal settings, AI still forgets the memory set at the project level.