De AI knowledge layer: 127 pagina's, geen vector database, en wat ik fout had

Andrej Karpathy publiceerde in april 2026 een gist met een patroon voor het bouwen van persoonlijke kennisbanken met LLMs. In een week: 99.000 bladwijzers. Meerdere implementaties gingen binnen dagen open source. graphify was er in 48 uur en haalde nog eens 27.000. Het patroon sloeg aan omdat het een vertrouwd probleem benoemt: de meeste agents missen persistent geheugen tussen sessies. Elk gesprek begint bij nul. U legt opnieuw uit wat uw bedrijf doet, wat uw doelen zijn, hoe u schrijft, wat de context is, en de output komt generiek terug omdat de input niets had om mee te werken.

Bij webvise draait een knowledge layer voor intern onderzoek en projectdocumentatie. Dit is wat ik ervan heb geleerd.

Agents vergeten tussen sessies.

De standaard AI-workflow is stateloos. U opent een chat, legt uit wat u nodig hebt, krijgt een antwoord, sluit de chat. Volgende sessie, dezelfde uitleg. De opgebouwde context is weg. De meeste mensen compenseren door langere prompts te schrijven, achtergronddocumenten te kopiëren of bestanden te uploaden aan het begin van elke sessie. Dat werkt, maar het schaalt niet. Op een gegeven moment raakt het contextvenster vol, daalt de kwaliteit, en besteedt u meer tijd aan het voorbereiden van de prompt dan aan het echte werk.

De knowledge layer lost dit op op infrastructuurniveau. In plaats van context in elke prompt te proppen, geeft u de agent toegang tot een persistente, gestructureerde kennisbank die hij leest voordat hij iets doet. De agent weet al hoe uw bedrijf werkt, hoe u schrijft, wat uw projecten zijn, wat er is geweest. De heruitleg vervalt en het werk begint direct.

Drie lagen, geen vector database

De architectuur bestaat uit drie onderdelen:

• Ruwe bronnen. Een map met onveranderlijke documenten: artikelen, notities, transcripten, PDF's, vergaderingsopnames, onderzoek. De agent leest deze maar wijzigt ze nooit. Dit is de bron van waarheid.
• De wiki. Een verzameling LLM-gegenereerde markdown-bestanden met kruisverwijzingen. Entiteitspagina's, conceptpagina's, syntheses, vergelijkingen, playbooks. De agent beheert deze laag volledig: maakt pagina's aan, werkt ze bij wanneer nieuwe bronnen binnenkomen, onderhoudt kruisverwijzingen en houdt alles consistent. U leest het. De agent schrijft het.
• Het schema. Een configuratiedocument (CLAUDE.md, AGENTS.md of equivalent) dat de agent vertelt hoe de wiki is gestructureerd, welke conventies van toepassing zijn en welke workflows hij moet uitvoeren. Dit is wat van een generieke LLM een gedisciplineerde wiki-beheerder maakt.

De wiki is een gecompileerd artefact. Kennis wordt niet opnieuw afgeleid bij elke query. De agent compileert één keer, legt kruisverwijzingen aan en houdt alles actueel. Voeg een nieuwe bron toe, dan integreert de agent die in de bestaande wiki en werkt elke relevante pagina bij. Stel een vraag, dan leest de agent voorgecompileerde pagina's in plaats van door ruwe documenten te zoeken.

Waarom dit RAG verslaat voor de meeste toepassingen

RAG leidt antwoorden opnieuw af op het moment van de query door documenten op te knippen en naar relevante fragmenten te zoeken. De gecompileerde wiki-aanpak slaat dat volledig over. graphify mat 71,5x minder tokens per query in hun gepubliceerde vergelijking; de resultaten zijn afhankelijk van de corpuskenmerken en queryverdeling. Eigen metingen laten ruwweg 1.000 tokens vault-inhoud per query zien, tegenover de 3.000 of meer tokens die een typische RAG-pipeline injecteert.

Ik schreef een uitgebreide technische vergelijking van RAG versus index-gebaseerde retrieval. De korte versie: in de geanalyseerde workloads presteerde de gecompileerde wiki beter dan RAG op nauwkeurigheid, kosten en operationele complexiteit. Geen vector database, geen embedding-model, geen chunking-strategie, geen re-indexeringstaak. Vijf shell-commando's en een bijgehouden indexbestand.

