My conversation in [LinkedIn article](https://www.linkedin.com/pulse/i-built-my-ai-brain-obsidian-had-tear-down-štěpán-rešl-qt9rf/), especially the part: > 1. **No / Poor metadata model.** This is one of the keys, how to make it work properly. You need to have right metadata, so you can find your starting point as soon as possible. > 2. **Distant nodes.** If a node is far away (meaning a lot of nodes must be loaded in between to get the full connection), it can easily cost you many more tokens and lead to more errors, because the chance that Claude takes a different path along the way keeps rising. > 3. **Poor graph structure and imbalance.** If it's built like multi-star / multi-snowflake schema, it won't give you an effective way, to query it. Same if everything is connected to everything. > 4. **Claude will find the way.** Of course it will find a way, how to answer to your question. Will it be deterministic and stable every time? Probably not... usually it's not. And this part is almost like my struggles: > I had to dig up some memories from university, where we discussed graph design, shortest paths, node centrality and yes, even Hamiltonian paths. I remember precisely why my brain hurt so much back then. But after some tests and calculations, I found out that my Obsidian design was simply... **terrible**. So I had to start from scratch and rebuild the whole structure into a functional, weighted graph with a few internal helpers that navigate my algorithm (yes, I'm not saying Claude anymore) in the right direction. A second brain is not memory storage for AI - it is your understanding, written by you, so the agent that reads it understands how you perceive the world and adjusts its predictions to your viewpoint. 1. poor metadata model - the problem is not a model, but that [[Don’t worry about structure|there is none]] - that is the point of a graph-like "structure": no top or bottom, nothing to structure except [[Always link your notes and explain why|composition (linking)]] and [[Use only the basic metadata|basic metadata to query it]], like the `when` property to display a calendar - I've been using Obsidian since it appeared and never actually needed more complex metadata; this area is often over-engineered 2. distant nodes - the `app.metadataCache` API holds the entire graph without loading the markdown files - tell your [any] agent to use it and you can traverse the graph without spending many tokens 3. poor graph structure and imbalance - there is no structure, accept it, rly - read about Zettelkästen first 4. Claude will find the way - no, it won't, ofc they will develop better agents, but not a better [your] knowledge graph - it represents your understanding [not theirs] - simply speaking, don't delegate your understanding, refine your notes and links, and accept that it will stay imperfect > On "no structure": Zettelkasten is a structure, just an emergent one. Emergent is great for human serendipity and terrible for deterministic querying. That difference is exactly what my article is about. Depends on what emerges, doesn't it? :D Actually this is exactly why it is hard, because you need to put in good abstractions that you can query - not only via frontmatter, but via links to these abstraction notes (!). E.g. `List all [[Post|posts]] about [[Retrieval]] and [[Obsidian]] from today` could be translated by an agent to the filter `hasPathTo([[LinkedIn post]]) && hasPathTo([[Retrieval]]) && hasPathTo([[Obsidian]]) && when == today()` and in my Obsidian will return just 1 note about your post :) - no need to read the markdown files, just the API. The distance between notes doesn't matter. Moreover it is deterministic. But you need to do 2 things first: 1. decompose your knowledge graph into more specific knowledge units (it is your job, agents suck at it a lot, I lost 3 months trying, but generative AI is great at generation, not at extracting abstractions :( ) 2. write a few graph algorithms into scripts, like hasPathTo, topological sort, etc. (which current AI will do easily :) ) > One thing I noticed in my own tests: hasPathTo alone gets weaker as the vault gets denser. A path exists to almost everything, so the mere existence of a path stops carrying information. Bounding the depth or weighting the edges helped me a lot, and that’s how I ended up with a weighted graph. > “In the end it doesn’t differ that much from old programming” might be the most accurate sentence in this whole thread. Thanks for this exchange, this is the kind of discussion I was hoping the article would start. Yeah, we have similar struggles, and I would say that we would like to make an agent as cognitive as we are. There is a catch with "A path exists to almost everything, so the mere existence of a path stops carrying information." - it really depends on what a link actually carries. My trick is simple: when you write and mention the other note, you actually link to more primitive (abstract) information or the older one, not the other way around (links in both directions are redundant, cycles indicate wrong decomposition, like in programming :D) - in the end you should finish with a directed acyclic graph (DAG), and it is very easy to search and sort. That's why hasPathTo or topological sort works for me. But the hard part is that I came to this after a few years of rewriting (relinking) my knowledge (I've been using Obsidian since 2020) - this is the work I would name "my understanding", and even if an agent is able to do the same work it will still be "its understanding". That's why I consider the Karpathy method a dead end, but for sure a very valuable lesson.