What survives the chat

A while ago I wrote an essay called "Every agent dies when you close the chat." It was about a condition: AI conversations don't persist, and the things you figure out inside them tend to die with the session. The essay diagnosed the trace I wished existed, the kind of receipt that would let next week's me read what last week's me learned. I didn't say what I was doing about it, partly because I wasn't sure yet. I'm a little surer now, so this is that piece.

I want to be careful about overclaiming. What I've been testing isn't a solution to the condition. The agent still dies when I close the chat; that hasn't changed. What's changed, for me, is what survives.

The Obsidian-shaped answer

The closest thing to what I wanted was Obsidian. A folder of markdown notes, backlinks between them, plugins, a community of people who think about this. I tried it. I keep some notes there still. What it didn't do for me is the part I most wanted: be readable by the next AI session in a way the AI could actually navigate.

Obsidian is markdown plus backlinks. That works beautifully for human reading: you wander, you follow a link, you discover. It's the digital garden shape. What it isn't is a typed graph. There's no schema for what a node is, no relations beyond "this links to that," no way to ask "show me all the open decisions" or "what protocols apply to system X." The graph is undifferentiated. For me, working with it, every search felt like I was hoping the AI would intuit what I meant.

I wanted something with a little more shape. Lighter than wikis (so I'd actually write the notes). More typed than markdown-with-backlinks (so the AI could traverse them with intent). Readable from the next session without my having to remember which file it was in.

Schema and traversal

For the last few months I've been keeping notes in a small typed graph. Each note is a plain markdown file with a YAML frontmatter: a type (decision, problem, system, convention, intent, and a few others), an id, a one-line description, and optional named connections to other nodes. The files sit in a folder. No database, no service, no index to rebuild.

The two pieces that change the experience: types and relations. Types mean a node is something specific — a decision is a different shape than a problem, and the AI knows the difference. Relations mean the connections between nodes carry meaning — `applies_to`, `motivated_by`, `belongs_to`, not just an unmarked link. In a markdown-and-backlinks tool, the graph is undifferentiated and the AI has to guess what it's looking at. With types and named relations, the AI can ask precisely: list all the open decisions, show me the protocols that apply to this system, walk the motivation chain from this intent up to the goal it serves.

The piece that makes the whole thing land is the small MCP server in front of the graph. The next AI session can search it, traverse it, list nodes of a type. When I ask something I've already thought about, the past thinking surfaces without my having to remember it's there. I don't recall the filename. I don't even recall that I once wrote about this at all. The model finds it because it knows what shape to look for.

The curator pattern

One thing I want to flag, because it changes the texture of the practice: the AI doesn't write into the graph. It proposes. There's a `propose_node` tool that drops a candidate node into an inbox; I review it later and accept, edit, or reject. The AI never mutates the graph directly.

This sounds like a small detail and it isn't. Letting an AI write freely into your long-term memory means your memory drifts toward whatever the model is confident about, which isn't always what you'd have written. Curation keeps me in the loop where it matters, and keeps the graph mine. It's slower. It's also the reason I trust the graph six months in.

The part that surprises me

The recursive thing is what I keep coming back to. Paperworlds itself is documented in this graph. The tools are nodes. The decisions are nodes. The conventions, the open problems, the things I'm intentionally not building yet, all nodes. When I write a new post, I add entries for any new terms it introduces. When I change my mind about a design choice, the old node gets a status change and the new reasoning gets its own node next to it. The project documents itself in its own tool. I didn't plan it that way; it just kept being the easiest place to put each thing.

The compound effect, after a few months, is that conversations start somewhere different. I'm not re-explaining the project to myself every time I open a session. The model has read the relevant nodes before it answers. The session begins already informed.

The engine and the fuel

Honest moment. The graph isn't as useful as the structure suggests it could be, and the reason is density. I ran an audit recently: 626 nodes, 596 edges, 0.95 edges per node. Sounds healthy. The shape underneath is less so. Twenty-six percent of the nodes are isolated, with no edges to anything else — captured fast, never wired to a parent. The decisions count, the place where rationale behind choices should accumulate, sits at twelve. For a graph that's been growing for months, that's low.

Translated: I have a catalogue, not a network. The schema and the traversal work. The fuel they need to be useful — the wired connections, the decision rationales that should compound across sessions — I haven't written enough of either. The engine exists; the tank is mostly empty in the ways that matter most for the use case I care about.

I'm calling this out because it's the part most easily missed when reading about a tool like this. The architecture is the easy part. The practice of capturing the right kinds of nodes consistently, and wiring them to the rest of the graph as you go, is the hard part. The audit was the first time I had numbers on that gap.

What I don't know yet

I don't know if this scales past a single author. The practice depends on me writing nodes consistently, and consistency depends on the friction staying low. If two more people were adding nodes, the graph would need conventions I haven't worked out. If I stopped writing nodes for a month, the graph would still be useful but wouldn't grow, and conversations would slowly drift back to flat-in-time.

I also don't know if the YAML-and-markdown shape is the right one. It's the shape that has the lowest friction for me right now. Something denser might be better long-term. Something sparser might survive my own attention drops better. I'm not sure.

What's working, hedged

What I can say is narrower than a recommendation. When I'm in a session now, the things I noticed in earlier sessions are accessible to the model without my effort. The conversation isn't flat in time anymore. The patterns that took weeks to emerge are visible without my having to remember them. The "every agent dies" condition is still real; it just lands differently when there's something the next agent can read.

That's the small thing I'm testing. The thing the previous post was teasing. A graph that's mostly mine, written slowly, read constantly.

The follow-up I want to write next is about two things: how I ended up testing this instead of going to Obsidian like most people would (and a little on tool discovery in AI generally — the recommendation surface is narrow, and the tools that fit your specific case are often the ones nobody reposts), and what a structured ingest sprint looks like to take this graph from catalogue to network. Numbers before, numbers after. Coming once I've done it.