De evolutie verliep in drie fasen: one-shot RAG van 2020 tot 2023, agentic RAG met multi-hop retrieval van 2023 tot 2024, en context engineering vanaf 2025 waarbij de agent zijn eigen context opbouwt uit meerdere bronnen. De knowledge layer is de infrastructuur voor die derde fase. De meeste teams bouwen nog steeds voor fase één.

Lessen uit de eigen knowledge layer

De interne wiki telt momenteel 127 gestructureerde pagina's verdeeld over zeven categorieën: mensen, bedrijven, concepten, playbooks, collecties, syntheses en tools. Elke pagina volgt een standaardsjabloon met YAML-frontmatter, kruisverwijzingen via Obsidian wikilinks en bronvermelding. De agent voert zes gedefinieerde operaties uit: ingest, conversational update, query, lint, enrich en reorganize.

• Het schemabestand is allesbepalend. Al het andere volgt eruit. Een goed geschreven schema levert een gedisciplineerde wiki op met consistente conventies. Een vaag schema levert hallucinaties en wildgroei op. De huidige versie telt ongeveer 200 regels en dekt directorystructuur, paginaformaat, alle zes operaties, naamgevingsconventies en het omgaan met tegenstrijdige bronnen. Het kostte meerdere iteraties om goed te krijgen.
• Dedup-eerst voorkomt paginawildgroei. De regel: zoek voordat u een nieuwe pagina aanmaakt de bestaande wiki door op overlappende inhoud. Dekt een bestaande pagina 60% of meer van hetzelfde terrein, verrijk dan die pagina in plaats van een nieuwe te maken. Zonder deze regel vult de wiki zich met redundante pagina's die kennis opsplitsen in onbruikbare stukken.
• Queries worden onderdeel van de kennisbank. Stel een goede vraag en levert dat een bruikbaar antwoord op, dan wordt dat antwoord teruggearchiveerd als nieuwe wikipagina. De volgende keer dat iemand een verwante vraag stelt, heeft de agent al een voorgecompileerde synthese beschikbaar. Dit is het samengestelde effect dat het systeem beter maakt in de loop van de tijd, niet alleen groter.
• Ingest-kwaliteit hangt volledig af van discipline. Een ruw artikel aanleveren met 'ingest dit' levert een dunne samenvatting op. De bron samen met de agent doornemen, takeaways bespreken en aangeven wat de nadruk moet krijgen, levert pagina's op die bruikbaar blijven naarmate de wiki groeit. De workflow is strikt: ruwe bestand opschonen, key takeaways bespreken, wachten op goedkeuring, dan volledig extraheren.
• Het indexbestand is het retrievalsysteem. De rootindex telt 22 regels. Elke submap heeft zijn eigen index met elke pagina en een éénregelige beschrijving. De agent leest de rootindex op ongeveer 400 tokens, identificeert de juiste submap, leest die index en haalt vervolgens de specifieke pagina's op. De meeste queries zijn klaar met drie leesslagen en ongeveer 1.000 tokens vault-inhoud.

Het schema is het belangrijkste bestand dat u schrijft

Karpathy noemt het het schema. Hier heet het CLAUDE.md. Sommige frameworks splitsen het op in een Knowledge Base Layer en een Brand Foundation. De naam is bijzaak. Wat telt is dat dit ene bestand bepaalt hoe de agent zich gedraagt in elke sessie.

Een goed schema definieert:

• Directorystructuur. Waar ruwe bronnen naartoe gaan, waar wikipagina's naartoe gaan, hoe ze in categorieën zijn georganiseerd.
• Paginaformaat. Frontmatter-velden, sectiestructuur, bronvermeldingsregels, kruisverwijzingsconventies.
• Operaties. Stapsgewijze workflows voor het ingesteren van bronnen, beantwoorden van queries, uitvoeren van gezondheidscontroles en onderhouden van de wiki in de loop van de tijd.
• Kwaliteitspoorten. Wat een pagina compleet maakt. Wanneer u onzekerheid markeert. Hoe u omgaat met tegenstrijdige bronnen. De regel dat elke claim herleidbaar moet zijn naar een bron.

Zonder dit improviseert de agent. Hij maakt pagina's aan op willekeurige locaties, gebruikt inconsistente opmaak, dupliceert inhoud over pagina's heen en wijkt bij elke sessie verder af van uw conventies. Het schema voorkomt die drift. Het wordt behandeld als productiecode: elke wijziging is doelbewust en getest tegen echte ingests.

