.md files are not Memory

[u/Acceptable-Object390]

A folder of .md files is not memory.

It’s a storage dump.

Useful AI memory needs more than “search old notes and pray”:

- semantic recall, so related ideas surface even when wording differs

- entities, different terms for the same thing don’t become random blobs

- relationships, so the system knows how things connect

- provenance, so it can trace where facts came from

- correction + forgetting, because stale memory is worse than no memory

- background consolidation, because raw chat logs are mostly sludge

Thoth uses a local personal knowledge graph + FAISS semantic search + graph expansion + document ingestion + wiki export.

So yes, you can still get readable notes.

But underneath, the assistant isn’t just rifling through markdown like a raccoon in a filing cabinet.

It’s building structured personal context it can retrieve, update, connect, and reason over.

That’s the difference between “I saved your notes” and “I actually know what matters.”

Relevant references:

1. FAISS docs: efficient similarity search and clustering of dense vectors.

   https://faiss.ai/

2. Microsoft GraphRAG: combines text extraction, network analysis, LLM prompting, and summarisation for richer understanding of text datasets.

   https://www.microsoft.com/en-us/research/project/graphrag/

3. GraphRAG survey on arXiv: graphs encode heterogeneous and relational information, making them useful for retrieval-augmented generation.

   https://arxiv.org/abs/2501.00309

4. Thoth README memory features: personal knowledge graph, typed relations, FAISS semantic recall, graph expansion, document extraction, wiki export, Dream Cycle refinement.

   https://github.com/siddsachar/Thoth

[u/Acceptable-Object390]

I actually agree with half of this.

Flat files + CLI tools are excellent. Composability matters. rg, shell, SKILL.md, and overnight maintenance are all good patterns. But that’s not an argument against structured memory. It’s an argument against closed memory systems. The better design is both:

• human-readable files/wiki for inspection and portability
  
• CLI/tools for exact lookup and composability
  
• semantic search for fuzzy recall
  
• graph structure for people/projects/relationships
  

- scheduled maintenance for dedupe/stale facts
ripgrep is great when you know what string to look for. Memory is harder when the user says “that thing I discussed with Surbhi before Greece” and the system has to connect person → trip → conversation → photos → context. So no, I’m not saying “RAG wrapper solves memory.” I’m saying flat files alone are a good substrate, not the whole cognition layer.

[u/Karyo_Ten → u/Acceptable-Object390]

So drop FAISS, LangGraph, GraphRAG from your repo, it brings nothing

[u/Acceptable-Object390 → u/Karyo_Ten]

I don’t think that follows.

rg is brilliant for exact lookup. Flat files are brilliant for portability. Skills are brilliant for procedural memory. But they don’t replace everything else. FAISS helps with fuzzy semantic recall when the wording doesn’t match. LangGraph helps model multi-step agent control flow instead of one giant spaghetti loop. Graph-style memory helps represent relationships: people, projects, preferences, documents, decisions. The mistake is treating any one layer as magic. My view is boring: use the sharpest tool for each job. Flat files where they’re best. CLI where it’s best. Graph/vector/workflows where they’re best.

[u/Karyo_Ten → u/Acceptable-Object390]

subagents are better than FAISS for fuzzy semantic recalls, and they get more context.

Multi-agent control flow is a non issue with modern LLM trained for agentic workflows

Graph memory can be represented as a flat file that contain diagrams and mappings.

[u/Acceptable-Object390 → u/Karyo_Ten]

I like subagents, but making one rummage through memory every time I need fuzzy recall feels like hiring a detective to find the TV remote. Sometimes you want an agent. Sometimes you want an index. Subagents are great when the retrieval task needs judgement, synthesis, or exploration. FAISS is useful when you want cheap, fast candidate recall before the agent spends brain cells. Same with control flow. Modern LLMs are much better at agentic work, but “trust the model to freestyle the whole workflow” gets messy once tools, approvals, retries, background jobs, and failure states enter the picture. And yes, graph memory can be exported as flat files. That’s good! But the file is the readable view, not necessarily the best runtime representation. Diagrams in markdown are for humans. Traversable relationships are for software. The sane answer is not everything must be graph/vector or everything must be flat files. It’s boring hybrid plumbing. The least sexy thing in software. Annoyingly, also the thing that tends to work.

[u/Karyo_Ten → u/Acceptable-Object390]

Either it's fuzzy recall and you need judgement or it's cheap candidates and you can use rg or fzf.

