Beads-compatible design reasoning memory system

[rpggio]

I have been working on a memory system for AI-assisted design which is inspired by Beads. The goal is to make the compressed reasoning structure of a design available between one chat (or code session) and the next, and to provide a paper trail of design progression.

My current prototype makes use of filesystem tool access - it's just a single skill file currently. (CLI to come next.)
My intent is to make it Beads-aware, so it can feed goals and requirements into Beads issues.

Does this sound useful? Is this solved elsewhere, and I missed it?

[peterkc]

Interesting timing! I've been working on something similar with beads.

The problem I was solving: How to preserve "compressed reasoning" (as you put it) across sessions—architectural decisions, patterns discovered, gotchas encountered—without it getting lost to context window limits or session boundaries.

Key insight: BD v0.46.0 added custom type support. This means you can create your own issue types for knowledge storage:

bd config set types.custom "memory,note"  # or whatever names fit your mental model
bd create "OAuth: Use PKCE for stateless auth" --type=memory -l decision -l critical

This makes "design reasoning notes" first-class beads issues without forking or custom tables. Labels give you filtering and tiering—I use critical for things that should auto-load at session start, reference for things I query on-demand.

Architecture pattern that helped: Separate repo for knowledge vs work. My work-tracking beads (tasks, bugs) have different lifecycles than knowledge (work closes, knowledge persists). Keeping them in separate .beads/ databases prevents pollution and lets them scale independently.

What I'm still figuring out:

• Automatic capture at session boundaries (hooks help but timing is tricky)
• Connecting knowledge back to the work that generated it
• Tiering: what loads automatically vs on-demand

Haven't published anything yet—still actively developing. But the BD custom types approach eliminated most of the custom sync code I thought I'd need.

Would be curious to compare notes if you get further!

[madanyang]

I have been using https://github.com/mkreyman/mcp-memory-keeper before I started to use beads, and I still use it along with beads, have look maybe you don't have to reinvent the wheel or make it better.

[rpggio]

@peterkc I did a bit of research on using bd custom types for this. The different lifecycles were a problem. But using separate databases makes a lot of sense. I'll reach out!

[peterkc]

mcp-memory-keeper is solid—the checkpoint metaphor ("save game before boss fight") works well and semantic search is a nice built-in.

One trade-off worth considering: MCP servers add tool definitions to your system prompt. Memory-keeper exposes 15+ tools, which costs ~5-7k tokens in context overhead—paid whether you use them or not in a given session.

If context budget is tight, CLI-based approaches (like native bd commands) avoid that tax but lose the in-context convenience. Depends on your priorities:

Approach	Context Cost	Convenience
MCP tools	~5-7k tokens (fixed)	Claude calls directly
CLI-based	0 tokens	Explicit invocation

Both solve the core problem of persisting design reasoning—just different trade-offs on how Claude interacts with the storage.

[madanyang]

one has to give to get something and the RECIPIES,md is imo golden, but everyone's needs are different

[jhult]

https://github.com/Dicklesworthstone/beads_rust

br is a local-first issue tracker that stores issues in SQLite with JSONL export for git-friendly collaboration. It's 20K lines of Rust focused on one thing: tracking issues without getting in your way.