Hoe u er in 20 minuten een bouwt

U hebt geen 17 bestanden, geen content skill graph en geen custom embedding-pipeline nodig. Vier dingen volstaan:

• Een Obsidian vault met twee mappen. `raw/` voor brondocumenten en `wiki/` voor agent-gegenereerde pagina's. Open het in Obsidian voor de grafiekweergave en navigatie.
• Een schemabestand. Begin met Karpathy's gist. Pas de directorystructuur en het paginaformaat aan voor uw domein. Houd het om mee te beginnen onder de 200 regels.
• Een LLM-agent met bestandstoegang. Claude Code, OpenAI Codex of elke andere agent die markdown-bestanden kan lezen en schrijven. Wijs hem naar de vault. Hij leest het schema bij het opstarten.
• Uw eerste bron. Zet een artikel, een set notities of een document in `raw/`. Geef de agent opdracht het te ingesteren. Zie hoe hij wikipagina's aanmaakt, kruisverwijzingen opbouwt en de index bijwerkt.

Dat is de hele loop. Het systeem wordt elke dag beter omdat elke bron die u toevoegt en elke vraag die u stelt de wiki verrijkt. De eerste ingest kost 10 minuten actieve aandacht. Bij de twintigste kent de agent uw domein goed genoeg om te extraheren en kruisverwijzingen aan te leggen met minimale sturing.

Optionele tooling naarmate u schaalt: qmd van Tobi Lutke voor lokale hybride zoekopdrachten met BM25 en vector retrieval zodra u de 300 pagina's passeert. De Obsidian Web Clipper-extensie om snel webartikelen in uw raw-map te krijgen. Dataview voor het uitvoeren van queries op paginafrontmatter. Git voor versiegeschiedenis. Niets hiervan is vereist om te beginnen.

Wat er niet toe doet

Het grootste deel van de complexiteit die mensen associëren met AI-kennissystemen is overhead voor problemen die ze nog niet hebben. Een vector database voor 200 documenten, een custom embedding-model terwijl een bijgehouden index de retrieval doet, een re-indexeringspipeline terwijl een document toevoegen betekent: een bestand schrijven, een chunking-strategie terwijl de pagina de eenheid is. Niets ervan is nodig op de schaal waarop de meeste bedrijven opereren.

Het patroon werkt omdat markdown eenvoudig is en LLMs er goed in zijn om het te lezen en te schrijven. De infrastructuurkosten zijn nul. De onderhoudskosten zijn laag omdat de LLM de index-updates verzorgt; periodieke menselijke review blijft aanbevolen voor nauwkeurigheid. De enige echte kosten zijn de discipline om het schema eerlijk te houden en de ingest-kwaliteit hoog. Dat is een mensenprobleem, geen technologieprobleem.

Toepassingen voor bedrijven

Dezelfde architectuur werkt op bedrijfsschaal. Vervang persoonlijke notities door klantdocumentatie, sales playbooks, onboardinggidsen en interne SOP's. Vervang de agent van één persoon door de agent van elk teamlid die leest uit een gedeelde kennisbank.

Het patroon is identiek: ruwe bronnen gaan erin, de agent compileert gestructureerde pagina's, kruisverwijzingen worden automatisch opgebouwd, mensen valideren. Het verschil is dat een gedeelde knowledge layer nieuwe teamleden direct productief maakt. Hun agent weet al wat de klantgeschiedenis is, wat de interne conventies zijn en wat de projectcontext is. Geen zes weken inwerkperiode. Geen stamkennis die opgesloten zit in iemands hoofd.

Karpathy noemt het een LLM wiki. Eric Osiu noemt het een shared brain. Cody Schneider noemt het een data warehouse. De naam blijft veranderen. Het patroon niet: agents hebben gecompileerde, gestructureerde kennis nodig om nuttig werk te doen. Zonder persistent context werken prompts zonder de institutionele kennis die ze nodig hebben.

webvise bouwt knowledge layers voor bedrijven die willen dat hun AI-agents echt weten waar ze het over hebben. Besteedt u meer tijd aan het uitleggen van context aan uw tools dan aan het er waarde uit halen, dan is dit het probleem dat dit oplost. Neem contact op.