There is a pattern making the rounds, usually credited to Andrej Karpathy: keep a wiki of durable knowledge that lives between your raw source material and your individual AI conversations. Not the code itself. Not the chat history. The layer in the middle: architecture decisions, deployment procedures, incident writeups, and the lessons that are true this month.
An Obsidian vault is a natural home for it. Markdown files, YAML frontmatter, wikilinks, everything in Git. Agents read it at the start of a session and write back to it at the end.
It works.
Until it grows.
A vault that earns its keep passes a thousand Markdown files sooner than you expect. A troubleshooting file creeps toward three thousand lines. The append-only work log reaches three quarters of a megabyte. None of that is a failure of the pattern. It is what success looks like: the vault fills up with exactly the knowledge it was supposed to capture.
The failure shows up somewhere else, and it shows up twice.
A Wiki for One Is Not a Memory for Many
A personal vault has one reader who mostly knows where things are. The person who wrote the note about the schema migration remembers writing it.
A team vault has readers who do not. New developers. Contractors. And, increasingly, the readers that matter most in practice: AI agents. Claude Code, Codex, whatever comes next. An agent does not remember writing anything. Every session, it has to find the right five documents from scratch.
So the vault problem at scale is really two problems:
- Can any given reader find the current, correct answer?
- Is every reader paying the full search cost separately, every time?
The second one is the silent budget leak, because the way agents search a folder of Markdown is expensive.
What Agents Do Without an Index
Without retrieval infrastructure, an agent answers "where is this documented?" the only way it can: pattern-match filenames, grep for keywords, then read whole candidate files into its context window to see which one actually holds the answer.
In a vault of that size, a typical where-is-it question means a search pass plus two or three full-file reads: somewhere between 20,000 and 60,000 tokens of context. The answer usually lives in a few hundred of them.
Monolithic files make it worse. When one troubleshooting entry lives in a three-thousand-line file, the agent pays for all three thousand lines to use twenty of them. Every session. Every seat.
Multiply that by a team, and by every agent each person runs, and the same knowledge gets re-found, re-read, and re-paid-for dozens of times a week.
The Index: Local pgvector Over the Vault
The answer is a retrieval index in front of the vault, and the important design decisions are about restraint.
The vault stays the source of truth. Humans keep editing Markdown in Obsidian. The index is a rebuildable projection: the vault is scanned, split into heading-scoped chunks, embedded, and stored in PostgreSQL with the pgvector extension. Delete the database and nothing of value is lost. We covered that architecture, and why it deliberately is not a chatbot, in the first post of this series.
Every chunk keeps its provenance: which file, which heading. Answers come back as citations, not paragraphs of unattributed confidence.
Search is hybrid. Full-text search catches the exact identifiers engineers actually ask about: error codes, table names, container names. Vector similarity catches the questions phrased nothing like the document. Either leg alone misses things the other catches, and it does not take many test questions to watch it happen.
And one rule does more work than everything else combined: lifecycle filtering happens before retrieval. Every note carries a status in its frontmatter. Superseded, archived, and draft content is structurally excluded from the candidate set unless a reader explicitly asks for history. An archived page can easily sit closer in vector space to a question than half of the correct results. Similarity is not authority. On a team vault full of old-but-plausible content, that filter is the difference between a memory and a trap.
The whole thing runs locally. The database is local. The embeddings come from a small open-source model running in-process. Indexing the vault and querying it sends nothing to any external API. For a vault that contains your infrastructure notes and incident history, that is not a minor detail.
The Token Math
Here is where the accountant in you should perk up.
Retrieval itself costs zero LLM tokens. The query runs as SQL: a full-text match and a vector comparison. No model reads the corpus to answer. The only model involved is the local embedding model turning the question into a vector, which costs nothing and leaves nothing behind.
The agent then receives about five cited chunks, roughly 2,000 tokens, instead of grep output plus whole files. On search-shaped questions, that is a 10x to 30x reduction in context spend. The three-thousand-line file stops being a tax because readers fetch the one section they need.
Indexing costs round to nothing with a local model. Even priced against commercial embedding APIs, embedding an entire vault of this size is a couple million tokens once, with content-hash checks making re-indexing incremental afterward.
If you pay per token, the savings are direct. If you are on a flat-rate coding subscription, they show up differently but just as usefully: as rate-limit headroom, which means longer productive sessions before the meter cuts you off.
Now the honest part. Building an index like this consumes far more tokens than it saves at first. If per-query savings were the whole case, the payback period would be measured in months. It is not the whole case.
The biggest token line-item on any AI-assisted team is not reading. It is rework. An agent that confidently acts on a superseded runbook burns tens of thousands of tokens doing the wrong work, plus the tokens to diagnose it, plus the tokens to redo it, plus your afternoon. The lifecycle gate does not make retrieval cheaper. It makes entire categories of wasted session not happen.
The Team Payoff: One Memory, Many Readers
Start counting seats honestly and most "one-person" teams are already one human and several agents. Whole teams multiply that.
The index changes the shape of that arrangement in four ways.
Every reader gets the same current truth. The gate means no agent acts on version N-1 of a procedure while another acts on version N. When a runbook is superseded, it disappears from every seat's default view at the next re-index, simultaneously. There is no window where the intern's agent and the founder's agent disagree about how deployment works.
Lessons compound instead of evaporating. The vault ritual is that sessions write back what they learned: a log line, an incident note, a gotcha. Before the index, that knowledge was findable mainly by the person who wrote it. Now a lesson written once, by anyone, in any session, is retrievable by every future session of every reader. The write-back habit finally pays interest.
Onboarding stops being archaeology. A new developer's agent has the same recall over years of decisions and incidents as anyone else's, on day one. The knowledge of the one employee who has been there seventeen years is still in their head, but now it is also in the index, cited by file and heading.
The question log tells you what to write next. Every retrieval is recorded: who asked what, what came back, and, most usefully, what came back empty. A stream of real questions from real sessions is the most honest documentation backlog a team will ever get. You stop guessing which docs matter and start writing the ones people actually reached for and missed.
The same index serves every tool through one narrow interface. Agents reach it through the Model Context Protocol as a single read-only search tool; the same API can back editor integrations or an internal portal later. The model is replaceable. The memory is not.
What This Does Not Do
No overselling. Three limits worth naming.
It does not add permissions. On a personal or small-team vault where everyone may read everything, that is fine. The moment different readers are allowed different answers, you need permission-aware retrieval, which is the enterprise layer we described in the previous post.
It does not make your notes true. Retrieval quality has to be measured, not vibed. Keep a small golden set of real questions with expected sources and forbidden sources, including a trap where an archived near-duplicate must lose to the current page, and a question whose correct answer is that the vault does not contain the answer. On a corpus this size, a local index answers in tens of milliseconds and the whole set runs in seconds, so there is no excuse not to run it on every change. When the numbers slip, you will know before your agents do.
It does make your conventions load-bearing. Frontmatter status was a nice habit before; now it is the input to the authority filter. A team that adopts this pattern is agreeing that metadata hygiene is part of the job. In practice the agents help maintain it, and the write-back ritual keeps it current.
The Takeaway
A Karpathy-style vault gives your team a memory. A local pgvector index gives that memory recall.
The vault holds what the team knows. The index makes finding it cost 2,000 tokens instead of 60,000, keeps superseded knowledge from masquerading as current, hands every human and every agent the same answers, and logs the questions so the memory knows where it is thin.
All of it runs on your own machine, against files you already have, without a byte of your operational history leaving the building.
Your notes already know the answer. The index is how everything on your team, human or otherwise, finally gets to ask.
Agave Information Solutions builds custom software, database systems, AWS infrastructure, and private AI search solutions for organizations with complicated data. This series documents our knowledge platform from the first Markdown scan through a production-ready, permission-aware knowledge service.