Your Obsidian Vault Is a Knowledge Graph

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

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, a links-to edge; the prose around the link often hints at how, though nothing makes that machine-readable.
• 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, by convention: customers/, meetings/, research/ tell you what kind of note to expect before you read a word of it, for as long as you keep the filing discipline.

That is a graph. Not a metaphor for one, the triples are there, this-note, links-to, that-note, with node types in the frontmatter. Be precise about which kind, though: this is a property graph, and its edges are mostly untyped. A wikilink asserts that two notes are related, not how they are related; the surrounding prose sometimes names the relation, but nothing captures that in the link itself. So it is a knowledge graph in the working sense, and the word semantic is earned only where your own conventions supply typed relations consistently enough to rely on.

An ontology and a query engine are the obvious gaps compared with a formal store, and as I will get to, you do not always need either. They are not the only gaps. Stable identifiers (rename a note and the identity moves with the filename), entity resolution, provenance, validation, and defined update semantics all come with a real store and are yours to maintain by convention here.

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].

Strictly, both halves are text, so the distinction is about what each half is good for rather than one of them being neural. The prose is unstructured: fuzzy, contextual, the kind of thing a language model absorbs and continues well, and the part you would struggle to query. The structure around it, the links and typed properties, is discrete and precise: the part you can follow deterministically with no model in the loop at all. Natural language is a good deal messier than subject-predicate-object, but where you do impose that shape, both readers can use it. Keeping both in one file means the fuzzy reader and the deterministic reader share a space instead of living in two systems you have to keep in sync.

That is the bridge people have chased for years, and Seale’s claim is that it turned out to be unglamorous. Worth being clear about what it is and is not: there is no symbolic inference here, no engine deriving new facts, so this is a shared substrate rather than a neuro-symbolic reasoning system. What you get is 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 [11], 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), though in practice a vault mixes types: a meeting note is an episode that also carries durable facts. Its center of gravity 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, and in practice the two cooperate: traversal selects the slice, the context window is where the slice lands. Complementary jobs, not competing ones.

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, and following links from a starting note will not answer it, the matches you want need not be reachable from wherever you began. You can still answer it by scanning: parse every note and every link, which is Θ(N+E) work for N notes and E links, and at vault scale that is a script and a few seconds. So what a graph database buys is not the possibility but the ergonomics and the economics, a declarative query language, indexes so you are not scanning at all, a planner, and operational guarantees.
• 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 gives you somewhere to hang enforcement, though most graph databases are schema-flexible by default, so strictness is something you configure or build on top, through the constraints the engine offers or a validation layer such as SHACL-style shapes for RDF, rather than something you get for free.
• Concurrent writers and transactions. A personal vault usually has one writer at a time, though sync clients, plugins, and agents can already collide on it, as anyone who has untangled a sync conflict knows. A shared graph serving many agents and services needs atomicity, isolation, and conflict handling that file conventions cannot provide, and that is what database transactions are for.

So the honest rule is a maturity ladder, not a rivalry. Start with the graph you already have: it adds no new service, no migration, and no separate bill, the parsing, the indexing, and the tokens your agent spends walking it are costs you are already paying, and it is readable by you and your agent today. Graduate to a dedicated graph store, managed, embedded, or self-hosted, 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.

The shape is identical to the vault story: structured knowledge the agent reads to reason, traversed by relationships to select what matters, with the selected slice then serialized into the model’s context, instead of flattening everything 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: AWS describes the graph as learning from how your agents use it, ranking the sources and join paths that produce good answers, the vendor’s description of a pre-release capability, not something anyone outside can measure yet. 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

• [1] Tony Seale, post on markdown wikis as agent knowledge graphs, LinkedIn, June 2026. https://www.linkedin.com/posts/tonyseale_for-the-last-six-months-i-have-barely-opened-share-7476011283620859904-z873/, the neuro-symbolic framing this post builds on: markdown as both the fuzzy and, with structure, the precise representation.
• [2] Cole Stryker, “What is AI agent memory?”, IBM Think. https://www.ibm.com/think/topics/ai-agent-memory, semantic memory as structured factual knowledge implemented with knowledge bases, symbolic AI, or vector embeddings; draws on the CoALA paper.
• [3] Stefan Christoph, “Is RAG Still Needed with 1M+ Token Context Windows?” https://schristoph.online/blog/is-rag-still-needed/, the prior exploration of agent memory beyond RAG vs long context.
• [4] Stefan Christoph, “Your Agent’s Skills Are Bounded Contexts (Design Them Like It).” https://schristoph.online/blog/agent-skills-are-bounded-contexts/, consistent vocabulary inside a boundary, the design discipline behind a clean graph.
• [5] Stefan Christoph, “Architecting Skills: How Code Makes AI Agents More Reliable Over Time.” https://schristoph.online/blog/architecting-skills-reliability/, structure where structure pays off.
• [6] Stefan Christoph, “Making My Website AI-Agent Friendly.” https://schristoph.online/blog/making-website-ai-agent-friendly/, structuring content so agents can read and traverse it.
• [7] Amazon Bedrock Knowledge Bases, GraphRAG with Neptune Analytics. https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build-graphs-build.html, fully managed GraphRAG integrated into Bedrock Knowledge Bases, using Amazon Neptune Analytics for graph and vector storage.
• [8] Amazon Neptune. https://aws.amazon.com/neptune/, managed graph database supporting property graph and RDF with openCypher, Gremlin, and SPARQL.
• [9] Amazon Bedrock AgentCore. https://aws.amazon.com/bedrock/agentcore/, managed primitives for production agents, including short- and long-term Memory.
• [10] Mai-Lan Tomsen Bukovec, “Context intelligence for your data and AI agents at scale,” AWS Machine Learning Blog, 17 Jun 2026. https://aws.amazon.com/blogs/machine-learning/context-intelligence-for-your-data-and-ai-agents-at-scale/, AWS Context (coming soon): automatically maps your data into a governed, identity-aware knowledge graph with agentic search, extending Amazon Quick’s personal knowledge graph into an organizational one.
• [11] Theodore R. Sumers, Shunyu Yao, Karthik Narasimhan, Thomas L. Griffiths, “Cognitive Architectures for Language Agents” (CoALA), arXiv:2309.02427 / TMLR. https://arxiv.org/abs/2309.02427, the framework behind the memory taxonomy: language agents with modular memory components.

#KnowledgeGraph #AgentMemory #Obsidian #AgenticAI #ContextEngineering

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 →

• KnowledgeGraph
• AgentMemory
• Obsidian
• AgenticAI
• ContextEngineering