Your Obsidian Vault Is a Knowledge Graph

written by Stefan Christoph

- 11 minutes read

🎬 Also available as a blog walkthrough video: a narrated screencast of this post.

TL;DR: Tony Seale spent six months working almost entirely inside a markdown wiki wired to an LLM, and argued the most useful bridge between fuzzy language and precise logic was not exotic, it was plain markdown with structure around it. I want to take that one step further with a claim about tooling people already have: a folder of markdown notes, linked with wikilinks and tagged with frontmatter, is already a semantic knowledge graph. Wikilinks are edges, frontmatter is typed node properties, folders are namespaces. That is the exact shape an AI agent wants for its long-term memory, and it is why my own setup, kiro-cli reading an Obsidian vault, traverses that graph every day, including the session that wrote this post. You still graduate to a real graph database when you need to, and I will draw that boundary honestly.

The Realization I Kept Having Backwards

For a long time I thought of my notes and my agent as two separate things. The notes were where I wrote things down. The agent was the clever part that did work. The notes were storage; the agent was intelligence.

That framing is backwards, and a post by Tony Seale finally made me say so out loud. Seale described barely opening anything but a markdown wiki connected to an LLM for six months, and made a quietly radical point: the markdown is not a passive store the model dips into. It is the model’s memory, and the structure in it, the links and the properties, is what turns a pile of text into something an agent can reason over [1].

Once you see it that way, a second thing follows. The structure most note-takers already use, links between notes and a bit of metadata at the top of each one, is not a poor substitute for a knowledge graph. It is one. You probably built a knowledge graph without noticing, and your agent can read it today.

What Actually Makes Something a Knowledge Graph

A knowledge graph is, at its core, three things: nodes (the things), edges (how the things relate), and properties (facts about each thing). Classic implementations express this in formal triples, subject-predicate-object, and store them in a graph database you query with a language built for traversal.

Now look at a linked markdown vault.

  • Each note is a node: one subject, one file.
  • Each [[wikilink]] is an edge: this note relates to that note, and the link text often names the relationship.
  • The frontmatter block at the top of each note is a set of typed properties: type: customer, status: active, tags: [knowledge-graph, agent-memory].
  • Folders are namespaces: customers/, meetings/, research/ scope what a note is about before you read a word of it.

That is a graph. Not a metaphor for one. The triples are there: this-note — links-to — that-note. The node types are there in the frontmatter. The only thing missing compared to a formal store is a strict ontology and a query engine, and as I will get to, you do not always need either.

Three markdown notes connected by wikilink edges, each carrying frontmatter properties

A linked vault is a graph: notes are nodes, wikilinks are edges, frontmatter is typed properties, folders are namespaces.

The Neuro-Symbolic Part Is the Interesting Part

Seale’s sharpest point is not “use markdown.” It is that markdown sits in two worlds at once [1].

The prose in a note is a neural representation: fuzzy, contextual, the kind of thing a language model is good at absorbing and continuing. The structure around the prose, the links and typed properties, is a symbolic representation: discrete, precise, the kind of thing you can follow deterministically. Language and logic both speak in subjects, predicates, and objects, and a structured wiki lets them share one space instead of living in two systems you have to keep in sync.

This is the neuro-symbolic bridge people have chased for years, and Seale’s claim is that it turned out to be unglamorous. You do not need a separate symbolic engine bolted onto a model. You need text with enough structure that both the model and a plain traversal can use it. The recent surge of interest in markdown-as-memory primed a lot of people to try this, and what they find is that the boring version works.

Where This Lands in Agent Memory

There is a useful taxonomy of agent memory that maps human memory onto machines. IBM’s write-up, drawing on the CoALA paper, splits long-term memory into episodic (specific past events), procedural (learned skills and routines), and semantic memory: structured factual knowledge, “implemented using knowledge bases, symbolic AI or vector embeddings,” the layer an agent retrieves from to reason [2].

A linked vault is a clean fit for that semantic rung — the top of the memory spectrum I mapped out in the first part of this series. It is the agent’s structured factual knowledge: who this customer is, what was decided in that meeting, how this concept connects to that one. It is not the conversation buffer (that is short-term memory) and it is not a log of every action taken (that is episodic). It is the durable, organized model of the world the agent reasons over, which is exactly what semantic memory is for.

If you have read my earlier piece asking whether RAG is still needed with million-token context windows, this is the other half of that answer [3]. Big context windows handle what you can paste in now. A knowledge graph handles what the agent should be able to walk to later. Different jobs.

My Setup Is Literally This

I am not describing a thought experiment. My own working setup is kiro-cli, a terminal coding agent, reading an Obsidian vault as its backbone. The vault holds customer notes, meeting notes, research, and the rules and workflows the agent follows, all as plain markdown with wikilinks and frontmatter.

