Add native Beads integration as long‑term memory backend

[russosalv]

Hi,
I’d like to propose a native integration between BMAD-METHOD and Beads (github.com/steveyegge/beads). Beads is a git-backed, agent-first issue tracker and memory system that lets AI agents persist and query decisions, dependencies and “ready work” directly inside the repo.​

For BMAD this could act as a long-term memory layer that complements PRD/Architecture/Story files by:

Storing retro decisions in a structured, queryable way (per sprint, domain, priority), so SM/Dev agents can actually reuse those decisions in future stories instead of forgetting them.

Tracking recurring frontend/backend bugs and canonical fixes, giving Dev agents a concrete place to look for “how we solved this last time” and which patterns the team agreed to standardize.

Providing a cross-sprint memory of process and architecture choices linked to the same git repo, instead of scattering them across ad-hoc docs.

The idea is not to replace BMAD’s workflow, but to give BMAD agents a first-class, repo-local memory graph they can read/write to when planning, implementing and refining work. In my experience this would significantly reduce repeated mistakes and help agents stay aligned with previous decisions over many sprints.

Would you consider adding official support or at least documenting a recommended way to use BMAD together with Beads as a long-term memory backend?

[ozenalp22]

I added on my fork of 6.0alpha if you want to try it out
https://github.com/ozenalp22/bmad-withbeads

[bmadcode]

how has this been working out? I have not had time to consider this yet. while I do not plan to add this in, potentially supporting this and other options so ppl can choose their own set up is desired.

[Ganbin]

Personally, I use BEADS and BMAD on a daily basis. I find that the two work very well together.

[curious-talleb]

Can you explain how you use them both? Are you using the implementation of ozenalp22?

[apantin]

Hi @Ganbin (and anyone else who’s tried this)! I’m trying to combine Beads with BMAD-METHOD and I’m wondering if you could share your experience.
If you have a write-up or notes showing how you use Beads—especially as a long-term memory layer for BMAD agents—I’d really appreciate a link.
Also curious about any gotchas or things that didn’t work well in practice.

[doc-krieger]

Would love to see this.

My current workflow is basically BMAD + Beads as my “project memory” layer:

• I use BMAD to generate and maintain the core docs (PRD, epics/stories, sprints, project context).
• Then I use Beads to break stories/sprints into smaller tasks (beads) and implement them with the beads task agents.

The big win is that each task leaves behind a clean, easy-to-find entry I can reference later. When something breaks, I can just point Claude at the relevant bead and it can get up to speed quickly.

I do the same thing for code review: when BMAD finds issues, I turn the valid ones into beads so they don’t get lost (plus any bugs/discoveries along the way of usual development). When I finish an epic, I can even ask Claude to review the beads for that epic to sanity-check that the docs and loose ends are actually complete.

It’s probably overkill, but it’s dramatically reduced “Claude forgot what we did” problems—especially if I keep new sessions per task/issue. Even after compaction it stays pretty on-track, because it can just anchor itself on the current in-progress bead.