Appearance
What Is a Personal Knowledge Engine? Notes That Work for You and Your Agents
Your notes now have two readers: you, and the AI agents you work with. A personal knowledge engine is built for both of them — and it has to remember which parts of your knowledge you decided, and which parts it only worked out.
You open a new session with an AI agent on a project you have been thinking about for four months. It is fast, it is capable, and unless you tell it, it knows nothing about those four months.
So you tell it. You paste in the three notes you can find. You summarize the rest from memory. You explain the decision you made in June, and why, and the thing you tried in July that did not work. Twenty minutes later the agent is genuinely useful. Tomorrow you will open a new session and do it all again.
There is an older version of the same problem, and you have probably met it too. Six months ago you researched a question, compared a few approaches and made a decision. You kept the articles, the meeting notes and your reasoning. Today the question comes back in a slightly different form. You remember doing the work. You can even find the folder. But putting back together what you learned takes long enough that starting over feels easier.
These are one problem, not two. The thinking you did exists, but not in a form that anything can pick up and continue from. For most of the history of note-taking, the only thing that ever had to pick it up was you. Now there is a second reader: tireless, quick, and starting from zero every time you open it.
Andrej Karpathy put the second half of this bluntly in a note he published in April 2026. Describing how most people point a language model at their documents — upload the files, let the model retrieve relevant chunks when you ask something, generate an answer — he wrote:
This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation.
No accumulation is the whole complaint, and it applies to both readers. Nothing you concluded last time is waiting for you this time. Nothing your agent worked out yesterday is waiting for it today.
The name that has started to attach itself to the fix is personal knowledge engine. This article argues that the name is worth keeping, but only for a specific kind of system — one that divides the work correctly between you, the software, and your agents. Getting that division wrong, in either direction, is where the trouble starts.
What people mean by a personal knowledge engine
There is no settled definition yet, and the people using the phrase mean noticeably different things. Here are three recent uses, described as their authors describe them.
MyMemory is a product, and it uses the phrase for itself: "MyMemory is a personal knowledge engine — save links, notes, and conversations, then find them again when you need them." It pulls material in from places like Notion, X, Reddit, YouTube and a browser extension, lets you ask questions answered from what you saved, and runs an MCP server so that AI assistants — it names Cursor, Claude Desktop, Windsurf and VS Code — can use your saved knowledge directly.
Brian Wong's concept note, from May 2026, treats it as an architecture: "a hybrid AI architecture that bridges the gap between general-purpose world knowledge and an individual's unique personal context." One half is a web-connected language model, for reasoning, current events and general facts. The other is retrieval over a private, structured knowledge base — his example is an Obsidian vault. He describes agentic workflows, where the AI acts on what it retrieves, as the next step. And he adds a maintenance note: keeping a clean, linked and linted wiki "(like an LLM Wiki)" significantly improves the quality of retrieval compared to searching unstructured text.
Omid Farhang's version, from December 2025, is a working setup for engineers: Jupyter notebooks plus language models running on his own machine. A few Python functions crawl his project directory and feed the relevant interfaces and documentation into the model's context — "RAG for One", he calls it. The part he calls the killer feature is what happens next: the model's code runs in the next cell, and if it fails, the stack trace goes straight back to the model. "The LLM isn't just guessing; it's being held accountable by the Python kernel."
Read side by side, the three share a shape. Each puts a language model on top of material that belongs to one person. Each relies on retrieval to get the right part of that material in front of the model at the right moment. And two of the three reach outward, toward the agent side: MyMemory through its MCP server, Brian Wong by naming agentic workflows as where this goes next.
Brian Wong's maintenance note is the one worth pulling out, because it points at a question the architecture diagrams skip. Retrieval can only return what the knowledge base contains, in the shape it is kept in. A clean, linked wiki retrieves better than a pile of text. Someone has to make it clean and keep it linked.
That is the question the rest of this article is about. But first, a working definition.
For the purposes of this article, a personal knowledge engine is a system that keeps what you have learned in a form that both you and your AI agents can pick up and continue from — and that keeps track of which parts of it you decided and which parts it merely worked out.
The first clause is what the three uses above have in common. The second is my addition, and the argument for it is most of what follows.
None of this replaces personal knowledge management. When Jason Frand and Carol Hixon named that practice in 1999, they described it as "a strategy for transforming what might be random pieces of information into something that can be systematically applied and that expands our personal knowledge." That is still the job. An engine is what a personal knowledge management system has to become once the knowledge has a second reader — one that cannot ask you what you meant, and will not remember the answer if you tell it.
Which brings back Brian Wong's question. If the knowledge has to be kept clean, linked and current for both readers, who keeps it that way? There are, broadly, three answers on offer.
Who keeps the knowledge: three answers
Every system that tries to make your past thinking usable has to decide who does the work in between — the work of turning a pile of saved material into something that can be picked up and continued. Each of the three answers has real advocates and a real case, so this section describes each one the way its advocates do.
Answer one: nobody keeps it — retrieve it at the moment you ask
The most common answer today is retrieval-augmented generation, usually shortened to RAG. When you ask a question, the system searches your material for the passages most likely to matter, hands those passages to a language model along with your question, and the model writes an answer from them.
The standard reference is a 2020 paper by Patrick Lewis and colleagues, presented at NeurIPS, which introduced what it called RAG models. Its stated motivation is worth reading. Language models store a great deal of knowledge in their parameters, the paper says, but "providing provenance for their decisions and updating their world knowledge remain open research problems." Their answer was to pair the model with an explicit, separate memory it could search — in their case, an index of Wikipedia.
Applied to personal notes, the appeal is obvious. Nothing has to be maintained. Your notes stay the source of truth; change one and the next answer reflects the change. All three of the personal knowledge engines described above rely on some form of retrieval — MyMemory's answers "grounded in your memories", Brian Wong's local RAG over a vault, Omid Farhang's "RAG for One".
The objection is the one Karpathy made, quoted at the top of this article, and he spelled it out further in the same note:
Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up.
He names NotebookLM, ChatGPT file uploads and most RAG systems as working this way. And Brian Wong's maintenance note describes the same limit from the other side: what retrieval returns can only be as good as the shape the material is kept in.
Answer two: the model keeps it
Karpathy's own proposal, in the note he calls LLM Wiki, is to stop re-deriving and start compiling. Instead of retrieving from raw documents each time, a language model "incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources."
He describes three layers. Your raw sources — articles, papers, images, data — which the model reads but never modifies; "This is your source of truth." The wiki itself — summaries, entity pages, concept pages, comparisons, a synthesis — which "the LLM owns entirely." And a schema: a document that tells the model how the wiki is organized and what to do when a new source arrives, which you and the model refine together over time.
The division of labor is stated plainly:
You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions.
Three operations keep it alive. When you ingest a new source, the model reads it, discusses the key takeaways with you, writes a summary page, and updates the entity and concept pages it touches — "a single source might touch 10-15 wiki pages" — noting where new data contradicts old claims. When you query it, good answers can be "filed back into the wiki as new pages," so what you explore accumulates alongside what you read. And periodically you ask it to lint: look for contradictions, stale claims, orphan pages, and concepts that are mentioned but lack a page of their own.
Two details matter for what follows. First, Karpathy's own practice keeps him in the loop: he prefers to ingest sources one at a time and stay involved — reading the summaries, checking the updates, guiding the model on what to emphasize — while noting that you could batch-ingest with less supervision. Second, he is explicit about why he thinks it works:
The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. … Humans abandon wikis because the maintenance burden grows faster than the value.
The model does not get bored and does not forget to update a cross-reference, so the maintenance cost falls to nearly nothing. He closes the note by connecting it to Vannevar Bush's memex, the 1945 design for a personal store of documents joined by associative trails — a design this blog has looked at before. Bush's vision, Karpathy writes, was private and actively curated, with the connections as valuable as the documents: "The part he couldn't solve was who does the maintenance. The LLM handles that."
He also describes the note as "intentionally abstract": a pattern to hand to your own agent, not a specific implementation.
Answer three: you keep it
The oldest answer is that you do the work yourself. You write the note in your own words rather than filing the quotation. You make the link because you noticed the connection. You write the paragraph that says what the last nine notes add up to. It is the practice behind the card index, the Zettelkasten and most of what gets taught as personal knowledge management — and it is where this blog has spent most of its time, from developing concepts rather than managing notes to a six-step workflow that ends in exactly that kind of paragraph.
Its advocates' case is that the writing is the thinking. The paragraph you produce at the end is not a by-product of understanding something; it is how you come to understand it. And it is unambiguously yours. When you reread it in a year, you know who concluded it and roughly how sure they were.
Its weakness is the one the second answer was built to escape. Karpathy puts it in one line: the maintenance burden grows faster than the value. The 1999 paper that named personal knowledge management reached a similar place from the other end. Of the five skills its workshop taught, four came with concrete techniques, most of them borrowed from library science. For the fifth, the paper says:
The task of integrating and relating is left to the individual student.
— and then reports what a few students had tried.
Not three products, three places to put the work
These answers overlap in practice. Karpathy's wiki is still searched when you query it — through an index file at first and, once it grows, with a proper search engine over the pages. People who keep their own notes search them constantly, and can just as well hand them to a model to summarize. What distinguishes the three is not the technology. It is where the accumulated understanding lives, and who writes it.
That is what each approach says about itself. The rest of this article is what I make of them.
Two kinds of knowledge, and who should keep each
Put the three answers side by side and a pattern shows up. Each one treats everything the system knows as a single kind of thing, and then picks one party to be responsible for all of it. Answer one makes nobody responsible. Answer two makes the model responsible. Answer three makes you responsible.
But what a knowledge system holds is not one kind of thing. It is two, and they behave very differently.
Some of it can be worked out again from your notes at any moment. How many notes mention a concept. Which two concepts keep turning up together. Which notes are close in meaning to this one. A summary of what a group of notes says. If all of that vanished tonight, nothing would be lost: run the calculation again tomorrow and you get it back, updated for whatever you wrote in between — a model's summary may come back worded differently, but nothing that was only in it is gone.
The rest cannot be worked out again, because it was never in the notes to begin with. That "setup burden" and "onboarding friction" are the same idea. That a proposed connection between two concepts is a coincidence of vocabulary. Which concepts deserve a name at all. The paragraph that says what nine notes add up to, and the exception you think matters. These are decisions. Each one cost someone real reading, and if it disappears, the only way to get it back is to do that reading again.
That split suggests a different division of labor from any of the three answers:
- What can be worked out again, let the system work out — continuously, from your notes, and never ask you to maintain it. Do not treat it as settled either: it is a current reading, and the next calculation is allowed to change it.
- What cannot be worked out again, keep as yours — stored permanently, clearly marked as a decision, and never overwritten by a recalculation.
- Let your agents read both layers, and tell them which is which.
A proposal from a language model — "these two notes seem related", "this looks like a concept" — belongs in the first layer. It was worked out, not decided. It crosses into the second layer only when you accept it, and at that moment it becomes the kind of thing a later rescan must not undo.
This is the same line the personal knowledge management article ended on, drawn one layer further out. There the argument was that a machine can take the noticing and the meaning stays yours. A personal knowledge engine adds a second reader and asks that reader to respect the same line: an agent should be able to see what the software noticed, see what you decided, and never confuse the two.
Seen this way, each of the three answers gets one layer right and the other wrong.
Retrieval at question time handles the derived layer well, because it recalculates everything on every question. But it has no separate place for decisions. A conclusion you wrote down is just another passage — retrieved or missed depending on how it happens to be worded, ranked alongside the raw material it was drawn from. And a decision that was never a passage, like two names being one idea or a connection you rejected, has nowhere to live at all. If you want the agent to know it, you tell it again.
Keeping everything yourself handles the decided layer well. But it hands you the derived layer too, and that is exactly the part Karpathy is right about. Updating cross-references and recounting which ideas keep meeting is bookkeeping, and bookkeeping is where hand-kept systems tend to stall.
The model-maintained wiki is the most interesting case, because it gets the derived layer spectacularly right — the model does the bookkeeping, tirelessly — and then files your decisions into the same pages. A wiki page that says two claims contradict each other, a concept page, a synthesis with "an evolving thesis": those are exactly the sentences that carry meaning, and in the pattern as written, the model writes them. Karpathy assigns the human the job of thinking "about what it all means," and keeps himself close to the updates. But the place where what it all means gets written down belongs, by design, to the model. A year later, reading a sentence in the synthesis page, how do you know whether you concluded it or it was drafted for you and you nodded along? Nothing in the pattern stops you from marking the sentences you endorsed. It just is not part of it — and the note is explicit that it is a pattern, meant to be adapted.
This matters twice over once agents are the readers. An agent that reads a model-written synthesis as though it were your considered view is building on an earlier model's draft, with your name on it. An agent that can tell the two layers apart can weigh them differently: treat your decisions as the constraints, and treat everything derived as evidence to check.
Six tests for a personal knowledge engine
The personal knowledge management article proposed six tests for whether a system helps you relate ideas. These six are about something else: whether a system can keep both layers straight for two readers. Each comes with a check you can run in a few minutes, on any tool — including the one you already use.
1. The derived layer maintains itself
Counts, pairs and similar notes should update from your notes without you doing anything. If a number in your system is only right because you remembered to fix it, you are doing the bookkeeping, and you will eventually stop.
How to check. Add a note that mentions two concepts you have used before. Without touching anything else, see whether every view that should change has changed.
2. Every claim says where it came from
For any statement the system shows you — a connection, a label, a summary — you should be able to tell whether you made it, the software counted it, or a model proposed it. These are three different levels of trust, and a system that presents them in the same voice is asking you to treat a guess as a fact.
How to check. Pick five things your system tells you about one concept. For each, answer: who or what produced this?
3. Decisions outlive recalculation
Anything you decided — a merge, a rejection, a conclusion — has to survive the next rescan, the next model, the next import. A decision that a later calculation can quietly overwrite was only ever a preference.
How to check. Reject a suggestion, then trigger whatever process generated it again. Does it come back?
4. Every claim leads back to the notes
Whether the claim is yours, counted or proposed, the notes underneath it should be one step away — for you, and for your agent. An agent that receives only a conclusion cannot check it; an agent that receives the conclusion and the notes it rests on can.
How to check. Take one connection your system shows and count the steps to the notes that support it.
5. Your agents can read it — on your terms
An agent should be able to ask your knowledge questions that text search cannot answer: which concepts connect to this one, how strongly, which notes support that. And it should do so inside limits you set: off until you turn it on, only the parts you allow, and unable to change anything unless you have said it may.
How to check. Ask your agent something about your notes that requires structure, not keywords — "which ideas keep appearing alongside X?" — and then ask it what it was not allowed to see.
6. It says what it did not look at
An empty answer can mean "there is nothing" or "I did not check". For a person those are different, and for an agent they are more different still, because an agent can build a confident answer on the first when the truth is the second. A system should report its own coverage — how much of your material was actually searched or analyzed — instead of letting silence pass for evidence.
How to check. Ask for something in a corner of your notes you know is thin. See whether the answer tells you it is thin, or simply comes back empty.
Two of the six overlap with the earlier set on purpose — evidence and decisions matter to both readers. And notice what all six have in common: none of them is about how clever the AI is. Tests 1 and 3 are about what gets recalculated and what gets kept. Tests 2, 4 and 6 are about honesty — the system being clear about what it knows and how. Only test 5 needs an agent at all, and what it asks of the agent side is restraint as much as capability.
That is deliberate. A personal knowledge engine is not a smarter model. It is a better arrangement of the knowledge a model gets to read.
How Jotaid answers the six tests
I build Jotaid, and it describes itself as a personal knowledge engine, so this is the section where the argument has to pay for itself. A maker scoring their own product is the least reliable kind of review there is. The only defense is to make every answer checkable: for each test, what Jotaid actually does, where the result lives, what an agent connected to it sees — and where it falls short. Two of the six come back with a gap. They are left in.
1. The derived layer maintains itself ✓
Everything Jotaid counts is counted from the [[links]] in your notes, and recounted from them: how many notes reference each concept, which concepts share notes and how strongly, the Core / Bridge / Emerging roles, and the pairs that have never met but share neighbors. None of it is a stored fact you could let drift out of date, because none of it is stored as a fact.
The semantic index — the part that finds notes close in meaning — updates itself in the background whenever notes are saved, paragraph by paragraph rather than from each note's opening alone, and by default on your own device.
Thirty days later: you have maintained nothing, and every number reflects the notes as they are that day.
2. Every claim says where it came from ⚠ mostly
Most of what Jotaid shows you, and most of what it hands an agent, carries a label saying what produced it.
A search result says how it matched: literal means the word is actually written in that note, semantic means a model judged the note close. Related notes say whether they are related because both cite the same concepts — a connection you made — or because the index thinks they are similar. Co-occurrence and relations are kept as two separate lists, and the difference is spelled out to agents in so many words: co-occurrence "is counted fact", relations "are judgments". Each relation carries its provenance — what produced it, by what method, how many notes support it, and which note it came from — so an agent can tell what produced each claim, and how.
Two places blur the line, and both matter for exactly the reason this article gives.
A concept's body can hold your own words, or a draft from Enrich Content, which has the AI read the notes that cite the concept and replace the body with a fuller draft built from what was there. Once that is saved, nothing marks which sentences came from where. The one-line description shown for each concept inherits the same blind spot: it is the first line of that body, or, if the body is empty, the description the AI proposed and you accepted when the concept was created. You see the same line either way, and so does an agent: it is not told which it is getting.
Theme Summary asks the AI to read every note under a theme and write a summary. It lands in the theme note at your cursor, as ordinary text, which is convenient and is also the model-maintained-wiki problem in miniature: once you save, nothing in the note marks those paragraphs as drafted rather than concluded. Until that changes, the practical rule is simple. Treat the summary as raw material. Rewrite it into what you actually think, or keep it under a heading that says it is a draft.
Thirty days later: the labels are still attached everywhere except those two, and those two are the ones you should edit by hand.
3. Decisions outlive recalculation ⚠ half
Names hold. Rename a concept and the old name stays behind as an alias; merge two and the absorbed name does the same. An agent looking a concept up by its old name is still taken to the right one — and told that the name it used is stale.
Rejections hold. Reject a relation the AI proposed and Jotaid writes a tombstone. Re-run the analysis on more notes, with a different model, a month later — the rejected pair does not come back. Removing a link from a note leaves a tombstone too, so a concept's decline can be replayed instead of silently disappearing.
Endorsements do not exist yet. The personal knowledge management article said this plainly, and it is still true: relations have a field for "the user confirmed this", and the server lists confirmed relations first, but there is no button in the app that sets it. So what an agent can see today is what produced each claim and what you threw away. It cannot yet see what you endorsed.
That leaves the conclusion itself, the most important decision in the system, where it was in the PKM article: in prose you write, on the concept or in the theme note that gathers the evidence. It survives every recalculation, because no recalculation writes there.
Thirty days later: the alias holds, the tombstone holds, your paragraph holds. The endorsement flag is not there to hold.
4. Every claim leads back to the notes ✓
A matrix cell opens the notes in the intersection. A concept lists every note that references it. A relation names the note it came from. A search hit carries the passage that matched and where it starts, so it can be quoted without fetching the whole note.
The agent side gets the same trail, as ids it can follow: from a concept to its referencing notes and the passage around each mention, from a relation to its source note, from any note to its full text.
Thirty days later: one click for you, one call for your agent.
5. Your agents can read it — on your terms ✓
On macOS, Jotaid can run a small server that AI agents on the same Mac can connect to over the Model Context Protocol, the open standard that its specification describes as "a standardized way to connect LLMs with the context they need." It gives an agent eleven tools, and most of them answer questions that text search cannot:
explore_conceptstakes a question and returns, in one call, the matching notes, the concepts those notes are about, and what each of those concepts connects to — counted co-occurrence and judged relations, in separate lists.get_nodereturns one concept with its evidence: the notes that reference it and in what context, its relations with their provenance, the concepts it co-occurs with and how strongly, and how much of its weight sits inside this project against the whole library.get_matrixreturns the project's whole co-occurrence table with an algorithmic grouping — and deliberately no group names, on the grounds that the agent is better placed to name a group than a stored label would be.node_timelinesays when a concept showed up and how its mentions are spread over time, dated by the notes that mention it.resolve_nodefinds a concept by name, including by an old name a rename left behind.
The rest cover what you would expect: listing projects, notes and tags, fetching a note, and searching by meaning, by exact words, or both.
The terms are yours. The server needs Pro, it is off until you switch it on, it listens only on your own machine (127.0.0.1), and it uploads nothing anywhere. Its access token lives in the Keychain and can be regenerated at any moment, which disconnects anything still attached, and the settings show when an agent last read from it. Once it is on, it can read all of your projects — including ones you create later — until you narrow it to the ones you choose; an agent asking which projects it can read is shown only those. And today, every one of the eleven tools reads. None of them can create, change or delete anything in your library.
One boundary sits outside Jotaid, and it is worth saying clearly. The server sends nothing off your Mac, but the agent you connect is a separate program with its own model. What it reads from your notes goes wherever that agent sends its prompts. Switching the server on is a decision about that agent, not just about Jotaid.
Thirty days later: the connection is still exactly as wide as you left it, and the "last used" line tells you whether anything has been reading.
6. It says what it did not look at ✓
This is the test that is easiest to fail without anyone noticing, and it is the one Jotaid's agent interface is most insistent about.
A search that used the semantic index reports how much of the library the index covers, so that an empty result with an incomplete index reads as "not indexed yet", not "not in the library". An agent reading a concept's relations is told how many of the project's concepts carry any relation at all, and unless most of them do, an empty list "is not a finding about this one" — it probably means nobody ever ran the analysis. Capped lists say they are capped. The co-occurrence table says how many concepts it left out. The timeline says that a missing day "is not information".
This is not generosity. Relations are judgments, and judgments only exist where someone ran the analysis, so in most libraries they cover a small fraction of concepts. An agent that took an empty relation list at face value would conclude, confidently and wrongly, that most concepts stand alone.
Thirty days later: the coverage figures will have changed, which is the point — they describe what was actually checked, on the day it was checked.
Four of the six pass, two come back with a gap, and the gaps are the same shape: places where something a model drafted can pass for something you decided. That is the line this whole article is about, so it is the right place to be caught out, and the next section's workflow works around both.
A workflow: one question, two readers
The personal knowledge management article worked through one question from start to finish: why do people abandon tools they initially found useful? Twenty-one notes over three months — seven interview excerpts, four from a book on habit formation, six things noticed about software, four arguments with a colleague. Four named concepts. One pair, setup effort and perceived value, sharing 9 of the 16 notes that mention either. And a paragraph at the end:
Setup effort looks like a cost problem and behaves like a forecasting problem. People abandon setup when they cannot predict what finishing it buys them — not when it is long. Interview 3 is the exception and it is worth understanding before this goes any further: the payoff was clear and they quit anyway.
This section picks up a month later. The example is still an illustration, not a case study, and the numbers are the same ones.
You now have to use that paragraph: say, to draft a proposal for a shorter onboarding flow, with an AI agent helping. This is the moment the opening of this article described — the new session that knows nothing. Here is how it goes when the knowledge is kept in two layers.
Step 1 — Put the conclusion where both readers will find it
The paragraph belongs in the theme note that gathers the evidence — call the theme Why people abandon tools. That is the decided layer, in the one form that holds reasoning, exceptions and doubt: prose you wrote.
If you used Theme Summary on the theme note, or Enrich Content on one of its concepts, this is where you deal with it. Anything the AI drafted in either place gets rewritten into what you actually think or moved under a heading that says draft. It takes five minutes and it is the only way, today, for an agent reading them to know which sentences are yours.
Step 2 — Make sure the names have converged
In the earlier article you caught yourself writing "onboarding friction" in one note and "setup burden" in another, and kept one name for both. Because the name you dropped stays behind as an alias, you do not have to remember which one you used in March, and neither does the agent. If it asks about the old name, it is taken to the one you kept and told the name it used was stale.
Step 3 — Connect the agent, and narrow it
On a Mac with Pro, switch on the knowledge base server in Settings › Agent › MCP Connections, narrow it to this one project, and use Copy setup to paste the configuration into your agent. Narrowing is worth the extra click. Once on, the server can read every project you have, and this question needs one.
Step 4 — Ask it something only the structure can answer
The request that makes this work is not "summarize my notes". It is one that asks the agent to respect the two layers:
Read my theme note Why people abandon tools — that is my current conclusion. Then use the concept graph to test it. Which notes support it, which complicate it, and which concepts keep appearing alongside setup effort that I have not accounted for? Keep three things separate: what I concluded, what the counts show, and anything a model proposed. Cite a note for every claim. Before telling me something is absent, check the coverage.
What the agent can actually reach, with that request, is specific. The theme note, verbatim. The notes that reference setup effort, with the passage around each mention. The pair with perceived value — nine shared notes, an overlap of 56% — returned as counted fact, in a separate list from any relation a model proposed. When setup effort started turning up, dated by the notes that mention it. And, for any empty list, a note on whether it means "nothing" or "nobody checked".
A useful answer to that request would do three things you could not easily do in the same half hour: find the notes that bear on your conclusion but never used your words for it; separate the ones that support it from the one that does not; and point you at interview 3, with a quote, as the note to reread first. You then check what it cites — the passages are one step away — rather than taking its reading on trust.
Compare that with the opening of this article. Nobody pasted anything. Nobody re-explained June.
Step 5 — Decide, and write the decision back yourself
Suppose rereading interview 3 turns up the thing you missed: the participant quit because the payoff was clear but belonged to someone else — the tool made their manager's life easier, not theirs. That is a refinement of the conclusion, not a contradiction of it. People abandon setup when they cannot see what finishing it buys them.
The agent cannot write that into your notes. Every tool it has reads, and none of them changes anything. So you add it to the theme note, in your words, with the note that prompted it.
That sounds like a limitation, and in one sense it is: the agent found the thread and you still have to type the conclusion. But it is also the division of labor working. The one place a model does not write is the layer where your decisions live. Next month, when a different agent — or the same one, starting from zero again — reads that theme note, every sentence in it is one you stood behind.
Step 6 — Let the derived layer catch up on its own
You do nothing here. The new notes you wrote this week are indexed without you touching anything, and as long as they name the concepts they are about, they are counted and folded into the matrix too. If "responsibility" starts turning up next to setup effort in the notes you write next, the counts will show it before you think to look.
Most of the six steps are about keeping the decided layer clean, and only two involve the agent at all. That proportion is roughly right. The agent is fast at the part it is good at — reading everything, finding the notes that bear on a claim, keeping the counted separate from the concluded when it is shown the difference. What makes it useful is not how much it can do. It is that what it reads is arranged so it can tell whose thinking it is reading.
What a personal knowledge engine doesn't do
It does not give your agent a memory. Unless the agent keeps a memory of its own, it still starts every session from zero. What changes is that it can read where it used to have to be told, and that what it reads says which parts are decided. The accumulation lives in your notes, not in the model.
It does not do the reading that decides things. Step 5 is still twenty minutes with one interview. The engine can tell you which interview; the agent can offer a first reading of it. What it means is still yours to settle — which is the entire point of keeping a layer that is only yours.
Counted is not the same as true. A pair that shares nine notes might be a real relationship, or a phrase you reach for when you are tired. Co-occurrence tells you where to look, not what you will find. The earlier article makes this case at length; it applies with more force once an agent is summarizing the counts for you.
The practical boundaries, so you can rule Jotaid in or out quickly. It runs on macOS and iOS; notes live on your devices, sync over iCloud if you want, and import and export as plain Markdown. The agent connection is macOS-only and needs an agent that speaks MCP, running on the same Mac. Today it only reads: agents cannot write to your library. Jotaid's own AI features need Pro and a provider you configure with your own key — which is a privacy and cost decision, not a way around Pro: the key does not unlock Pro, Pro unlocks the ability to use the key. When you use a remote provider, the notes involved go to that provider.
The free tier is a single project, Inbox, with the whole derived layer switched on: the editor, wiki links, the graph, the co-occurrence matrix, link predictions, the canvas, iCloud sync, and an on-device semantic index that works without sending anything anywhere. Pro adds multiple projects, the AI features, the agent connection, bulk moves and stacking more than one filter at a time.
Some people should build something else. If most of what you keep is other people's writing — papers to digest, a book you are reading chapter by chapter, a field you are surveying — then Karpathy's pattern may suit you better than anything described here. Letting a model compile a wiki from sources is exactly what it is designed for, and plain Markdown files in a folder with Obsidian as the viewer is a setup you control completely. If what you need is to ask questions of a fixed set of documents, a retrieval tool over those documents is simpler still. And these do not exclude each other: Jotaid imports and exports plain Markdown, so the same notes can feed more than one system.
A personal knowledge engine in the sense argued here is for a narrower case: when the valuable part of your knowledge is what you concluded, and you want every reader of it — yourself next year, and whatever agent you are working with — to be able to tell that part from everything the software worked out around it.
Back to the new session
Open that agent session again, on the project you have been thinking about for four months.
This time it does not need you to paste anything. It can read the concepts you named, and find its way from an old name to the new one. It can see which ideas keep turning up together and in how many notes, and open those notes. It can read the paragraph you wrote in June, in the note where you keep your conclusions — and because you kept drafts out of that note, what it reads there is what you actually concluded. When a list comes back empty, the answer says whether that means nothing or nobody looked.
Karpathy's complaint about the usual setup was that there is no accumulation: every question starts from scratch. A personal knowledge engine accumulates in two places. The software keeps the derived layer current, so nobody has to do the bookkeeping. You keep the decided layer, so nothing a recalculation or a model produces can quietly take the place of what you concluded. And your agents read both, told which is which.
That is the whole idea. The rest is whether a given tool actually does it — which is why the six tests are written so you can run them on anything, starting with whatever you use now.
If you would like to see how Jotaid does it before installing anything, the documentation walks through concepts, themes and the matrix, and the release notes describe the agent connection.
Sources
- Andrej Karpathy, LLM Wiki, April 2026 — every quotation from Karpathy in this article comes from that page.
- Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020.
- MyMemory; Brian Wong, Personal Knowledge Engine, May 2026; Omid Farhang, Building a Personal Knowledge Engine with Jupyter and Local LLMs, December 2025.
- Jason Frand and Carol Hixon, Personal Knowledge Management: Who, What, Why, When, Where, How?, UCLA Anderson School, December 1999 (Internet Archive copy).
- Model Context Protocol specification.
