Alternative forms of memory (e.g. Knowledge Graphs)

[BradKML]

There are some memory designs that are different from just chat history (#486) and conventional memory banks (#284) that might be worth looking into for documentation and problem-solving.

Regarding knowledge graphs and PKM integrations, here are some examples:

• https://github.com/basicmachines-co/basic-memory
• https://github.com/shaneholloman/mcp-knowledge-graph
• https://github.com/okooo5km/memory-mcp-server
• https://github.com/gannonh/memento-mcp
• https://github.com/T1nker-1220/memories-with-lessons-mcp-server

There are some examples where knowledge graphs can probably do better than just vector DB or fuzzy text search:

1. Capturing lists of errors and failed solutions, to reflect on common issues and discover prevention or shared causes (DAGs mixing divergent thinking and convergent thinking)
2. Clustering related features together, for those with tightly coupled dependencies, and slowly adopting proper design patterns to decouple them effectively (node distances and community detection)
3. Creating new ideas by linking user requirements together in novel ways like "deep research" (web crawling) and other forms of lateral thinking

Some questions to consider:

1. How can MCPs interact with one another (task master vs knowledge graphs vs deep research) without clashing in the process?
2. Out of those links, which ones should be selected to be the default to work with Task Master? Basic Memory or MCP-KG?

[BradKML]

Side note: for every PKM, there are many MCP ready for other apps, but there are certain features that are missing when it comes to project-tracking https://github.com/basicmachines-co/basic-memory/discussions/113#discussioncomment-13138263 https://github.com/onigeya/siyuan-mcp-server/issues/12

[eyaltoledano]

I’d REALLY like to have a task graph and a code graph. Context that shows what and how relational the code and its artifacts are, and same with the tasks

this probably lives on a local graph db

i’m not a huge fan of “memory” mostly because its role is uncleR, especially if context is given permanence

buuuuut if could be a valuable method for half life information to persist just enough to keep the agent focused on its subtask before having to address something else

or compiling and keeping every instance the agent gets stuck and refeeding into the subtask with update-subtask — it could be a method for empowering the workflow moreso than as a way of storing things

for storage i’d look to elevate the context given to taskmaster. Especially code context

[joedanz]

Some feedback from online.. https://x.com/pashmerepat/status/1926717705660375463

[BradKML]

@joedanz "codebase Q&A" seems to be what they are referring to, and that unless we can replicate it for Cursor/Windsurf and RooCode/Cline, it's kinda meh https://www.anthropic.com/engineering/claude-code-best-practices https://pashpashpash.substack.com/p/why-i-no-longer-recommend-rag-for
There is a good rebuttal conversation on how RooCode should be doing RAG for human-facing design notes and not codebases (which should be using Aider-like repomap and related code tooling), but UX documentation matters a lot in bigger projects https://www.reddit.com/r/ChatGPTCoding/comments/1ktt4ab/comment/mtw9xec/

[Shashankss1205]

Checkout: https://github.com/Shashankss1205/CodeGraphContext, Exactly what you needed :)

[Crunchyman-ralph]

@Shashankss1205 thats cool dude, can you turn it into an ai sdk tool ? we need to start getting code context into taskmaster while generating plan and expanding tasks

[Shashankss1205]

Yeah, that's in my immediate bucket list. Will launch it by next week :)

[joedanz]

I was playing around a little - let me know what you think of the following.. I added a task-graph command that generates taskgraph.md and taskgraph-subtasks.md from tasks.json as mermaid diagrams in the tasks folder. The one with subtasks is very busy, but can be filtered by status or ID. Just some ideas...

[BradKML]

Think about how some tasks have bidirectional flows, where data can flow one way while design constraints can flow the other way. The job of the memory graph (or documentation in general) is to settle issues between heavily interlinked tasks that warrant iterative refactoring.

[Crunchyman-ralph]

@joedanz how do we make this hehehe

[BradKML]

Interesting memory repos to consider

• Decision logs and quality checks https://github.com/shipdocs/roocode-memorybank-optimized
• Full automated note taking https://github.com/GreatScottyMac/cascade-memory-bank
• "Best Practices" https://github.com/botingw/rulebook-ai
• History-hunting https://github.com/dazeb/cline-mcp-memory-bank
• Separating context types https://github.com/ipospelov/mcp-memory-bank
• Tool statefulness https://github.com/movibe/memory-bank-mcp
• Layered memories https://github.com/aurda012/cursor10x-mcp

[eyaltoledano]

This is great @joedanz -- I think the main missing point is still the code

Each task essentially needs to be aware of where exactly the implementation lives (or should live)

This would allow the graph to include the code within the relationships which implicitly creates dependency connections between those tasks provided they rely on the same code

Loving this discussion and where it's headed. Thanks @BradKML

[BradKML]

Something extra to consider: design documents should be more expansive than PRD or task files. If a codebase is worth refactoring, every piece of detail matters, so having a feature/requirements graph to accompany the code structure would be important. #133

[BradKML]

Also found this as well https://github.com/RPG-fan/Cline-Recursive-Chain-of-Thought-System-CRCT-

[BradKML]

Some more ideas to consider regarding RAGs (will check other repos that aggregate techniques together) https://github.com/FareedKhan-dev/all-rag-techniques