LLM Knowledge Bases
Why I'm rebuilding how my team captures knowledge — and why an LLM is doing most of the work.
When Andrej Karpathy shared his approach to LLM-powered personal knowledge bases, something clicked. Not because the idea was entirely novel — knowledge management has been a cottage industry for decades, from Zettelkasten cards to Confluence wikis to Notion databases. What struck me was the specific inversion he described: the LLM doesn't just query your knowledge, it authors and maintains it. That distinction matters enormously, especially in fintech, where the gap between raw data and structured understanding is both large and expensive.
I've spent the last several weeks designing a version of this system for my own work — a knowledge base sitting at the intersection of payments infrastructure, regulatory compliance, and emerging AI tooling in financial services. Here's what I've found, what I'm building with, and why I think this approach genuinely outperforms every knowledge capture method I've used before.
The problem it's solving
In fintech, knowledge is perishable and fragmented. Regulatory guidance from the Central Bank of Ireland lands in a PDF. A thread about PSD3 implications lives in Slack. A competitor's API documentation sits in a browser tab someone bookmarked six months ago. A post-mortem from a failed payment rail integration is buried in a Jira ticket nobody reads. The tools we've used to manage this — Confluence, Notion, shared Google Drives — are fundamentally passive containers. They store what you put in, they don't synthesise, cross-reference, or surface connections.
"The tools we've used are fundamentally passive containers. They store what you put in — they don't synthesise, cross-reference, or surface connections."
The Karpathy model flips this. Raw inputs flow into a directory. An LLM compiles them into a living wiki: structured articles, backlinks, concept maps. The wiki isn't a destination you occasionally update — it's a continuously compiled artefact. For a fintech context, this means that a new EBA opinion paper, a GitHub repo exploring SEPA Instant integration, and a competitor teardown can all become interconnected nodes in a single coherent knowledge graph, maintained without manual effort.
How I'm implementing it
My implementation centres on a raw/ directory that ingests source material: regulatory documents, research papers, internal architecture notes (anonymised), RSS feeds from financial regulators, and curated news summaries. I'm using Claude Code as my primary agent layer for compilation tasks — it runs against the directory, incrementally building and updating a wiki/ directory of markdown files organised by domain: payments, compliance, open banking, infrastructure, market intelligence.
For the IDE layer — the place where I read and navigate the compiled wiki — I'm not using Obsidian. I want something that fits more naturally into my existing development workflow. My current shortlist is Logseq (which offers a graph view and robust markdown support with an open, local-first architecture), Foam (a VS Code extension that turns a markdown directory into a wiki with backlinks and graph visualisation — perfect since I'm already living in VS Code), or simply a lightweight local web server rendering the markdown directory via Markwhen or a custom Next.js viewer. For visualising relationships between concepts — say, how DORA requirements intersect with third-party risk management obligations — I'm experimenting with Mermaid diagrams auto-generated by the LLM and embedded directly into wiki articles.
For output, instead of Marp slide formats, I'm generating structured briefs in markdown that I can pipe into a simple HTML template, producing clean one-pagers I can share with stakeholders. The LLM also generates comparative summaries when I'm evaluating technology choices — think: "compare these four payment orchestration platforms across latency, fee structure, and PSD2 compliance posture."
Strengths and weaknesses
Strengths
- Synthesises fragmented sources automatically
- Cross-references regulatory and technical content
- Queries scale with the knowledge base, not your memory
- Every exploration enriches future queries
- No manual tagging or organisation overhead
- LLM health checks catch gaps and inconsistencies
Weaknesses
- Source quality determines wiki quality entirely
- LLM compilation can introduce subtle errors
- Sensitive data governance requires careful scoping
- Token costs grow with wiki scale
- No native team collaboration layer yet
- Requires ongoing prompt engineering discipline
The data governance point deserves particular attention in a fintech context. Not everything can go into the raw directory. Customer data, anything under NDA, internal pricing models — these require a separate, carefully scoped knowledge base or must be excluded entirely. I'm treating the wiki as a strategically curated intelligence layer, not a dump of everything I've ever touched.
The toolset
| Tool | Role |
|---|---|
| Claude Code | Agent layer for wiki compilation and Q&A |
| Foam / VS Code | IDE and wiki navigation with graph view |
| Logseq | Local-first wiki viewer, backlink graph |
| Mermaid | Auto-generated concept and flow diagrams |
| Markdownlint + LLM | Health checks, gap analysis, integrity linting |
| n8n / Make | Automated ingest pipelines from regulatory feeds |
Why this beats everything else I've tried
I've tried most of the canonical approaches. Notion databases collapse under their own taxonomy weight — every new document forces a decision about where it belongs, and those decisions compound into a system nobody navigates naturally. Confluence is where knowledge goes to age quietly. Shared Google Drives are organised by whoever set them up, which is usually optimised for storage, not retrieval. Even dedicated tools like Roam Research, which I used for two years, require constant manual curation to maintain their graph's coherence.
The LLM-compiled wiki solves the curation problem by removing the human from the maintenance loop. I decide what goes into raw/. The LLM decides how it connects, what it means in context, and how it should be presented. My role shifts from librarian to editor — I review the wiki periodically, course-correct the compilation prompts, and add source material. The cognitive overhead drops dramatically.
More importantly, the knowledge compounds. When I ask a complex question — "what are the second-order implications of the EU AI Act on algorithmic credit scoring within PSD3's open finance framework?" — the answer draws on dozens of articles the wiki has compiled and cross-referenced. No single Slack thread, Notion page, or Google Doc could answer that. The wiki can, because it was built to connect things, not just contain them.
Karpathy noted there's room for an incredible product here, not just a collection of scripts. I'd agree — but until that product exists, the scripts are producing genuine value. This is knowledge infrastructure, and in fintech, infrastructure compounds.
You can read Karpathy's post here: x.com/karpathy/status/2039805659525644595.
This article is an independent opinion piece. All implementation details reflect personal and exploratory workflows, not production systems.