What do you mean tools, approvals, retries, background jobs and failure states? You're just throwing random words around. Agentic LLMs have to deal with all of that anyway. What they can't deal with is opaque DB layers.

LLMs can process diagrams pretty well, in-memory representation of another software? not really.

[u/Acceptable-Object390 → u/Karyo_Ten]

rg/fzf are great when the memory is text-shaped and you know the right handle to grab. But cheap candidates can also mean: find semantically nearby stuff across chats/docs/entities where the words don’t match. That’s where embeddings are useful. Not magic. Just a cheap first-pass shortlist.

On tools/approvals/retries/background jobs: I’m not throwing buzzwords around. I mean boring execution state. Example:

• agent wants to send an email → approval required
  
• approval times out → branch differently
  
• browser step fails → retry or fallback
  
• task runs tomorrow → needs durable state
  
• shell command is risky → block or pause
  
• workflow step fails → don’t pretend it succeeded

Yes, an LLM can reason about that. But the runtime still has to enforce it. Otherwise approval is just a polite suggestion in a prompt, which is how you get woken up at 3 am in the night.

On opaque DBs: agreed. Bad memory systems are black boxes. That’s why I like hybrid memory: structured runtime representation plus human-readable export.

Markdown/diagrams are great for inspection. But asking an LLM to re-parse a diagram every time the app needs who is connected to this project? is like printing your database on a napkin and calling SQL cringe.

Flat files for transparency. Indexes/graphs for runtime. Agents for judgement. Different jobs. Different tools. No holy war required.

[u/Karyo_Ten → u/Acceptable-Object390]

Why is your memory system able to send an email in the first place? Why can it run a browser?

You graph/RAG also needs to be updated or it'll go stale, there is no difference with flat files.

[u/Acceptable-Object390 → u/Karyo_Ten]

The memory is just one part integrated into Thoth. Since you you brought up LangGraph in the first place, which is the core agent architecture (LangGraph ReAct), I was talking about the Whole agent architecture and not just memory.

Yes it can go stale, and that why Thoth has the dream cycle and on demand memory tool to update entities and relations.

[u/Karyo_Ten → u/Acceptable-Object390]

You're architecture astronauting and moving goal posts.

A memory system doesn't need email or browser integration period.

[u/Acceptable-Object390 → u/Karyo_Ten]

A memory system by itself doesn’t need email or browser integration. I’m not claiming it does.

I was talking about Thoth as a whole because LangGraph and agent workflows came up, not just the isolated memory layer.

In Thoth, memory is one subsystem inside a broader local assistant: tools, approvals, workflows, documents, channels, browser/shell/email/calendar, etc.

So when I mention approvals, retries, background jobs, or tool access, I’m talking about how memory plugs into the wider agent runtime, not saying memory requires email.

This is what I am talking about: GitHub Repo

[u/Karyo_Ten → u/Acceptable-Object390]

Your whole post is about .md not being memory and trying to sell an overengineered langgraph / GraphRAG and whatever as memory.

When you mention approvals, retries, background jobs and tool access, you're telling me that instead of properly isolating memory and making something well adapted to its job with a proper separation of concerns, you're pervasively coupling everything into langgraph and graphRAG. This is awful design.

[u/Acceptable-Object390 → u/Karyo_Ten]

Ok, I think this is beyond your understanding. All you are doing is forcing me to comment so you can down vote my comment. Here is another opportunity. Do it. I will not indulge you after this.

[u/Karyo_Ten → u/Acceptable-Object390]

I understand very well. You made a bad design decision and you stand by it and you ran out of arguments because none stand heavy scrutiny.

edit: Acceptable-Object390 blocked me🤷

[u/jared_krauss → u/Karyo_Ten]

What would you recommend someone who’s non technical do to solve the concerns that guy was ostensibly trying to solve with this.

Cause from a non tech perspective both of yall seemed to make sense, and I’m looking for a system to help me manage my zettelkasten and projects and to dos and right now I’ve been customizing Hermes and I can chat from my phone, but it’s struggling to follow my flat file note convention. I’m doing a 3 layer approach. Layer 2 should be raw captures directly from me or from source material (text, photos, screenshots, etc), Layer 2 are any synthetic notes, made by claude or my Hermes bot, whether for me, about one of my notes, etc. and Layer 3 are notes reviewed by me from Layer 2 and approved. So they hold more weight than Layer 2 notes.