When the agent prepares a meeting, it does not get handed one big blob of text. It starts at the meeting note, follows the wikilink to the customer note, follows that to the relevant research, and reads frontmatter to know what kind of thing each note is. That is graph traversal. It is doing it right now, in the session that produced this article: it read the source note, walked the links to related posts, and assembled the context from the graph rather than from a single file.

What makes this work is not that markdown is special. It is that the structure is consistent enough to traverse. A link I write for my own future reference is, unchanged, an edge the agent follows. The metadata I add so I can find a note later is, unchanged, a property the agent filters on. The same structure serves the human and the machine, which is the whole point of the neuro-symbolic framing: one space, two readers. I have written before about designing an agent’s skills as bounded contexts with their own consistent vocabulary [4], about how the most reliable parts of a skill are the ones with a single correct answer [5], and about structuring my own website so agents can read and traverse it [6]. A traversable vault is the data-layer version of the same discipline: structure where structure pays off.

The Honest Boundary: When You Do Need a Graph Database

Here is where I have to be careful, because the easy version of this argument overreaches. Markdown does not replace graph databases. It replaces reaching for one too early.

A linked vault is excellent when the graph is human-scale, traversal is “follow a few links from a starting note,” and a person or a single agent is the main reader. It struggles the moment you need any of the following, and these are exactly when a real graph store earns its place:

  • Queries across the whole graph. “Find every customer in this industry who mentioned this concern in the last quarter” is a query. Walking links one note at a time will not answer it. A graph database with a query language will.
  • Scale beyond what fits in a working set. A few thousand notes, fine. Millions of entities with dense relationships, not fine. Index and storage engines exist for a reason.
  • A strict, enforced schema. Frontmatter is convention, not constraint. Nothing stops me typing type: custmer. A real store can enforce the ontology so the graph stays clean at scale.
  • Concurrent writers and transactions. One person’s vault is one writer. A shared graph serving many agents and services needs the guarantees a database gives.

So the honest rule is a maturity ladder, not a rivalry. Start with the graph you already have, because it costs nothing and it is readable by you and your agent today. Graduate to a managed graph store when you hit cross-graph queries, scale, schema enforcement, or concurrency. The markdown vault is where the pattern begins, and often where it is entirely sufficient. It is a deliberate choice for the stage you are at, not a lesser version of the “real” thing.

If You’re Running This on AWS

The pattern is tool-agnostic, but here is where each rung lands if you build on AWS, and it follows the same ladder.

StageWhat it looks likeAWS service
The graph you already haveA linked markdown vault an agent traversesFiles in Amazon S3; the agent reads and walks links
Managed semantic memoryRetrieve structured knowledge to ground answersAmazon Bedrock Knowledge Bases, with a GraphRAG option backed by Amazon Neptune Analytics [7]
A real graph databaseCross-graph queries, enforced relationships, scaleAmazon Neptune (property graph or RDF, with openCypher / Gremlin / SPARQL) [8]
An org-wide governed graphAuto-mapped relationships, agentic search, identity-aware, shared across many agentsAWS Context — announced at the NYC Summit, coming soon [10]
Managed agent memoryShort-term and long-term memory as a serviceAmazon Bedrock AgentCore Memory [9]

The shape is identical to the vault story: structured knowledge the agent reads to reason, traversed by relationships rather than flattened into one prompt. You move up the rungs when the volume of data, the query complexity, or the number of readers forces you to, not before.

AWS leaned into this exact ladder at the New York Summit. AWS Context (announced, coming soon) automatically maps your existing data into a governed, identity-aware knowledge graph with agentic search, and it frames the jump the way I just did: it extends what began as a personal knowledge graph inside Amazon Quick into a shared organizational one [10]. It even rhymes with the rest of this series, since the graph is designed to learn from how your agents use it, ranking the sources and join paths that actually produce good answers. Personal vault, organizational graph: the same idea at a different scale.

The Takeaway

You do not need to stand up a graph database to give an agent a knowledge graph. If you keep linked, tagged notes, you already maintain one, and the structure you added for your own benefit is the structure your agent traverses. The links are edges. The frontmatter is properties. The folders are namespaces. Seale’s six-month experiment and the agent-memory taxonomy point at the same conclusion from different directions: structured markdown is a working semantic memory, and the graph database is the upgrade you grow into, not the entry fee.

So before you reach for Neptune or Neo4j, open your notes and ask: is this already the graph I was about to go build? And when you wire an agent to it, what would it find if it started at one note and just followed the links?

Sources

#KnowledgeGraph #AgentMemory #Obsidian #AgenticAI #ContextEngineering

Stefan Christoph

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

🎬 Also available as a blog walkthrough video on YouTube

❤️ Created with the support of AI (Kiro)