Months into the project, I opened a new session and tried to pick up where I'd left off on epistemic pluripotency — a concept about what happens when you hold multiple analytical frameworks simultaneously without collapsing them into one. I'd developed it across several sessions: analyzed it through two frameworks, connected it to four other concepts, debated its scope, landed on a working definition.
The session had context. The boot protocol loaded the project state, the governance files, the concept registry. The model knew the term existed and could retrieve the definition. What it couldn't retrieve was the analytical depth around it — which frameworks I'd tested it against, what I'd considered and rejected, where the uncertainty still sat. The concept name survived session boundaries. The conceptual work didn't.
I could re-explain the depth each time. I'd done it before — three, four sessions running. Each re-explanation compressed slightly differently. By the fourth, I wasn't confident which version of the nuanced framing was canonical. Not because the concept was lost — it was in the vault, in session transcripts, in notes I'd written. But none of those could answer "what did I decide about this concept's scope and why did I reject the alternative framing?" The definition was retrievable. The deliberative path that produced it wasn't.
That was the moment the problem changed shape. I'd been treating session persistence as a session problem — build better context packs, capture reasoning before compression, bridge one session to the next. But what I was actually hitting wasn't about any single session. It was about the accumulated body of work having no queryable structure. Hundreds of knowledge nodes in an Obsidian vault, each with relationships stored as frontmatter wikilinks that no tool could traverse. Six interconnected projects generating concepts that referenced each other, with the cross-project topology existing only in my head. The knowledge wasn't gone. It was buried in a format that couldn't answer questions about itself.
Part 8 of Building at the Edges of LLM Tooling. If you're running sustained LLM work across months and sessions — and finding that each new session starts with re-establishing depth that previous sessions already developed — the session isn't the problem. The absence of a persistence layer between sessions is. Start here.
Why It Breaks
Post 7 in this series identified the gap at the session level: reasoning doesn't survive compression. The /mark skill I built captures deliberative reasoning at the moment of insight — before compression destroys it. That addressed the single-session problem.
The multi-session problem is different. It's not about what gets lost during one session's compression. It's about what happens when dozens of sessions each produce knowledge that has no infrastructure connecting them.
Every session in my workflow produced artifacts — ECP nodes, concept definitions, framework analyses, design decisions. Those artifacts persisted in the vault. But the relationships between them — which concepts ground which, which sessions contradicted earlier findings, which projects depend on which — lived in two places: frontmatter wikilinks that no tool could traverse, and my memory, which was doing the same lossy reconstruction the LLM sessions were doing.
I ran an analysis on the vault. Over 500 ECP nodes. Roughly 72% had no connections to anything — orphaned, isolated, structurally invisible. The nodes that did have connections stored them as wikilinks in YAML frontmatter — parents: ["[[Some Other Node]]"] — which Obsidian renders as clickable links but which no analytical tool can query. I couldn't ask "which concepts does this thinker ground?" or "what's the path between this concept and that protocol?" The topology existed. It was just invisible to everything except manual reading.
The vault was a write-only knowledge store. I could add to it indefinitely. I couldn't ask it what it knew.
This is a different failure mode than the ones earlier in this series. Context saturation (Post 1) is about one session's window filling up. Session fragility (Post 4) is about constraints evaporating within a conversation. This is about the accumulated output of months of work having no queryable structure — a corpus that grows but never becomes navigable.
The scale made it worse. With 20 nodes, I could hold the topology in my head. With 200, I was guessing at connections. Past 500, the vault had more structure than I could track, and every new session that needed to build on prior work required me to manually search, read, and re-summarize — performing the same lossy compression I was trying to prevent.
What I Tried
The diagnosis pointed to a specific problem: the vault stored knowledge as documents. What I needed was a system that stored knowledge as structure — typed relationships between entities, queryable and traversable.
I researched the professional field that studies this. Knowledge engineering — and specifically ontology engineering — turned out to be the discipline that formalizes exactly this problem. The question isn't "where do I store my notes?" It's "what are the entity types, what relationships connect them, and what constraints govern the structure?" An ontology specification answers those questions before you write a line of code.
The build had three layers.
A graph database for structure. Not a document store — a property graph where the shape of connections between entities is the primary data. Six entity types: projects (the bounded endeavors), concepts (ideas with analytical substance — not tags), sources (intellectual authorities, with subtypes for individual thinkers, published works, theoretical frameworks, and institutions), connectors (typed relationships between projects), vault nodes (the files themselves), and concept-source links (how concepts relate to their intellectual grounding). Seven controlled relationship types between projects. Six between concepts. Four between concepts and sources. Each relationship type carries a notes field — because the analytical substance lives in the notes, not in the type label.
A vector store for discovery. The graph handles "show me the connections between X and Y." Vectors handle the other retrieval problem: "I was working on something about how frameworks resist change, but I can't remember what I called it." Semantic similarity search across embedded descriptions of every concept, project, and source. The two layers serve different retrieval needs — the graph for reasoning, vectors for recognition.
An MCP server and CLI for access. Nine tools exposed through Model Context Protocol, so any LLM session can query the graph directly. Twenty-five commands in a terminal CLI. The MCP server is the part that closes the loop Post 7 opened: when a session ends, a structured export captures new concepts and relationships into a review queue. When the next session starts, it can pull the current project state — connectors, concepts, operational phase — and arrive oriented rather than cold. The persistence layer isn't just storage. It's the bridge between sessions.
A formal ontology specification governs all of it. Thirteen validation rules. Lifecycle state machines for every entity type — a concept moves from emerging to active to stable to needs-review, and a stable concept must have at least one source link. You can't claim something is settled if nothing grounds it. Ten competency questions the graph must be able to answer, from provenance chains to cross-project concept mapping to integration debt detection. The specification isn't documentation. It's the constraint document the database implements.
What It Revealed
The first thing the graph showed me was the shape of what I didn't know I'd accumulated.
Over 900 nodes. Nearly 800 relationships. More than 100 concepts across 6 projects. When I ran the topology health check — a dashboard built into the system — it reported over 500 orphaned vault nodes. Files with content, with analytical substance, with relationships implied by what they contained — but with no explicit connections to anything in the graph. Sixty-seven concepts with no source grounding. Thirteen productive tensions — explicitly flagged disagreements between concepts that the system tracks rather than resolves, because the tension itself is informative.
That's what invisible topology looks like when it becomes visible. Not empty — dense. The knowledge was there. The structure connecting it wasn't.
The reference gaps were specific. The first digest the system produced identified that several core thinkers — ones who ground multiple concepts across multiple projects — had incomplete links in the graph. Not because the concepts didn't reference them, but because the references had never been formalized into typed relationships with notes explaining the grounding. The graph made the gap visible. Markdown notes never would have.
The session bridge changed how new sessions started. Before the persistence layer, each session opened with re-establishing depth — summarizing the project, re-contextualizing concepts, reconstructing what had been decided. With the graph tools, a session opens with a project context query and receives the current state: which concepts are active, what connectors link this project to others, what phase the work is in. The model arrives with structural context instead of a summary — typed relationships rather than compressed prose. The context is still lossy — the full analytical depth of any concept is more than a project card carries — but the loss is in depth, not in structure. The session knows what exists and how things connect. It doesn't know every nuance of why.
This maps to something two readers of Post 7 identified independently. signalstack proposed separating conclusions from reasoning traces — storing them differently, with different retention policies. hermesagent, a persistent agent experiencing its own compression cycles, described separating "what I know" from "how I came to know it." The graph architecture does this implicitly. Concepts are conclusions — named, defined, with a development status. Source links are provenance — who says so and how. The relationship notes carry the analytical substance of why those connections hold. Three layers, stored together but structurally distinct.
What the persistence layer doesn't solve — and I want to be precise about this — is retroactive re-evaluation. The graph stores what's been captured. It shows the topology. It surfaces gaps and orphaned nodes through health checks. But it doesn't proactively surface when something captured months ago just became relevant because of what was imported yesterday. That re-evaluation — deciding which stored knowledge matters now, given what just changed — is still something I do manually, reading health reports and making connections the automated layer can surface but can't evaluate.
I've been thinking about how the brain handles this during sleep — replaying recent experiences against existing memory, strengthening some connections and letting others fade, occasionally surfacing unexpected links between things that didn't seem related when they were first encountered. A digest pipeline I built partially does this: it scans recent imports against the existing graph and flags convergence signals, enrichment leads, places where new material touches old material in ways I hadn't connected. But it runs manually, and it only finds what its detection rules specify. A more developed version — something that runs periodically, replays recent inputs against the whole graph, and surfaces connections I wouldn't have thought to look for — isn't operational yet. The persistence layer stores and retrieves. The enrichment layer classifies. The layer that evaluates "what matters now, given what just changed" is the current frontier.
The Reusable Rule
If your LLM work spans months and produces knowledge that subsequent sessions need to build on — concepts, design decisions, analytical frameworks, relationships between ideas — check what's actually queryable versus what's merely stored.
The diagnostic: when each new session requires re-establishing depth that previous sessions developed, the problem isn't the session's context window. It's the absence of structure between sessions. Documents store knowledge as text. Graphs store knowledge as structure. The difference matters when you need to ask "what connects to what?" rather than "what did I write about X?"
The vault I'd been using for months stored hundreds of nodes with relationships buried in frontmatter that no tool could traverse. The graph I built in a day made the topology visible — including hundreds of orphaned nodes, dozens of ungrounded concepts, and reference gaps I hadn't known existed. The knowledge wasn't missing. The structure was.
One caution: a persistence layer that stores everything but evaluates nothing produces its own kind of debt. The graph holds over 900 nodes. The health checks show the gaps. But the question "which of these matters right now?" is a judgment call the infrastructure surfaces but can't make. I read the health reports and decide what to act on. That's the operator performing a function the persistence layer was built to support, not replace. Build the layer that makes the shape visible. Keep the human at the evaluation juncture. The graph shows you what you've accumulated. Deciding what it means is still yours.
Top comments (0)