Daniel's been watching the conversation around AI memory shift from something pretty tactical — Karpathy's Obsidian and Markdown hack for giving agents a lightweight memory layer — into something people are now calling graph engineering. He wants to know what that actually means in practice. Not the theory, the mechanism. How do you go from a folder full of Markdown files to a system that surfaces connections nobody explicitly wrote down? What's genuinely new here versus conventional retrieval, why is this attracting so much interest right now, and what might it unlock that other approaches don't?
And the timing's interesting, because this went from a neat pattern people were sharing on Twitter to a named discipline in, what, six weeks? MarkTechPost ran a piece at the end of July framing it as the third phase — prompt engineering, then loop engineering, then graph engineering. And Josh Simmons published a whole essay arguing we're moving from engineering prompts to engineering the structure of knowledge itself. That's not a tweak. That's a category claim.
So let's start with what Karpathy actually showed us, and where the community has taken it. Because the origin story here matters for understanding why the graph part became the interesting part.
Right. So Karpathy's original pattern was almost embarrassingly simple. You maintain a folder of Markdown files — your notes, your project docs, your thinking-in-progress — and when you fire up an AI agent, you point it at that folder as its context. The agent reads the relevant notes and suddenly it knows what you're working on, who you're talking to, what you decided last week. It's a second brain, but the second brain isn't for you — it's for the agent.
And the key word there is "relevant." The agent isn't reading your entire folder. It's pulling the files that match whatever you're asking about. At that stage, it's basically a file picker with a search bar.
And that's where the community started iterating. People began linking their notes together — Obsidian's whole thing is bi-directional links, so if Note A links to Note B, Note B automatically shows a backlink to Note A. And once you've got a few hundred notes linked like that, something interesting happens. The structure itself starts carrying information that isn't in any single file.
This is the part where I think the word "graph" starts meaning something, not just being a metaphor. Walk me through what's actually happening under the hood when you've got linked Markdown files versus a flat collection.
So imagine three notes. One's about a project deadline — the Q-three launch is slipping to October. One's about a person — Miriam, who specializes in localization workflows. One's about a tool — a new translation management system your team's evaluating. None of these notes mention each other. They're in different folders, written weeks apart, by different people.
A vector search across these three notes is going to find... nothing. "Localization workflow" and "translation management system" might have some embedding proximity, but the deadline note is about calendars and milestones. Semantically, it's in a different neighborhood.
That's exactly the distinction. A flat vector store retrieves by similarity. You ask "who can help with the Q-three launch" and it finds notes that talk about Q-three, launches, deadlines. It surfaces the deadline note. It might not surface Miriam, because Miriam's note doesn't mention Q-three or the launch. It talks about her expertise in localization.
But a graph retrieves by relationship. And if that deadline note links to a project overview note, and the project overview links to a team directory note, and the team directory links to Miriam...
The graph traversal follows the path. It doesn't need semantic similarity between the query and Miriam's note. It just needs structural proximity — they're connected through intermediate nodes. The agent can surface "this person has relevant expertise and appears to be available during the relevant window" without anyone ever having written that sentence down.
That's the leap from memory to discovery. Memory answers "what did I record about this." Discovery answers "what's connected to this that I didn't think to record."
And this is where Simmons's framing gets really useful. He argues we've been through two phases. Prompt engineering was about learning to talk to the model — what words, what structure, what examples produce the best output. Loop engineering was about giving the model agency — letting it plan, execute, observe results, and iterate. Graph engineering is about something different. It's about engineering the knowledge substrate the model reasons over.
So the prompt is the question, the loop is the process, and the graph is... the world model? The thing the agent consults to understand what's true and what's related?
That's the claim. And I think it's mostly right, with one important caveat. The graph isn't a world model in the sense of being a complete representation of reality. It's a curated, partial, structured representation of the specific domain the agent operates in. Your project, your team, your company's knowledge. The quality of the agent's reasoning becomes a function of how well that graph captures the actual relationships in your world.
Garbage graph, garbage reasoning.
Worse than garbage reasoning, actually. A bad graph actively misleads. If the graph says Miriam reports to David, but she actually reports to Sarah, the agent routes tasks to the wrong person, escalates to the wrong manager, and makes decisions based on an org chart that doesn't exist. A flat vector store that fails to retrieve something just... misses it. A graph that's wrong produces confident, structured, path-based errors that look plausible.
So there's a curation cost here that doesn't exist with simpler approaches. Which makes me wonder — when does this actually pay off? When is graph engineering the right tool versus just using a vector database and calling it a day?
The short answer is: when the value comes from connections rather than content. If you're building a customer support bot that needs to answer "how do I reset my password," a vector store over your help docs is perfect. The answer is in one document, the query is semantically similar to that document, done.
Right. Nobody needs a knowledge graph to find the password reset page.
But if you're trying to answer "we're seeing unusual churn in our European enterprise accounts, what's going on," that answer isn't in any single document. It might be at the intersection of a pricing change note from six months ago, a competitor's product launch, a support ticket spike about a specific feature, and a regional manager who left in March.
None of those documents mention each other, and none of them contain the word "churn." A vector search fails. A graph traversal across linked documents — where the pricing change links to the product roadmap, and the roadmap links to the competitor analysis, and the competitor analysis links to the regional structure — can surface the pattern.
That's the serendipity-by-design idea. A flat memory answers what you ask. A graph can surface what you didn't know to ask. And that's not just a nice-to-have. For certain classes of problems — strategy, research, innovation, diagnosis — it's the whole game.
So let's talk about who's actually building this, because it's easy to describe the ideal and harder to point at something real. The research Daniel sent over mentions something called the Caesar Framework from Cognizant.
Yeah, this is the proof that graph engineering is leaving the personal-notes world and entering enterprise. Cognizant's AI lab built Caesar explicitly for idea generation through graph-based discovery. The premise is that innovation comes from connecting previously disconnected ideas — which is a thing people have been saying forever, but Caesar operationalizes it. It ingests research papers, market data, internal expertise documents, patent filings, and builds a graph that links concepts across domains.
And then what — you ask it for product ideas and it traverses the graph looking for unlikely neighbors?
Essentially, yes. It identifies concepts that are structurally close in the graph but semantically distant — they're connected through intermediate nodes but don't obviously belong together. A materials science paper about self-healing polymers, a market report about aging water infrastructure, and an internal doc about your company's sensor technology. None of these mention each other. But the graph connects them through shared concepts — "degradation detection," "distributed monitoring" — and suddenly there's a product idea: self-reporting pipes that signal when they need maintenance.
That's a non-obvious connection. No one on the team would have sat down and said "let me read about polymers and water pipes and see what happens." The graph did the serendipity for them.
And this gets at why the timing matters. Three things converged to make this possible right now. First, context windows are still finite — they're bigger than they were, but you can't dump an entire company's knowledge into a prompt. External memory still matters. Second, LLMs are now good enough at entity extraction and relationship detection that you can build these graphs from unstructured text without an army of annotators. The model reads the documents, identifies the entities, proposes the links.
That's the piece that wasn't true two years ago. Building a knowledge graph used to require ontologists and taxonomists and months of manual work. Now an LLM can do a decent first pass in hours.
And third, the tooling got cheap. Graph databases used to be exotic. Now you've got Neo4j's community edition, you've got embedding models that are basically free, you've got orchestration frameworks that handle the pipeline. The barrier to entry collapsed.
So we've got the mechanism, we've got the enterprise use case, we've got the why-now. What breaks? Where does this fall apart in practice?
A few places. The obvious one is maintenance. A graph is a living thing — or it needs to be. People leave, projects end, tools change. If nobody updates the graph, it drifts. And a stale graph is worse than no graph, because it produces confident wrong answers instead of admitting ignorance.
The second thing that worries me is the bootstrap problem. You need a certain density of nodes and links before the traversal starts producing useful serendipity. Below that threshold, you've just got a very expensive file system.
That's right. The first hundred notes in your Obsidian vault — you're not discovering anything. You're just... taking notes. The graph effects kick in somewhere in the thousands, when the probability that two unrelated notes share an intermediate node becomes non-trivial.
And most teams won't get to thousands. They'll get to eighty-seven and wonder why the graph isn't magically generating insights.
There's also a bias problem that I don't think gets enough attention. When you build a graph, you're making decisions about what counts as a node and what counts as a link. Those decisions encode assumptions. If your entity extraction model consistently misses certain types of relationships — say, informal mentorship connections that don't appear on org charts — your graph will systematically undervalue those pathways. The agent will reason as if they don't exist.
So the graph doesn't just reflect the biases in your documents. It amplifies them by making them structural. A biased vector store retrieves biased documents. A biased graph builds biased reasoning paths.
Those paths feel authoritative because they're explicit. You can trace them. "The agent recommended Miriam because she's linked to the localization node through the Q-three project graph." That traceability is a feature — it's one of the things that makes graph-based reasoning more auditable than a black-box embedding similarity score. But it also makes the errors more persuasive. A wrong path looks just as traceable as a right one.
Which brings us back to curation. The bottleneck shifts from retrieval quality to graph quality. And graph quality is a human judgment problem, not a compute problem.
That's the honest limitation here. Graph engineering is not a universal replacement for vector search. For simple Q-and-A, for fact lookup, for "find me the document that says X" — use a vector store. It's faster, it's cheaper, it's simpler. Graph engineering is for a specific class of problems: discovery, synthesis, planning, diagnosis. Problems where the answer isn't in any one document, but lives in the space between documents.
If I'm hearing you right, the real shift here isn't technical — it's conceptual. We're moving from "how do I store what I know so an AI can find it" to "how do I structure what I know so an AI can reason about it."
That's the Simmons argument in a sentence. And I think it's right, with the caveat that most use cases still don't need it. The password reset bot doesn't need a graph. But the strategy advisor, the research assistant, the diagnostic system — those do.
What about the personal knowledge management side of this? Daniel's prompt started with Karpathy and Obsidian — the individual use case. Does graph engineering scale down, or is this inherently a team or enterprise thing?
It scales down, but the value proposition changes. For an individual, the graph is mostly about memory augmentation — surfacing connections you've forgotten you made. You read a paper six months ago, you wrote a note about it, you linked it to a project that's now relevant again. The graph reminds you that connection exists. That's useful, but it's not the same as the Caesar Framework generating novel product ideas from enterprise-scale knowledge.
The individual version is "oh right, I already thought about this." The enterprise version is "nobody has ever thought about this, but the graph just assembled it."
Both are valuable, but the second one is what's driving the excitement. Because it promises something that conventional search has never been able to do — find answers to questions you haven't formulated yet.
Alright, Hilbert. You've been quiet back there — and I have a feeling you've seen something like this before.
Hilbert: Nineteen ninety-seven. Consulting firm in Boston. We had a whole wall — floor to ceiling whiteboard, maybe thirty feet long. Index cards, colored string, pushpins. Every project got a card. Every person got a card. Every client got a card. String meant a relationship — worked on, reported to, contracted with. Different colors for different relationship types. Took three of us a weekend to set up.
A physical knowledge graph. On a wall.
Hilbert: Called it the Nexus. Very proud of the name.
How long did it last?
Hilbert: Worked brilliantly for about six weeks. You could stand at the wall and trace a path from a client problem to a consultant who'd solved something similar three years ago at a different firm. People would come by and just... stare at it. Found connections they didn't know existed.
And then?
Hilbert: People stopped updating it. Someone would leave the firm, their card stayed up. Project would end, string stayed. New client would come in, nobody added them. After about four months it was a monument to the company as it had been in March.
It became actively misleading.
Hilbert: There was one moment, though. About two months in. We had a consultant, Elaine, working on a supply chain problem for a manufacturing client. And someone was standing at the wall and noticed — Elaine's card was connected to a project from five years earlier, and that project was connected to the same client through a different division. She'd worked on basically the same problem for the same company and nobody in the room knew it, including Elaine. She'd forgotten.
The graph didn't forget.
Hilbert: That one connection saved them about six weeks of work. The partner kept the wall funded for another year based on that single win. Even after it was useless.
Even a broken graph can occasionally outperform no graph.
Hilbert: The question isn't whether it works. The question is whether anyone will do the work to keep it working. That was true in ninety-seven with string and pushpins, and I don't see why it would be different now.
The difference now is that a lot of the maintenance can be automated. The LLM can scan new documents, propose new nodes, flag stale connections. It's not perfect, but it's not three people and a weekend.
Hilbert: Someone still has to decide. The model proposes, but someone has to accept. That's the part that breaks. Not the technology. The discipline.
What happened to the wall?
Hilbert: Painted over in two thousand one. I kept one of the index cards. It's in a box somewhere.
Whose card?
Hilbert: Mine.
I have so many follow-up questions and I'm going to save all of them.
The ownership question is the one that sticks with me. If the graph becomes the substrate for agent reasoning — if the quality of the agent's thinking depends on the quality of the graph — then who owns the graph becomes a very high-stakes question. Is it your graph, running on your infrastructure, curated by your team? Or is it the platform's graph, where your documents are just nodes in their much larger structure, and the insights the agent surfaces are partly derived from connections to other companies' data?
That's the enterprise version of the same question people are asking about personal AI. If your agent's memory lives in the model provider's cloud, and the model provider is also running graph engineering across millions of users' notes, whose insights are those?
The answer right now is: it depends on the architecture. If you're running a local Obsidian vault with local models doing the entity extraction and link suggestion, it's yours. If you're using a hosted service that ingests your documents into a shared graph... it's complicated.
The next phase after graph engineering might be graph self-maintenance — agents that don't just reason over the graph but actively maintain it. Detect stale nodes, propose new links, prune dead branches, flag contradictions. The graph becomes a living system that the agent tends, rather than a static structure that humans have to keep updating.
That's where the loop engineering and graph engineering phases merge, actually. You give the agent a loop — observe, plan, act, reflect — and one of the things it can act on is the graph itself. It reads a new document, extracts entities, proposes links, checks for consistency with existing nodes, surfaces conflicts for human review.
The curation bottleneck doesn't go away, but it moves. Instead of humans doing all the maintenance, humans review the agent's proposed maintenance. Still work, but different work.
More scalable work. One person can review a hundred proposed link changes in the time it takes to manually create ten.
Where does this leave us? Daniel asked what's new, why the interest, what it enables. I think the answer is: graph engineering is new in the sense that it shifts the retrieval paradigm from similarity to structure, and it's attracting interest because the tools finally exist to build these graphs without heroic effort. What it enables is a class of AI application that doesn't just answer questions — it discovers questions worth asking.
The most interesting systems won't be the ones with the best models. They'll be the ones with the best-connected knowledge. The model is the engine, but the graph is the map. And a great engine with a bad map just gets you lost faster.
This has been My Weird Prompts. Thanks to our producer, Hilbert Flumingtop, who apparently has an index card with his own name on it in a box somewhere and is not going to elaborate.
If you want to send us a prompt — about graph engineering, AI memory, or anything else — email the show at show at my weird prompts dot com. Or find us at my weird prompts dot com.
We'll be back soon.
