What This Session Is About
Uri said he had spent the prior two months using the LLM Wiki pattern — introduced by Andrej Karpathy — to manage knowledge bases for his company. In this session he showed how the workflow works: raw transcripts in, structured Obsidian-style wiki out, with an LLM doing the organizing and an agent keeping it current.
The live demo used Stark Industries as a fictional example — five Gong call transcripts from "the Avengers" selling Jarvis — to show how a product team could extract feature requests, sentiment, customer profiles, and synthesis from call recordings in minutes.
The Core Idea
Three ingredients make it work:
Any unstructured input — Gong transcripts, Zoom recordings, PDFs, one-pagers, emails, Jira exports. You drop it in a /raw folder. You never touch it again.
A folder of markdown files organized by the LLM. Customers, features, calls, synthesis — all interlinked. Readable by humans in Obsidian. Navigable by the LLM using a CLAUDE.md schema file it wrote itself.
Claude (or whatever model). It runs three operations: Ingest (raw → wiki), Query (analysis on demand), Lint (find contradictions, stale data, broken links).
Key Insights
- 01Uri's core contrast: RAG does not accumulate by default, LLM Wiki can. In his framing, useful answers can be written back into the wiki as synthesis pages instead of being recomputed from raw sources every time.
- 02The knowledge base stays inspectable. Uri's point was that plain markdown makes the agent's working knowledge easier to audit: customers, features, calls, synthesis pages, and links are visible to humans instead of hidden behind retrieval internals.
- 03Uri argued that LLMs can help reduce wiki drift. Human-maintained Notion and Confluence spaces often collect duplicate pages and stale information. His LLM Wiki workflow uses ingestion and lint passes to link related content and flag conflicts or outdated data.
- 04The
CLAUDE.mdschema is the secret. When you open a session with a knowledge base, the LLM reads the schema file first — it describes the folder structure, what each entity type looks like, what front matter properties exist, and how to navigate. This is exactly the same pattern asCLAUDE.mdin coding projects. - 05Ingestion converts expensive formats to cheap ones. Reading a PDF is token-heavy. After ingestion, the LLM reads markdown instead. The one-time ingestion cost is higher, but every query after is faster and cheaper.
- 06You can automate the whole pipeline. Cron jobs push new Gong calls or Zoom transcripts to
/raw, and a scheduled skill runs ingestion automatically. Uri's co-founder doesn't use Obsidian at all — he just has the folder connected to his agentic workspace and queries it directly.
The idea is: I'm in charge of adding raw data. The LLM is in charge of organizing it. I'm not touching any files in the wiki. I'm not editing them. I'm not changing them.
From the Q&A
Why is this better than RAG?
RAG doesn't update itself as you ask questions. And with RAG you don't really know how the data is organized internally. Here you can see every file, every link, every property. It's not necessarily better — it's a different tool for a different scope.
What about token consumption as the wiki grows?
The biggest consumption is at ingestion. After that, the LLM rarely goes back to the raw data — it reads the wiki pages instead, which are much shorter. And because synthesis gets written back to the wiki, the same analysis doesn't get recomputed every time.
How do you keep it updated when decisions change over time?
You tell the LLM during ingestion what time-sensitive data looks like. After a quarter, old feature request priorities can be archived. Action items are harder unless you close the loop by feeding in completion signals. The wiki is only as current as the raw data you feed it.
Can this work at organization scale, across teams?
Uri's team is experimenting with pushing the wiki to Git so multiple people can pull and push. Read-only users (asking questions only) are easy. Write access (who can change the knowledge base) is the unsolved problem. Monday.com has started doing this internally.
Where This Fits in the Bigger Picture
Kamal Kishore, who works with knowledge graphs, framed LLM Wiki as a lightweight entry point into a broader knowledge-graph idea. His view from the Q&A: LLM Wiki can work well for narrower team or personal scopes, while larger enterprise document sets may eventually need graph-based approaches and more formal evaluation.
Uri built his own Obsidian-like viewer because the default app had too many features he didn't need. His version opens directly from the terminal, lets him ask questions and run skills inline, and syncs to Git. The markdown files don't care what you read them with.
What to Try Next
- Read Karpathy's LLM Wiki gist on GitHub — everything Uri covered is documented there
- Start with one type of raw data (meeting transcripts, Gong calls, emails) and one knowledge base scope
- Let the LLM write the schema — give it a prompt describing what you want to track, then paste the LLM Wiki methodology
- Use
ingest, then immediately try aquerythat would be painful manually (e.g. "top product gaps without a committed fix date") - Set up a cron job for automated ingestion once the structure feels right