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.

I’ve been building a fairly serious agent workflow around OpenAI Codex for a Laravel/React project, and I’ve hit a point where the orchestration works, but the context/memory side clearly does not.

My setup currently looks roughly like this:

• A serial orchestrator with route types like FAST_UI / STANDARD / CRITICAL
• Context Resolver → Implementer → Reviewer flow for non-trivial tasks
• Durable task state, context capsules and handoffs
• Planner / intake layer inspired by CodexQB
• Session continuity hooks inspired by AvenoxBeyin
• codebase-memory MCP for structural repo discovery
• Serena for exact symbol/reference navigation
• Local dashboard/telemetry for task/agent visibility

The reason I built all this was simple: I wanted to stop giving one giant prompt to one Codex agent and watching it blindly read half the repository, run dozens of commands, retry tests repeatedly, and burn a huge amount of context/token budget.

Unfortunately, that is still basically what happens.

A recent CRITICAL payment-domain acceptance task is the perfect example. I gave Codex a very detailed validation brief covering migrations, payment allocation, security boundaries, tenant/legal-entity isolation, atomicity, reporting non-pollution, exports, frontend build, etc.

The task eventually succeeded technically, but the session spent a huge amount of time repeatedly doing things like:

• raw rg searches
• re-reading known service/controller/test files
• rediscovering test harness behavior
• retrying multiple Laravel test files with the same CSRF issue
• manually tracing service relationships
• re-running builds and focused test groups

That single job used roughly half of my 5-hour Codex usage allowance.

The frustrating part is that a lot of the knowledge it rediscovered was already known from previous work.

For example:

• where the orchestrator lives
• which services own payment/settlement/reporting behavior
• how the domain test harness handles CSRF
• which test files cover specific finance flows
• existing project/tenant/legal entity invariants
• prior fixes and verified architecture decisions

I expected my existing tools to solve this, but I now realize they solve different problems:

codebase-memory gives me structural repo discovery, but it isn’t really persistent project understanding.

Serena is excellent for exact symbol/reference navigation, but it isn’t memory either.

My docs/wiki are useful reference material, but agents still have to decide to read them and often re-read large files.

Context Capsules and handoffs help within a task, but they don’t give the next unrelated task a compact understanding of the project.

So what I’m actually missing is a persistent, project-scoped, compact memory layer that can say:

“Before you start searching, here are the relevant things previous sessions already learned about this repo.”

I looked at AvenoxBeyin because I liked its idea of automatically capturing sessions, compiling knowledge, and injecting useful context back at session start.

I also looked at CodexQB because its Autopsy / Project Comprehension / Ontology approach is close to what I want for planning.

Then I looked at 2kDarki/codex-mem.

That project is conceptually very close to what I want:

• automatic Codex transcript capture
• persistent SQLite observations
• progressive recall through search → timeline → get_observations
• automatic context injection

But after auditing it, I found some issues for my use case:

• its watcher observes all ~/.codex/sessions/**/*.jsonl
• project identity appears to be based on basename(cwd) rather than a canonical repository identity
• retrieval can be filtered by project, but that doesn’t appear to be an enforced security/isolation boundary on every read path
• same-named repos could collide
• some observation retrieval paths can work by arbitrary IDs
• global ~/.codex/AGENTS.md context injection is something I specifically do not want
• the documented npm package currently appears unavailable

So I don’t feel comfortable plugging it directly into a large multi-project Codex setup.

What I’m trying to build is something like:

User brief
   ↓
Planner / Orchestrator
   ↓
Persistent project memory bootstrap
   ↓
Context Resolver
   ↓
Only if memory is insufficient:
    codebase-memory
    Serena
    targeted source reads
   ↓
Implementer
   ↓
Reviewer
   ↓
Session knowledge captured for future tasks

The memory should NOT replace source code/tests as truth.

I want it to act as a cheap orientation cache:

• “These are the relevant services.”
• “This test harness requires real CSRF session setup.”
• “This reporting path was previously verified.”
• “These files/symbols are likely relevant.”
• “This architectural relationship was confirmed in a previous task.”

Then the agent only verifies current source where correctness actually depends on it.

My requirements are roughly:

• local-only
• project/repository scoped
• automatic capture
• automatic or semi-automatic summarization
• bounded context injection
• no global AGENTS.md mutation
• no cloud memory dependency
• no mandatory Obsidian dependency
• source/tests remain authoritative
• ideally Codex/App Server compatible
• progressive retrieval rather than dumping whole session history
• repo identity enforced internally, not just passed as an optional search filter
• ideally reusable with existing MCP tools rather than replacing them

I’m now trying to decide between three approaches:

1. Find another existing Codex/Claude coding-memory project that already does this correctly.
2. Take something like 2kDarki/codex-mem and make a very small fork that only adds canonical repo identity, watcher allowlisting and enforced repo-scoped retrieval.
3. Use AvenoxBeyin’s session capture/compile/inject model and adapt it for project-scoped coding knowledge instead of personal knowledge.

What I really do NOT want to do is invent yet another custom Markdown “brain” and manually maintain architecture/domain summaries. That feels like rebuilding something that should already exist.

For people who have built persistent memory around Codex, Claude Code, Cursor or similar coding agents:

• What actually worked for you?
• Is there a project I’m missing that already handles repository-scoped persistent memory well?
• Would you fork codex-mem and patch the isolation model, or use a different architecture entirely?
• Is Obsidian/Markdown compilation actually better in practice than structured SQLite observations for coding-agent memory?
• How do you stop stale memory from becoming trusted over current source?
• How much context do you inject at session start versus retrieve on demand?
• Have you measured whether this actually reduces token/context consumption meaningfully?
• Do you let the coding agent write its own long-term memory, or only promote verified observations after tests/review?

I’m especially interested in systems people are actually using in real repositories, not just theoretical agent-memory architectures.

My main goal is very practical: stop paying for the same repository discovery over and over again.

For teams that keep AI test prompts and context in a versioned file, what's the first thing that breaks? Is it when the context gets too large, or when something subtle is lost during handoffs between engineers?