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

Andrej Karpathy publiceerde in april 2026 een gist met een patroon voor het bouwen van persoonlijke kennisbanken met LLMs. In een week tijd: 99.000 bladwijzers. Meerdere implementaties gingen binnen dagen open source. graphify was er in 48 uur en haalde nog eens 27.000 meer. Het patroon sloeg aan omdat het een probleem benoemt dat elke AI-gebruiker al voelde: je agents hebben geen geheugen. Elk gesprek begint bij nul. Je legt opnieuw uit wat je bedrijf doet, wat je doelen zijn, hoe je schrijft, wat de context is, en de output komt generiek terug omdat de input niets had om mee te werken.

Bij webvise draaien we een knowledge layer die ons intern onderzoek, onze klantdocumentatie en de contentpipeline aanstuurt die dit blog produceert. Dit is wat we leerden.

Het probleem is niet je prompt. Het is geheugenverlies.

De standaard AI-workflow is stateloos. Je opent een chat, legt uit wat je 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 besteed je 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, geef je de agent toegang tot een persistente, gestructureerde kennisbank die hij leest voordat hij iets doet. De agent weet al hoe je bedrijf werkt, hoe je schrijft, wat je projecten zijn, wat er is geweest. Je slaat de heruitleg over en gaat direct naar het werk.

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 je 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. Hij maakt pagina's aan, werkt ze bij wanneer er nieuwe bronnen binnenkomen, onderhoudt kruisverwijzingen en houdt alles consistent. Jij 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 hij moet volgen en welke workflows hij moet uitvoeren. Dit is wat van een generieke LLM een gedisciplineerde wiki-beheerder maakt.

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

Waarom dit RAG klopt 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 vergeleken met zoeken door ruwe bestanden. Onze 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.

We schreven een uitgebreide technische vergelijking van RAG versus index-gebaseerde retrieval. De korte versie: voor kennisbanken onder de 1.000 documenten presteert de gecompileerde wiki beter dan RAG op nauwkeurigheid, kosten en 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.

Wat we leerden van onze eigen knowledge layer

Onze 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 produceert een gedisciplineerde wiki met consistente conventies. Een vaag schema produceert hallucinaties en wildgroei. 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. Onze regel: zoek voordat je een nieuwe pagina aanmaakt de bestaande wiki door op overlappende inhoud. Als een bestaande pagina 60% of meer van hetzelfde terrein dekt, verrijk je 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 je een goede vraag en krijg je een bruikbaar antwoord, dan wordt dat antwoord teruggearchiveerd als een nieuwe wikipagina. De volgende keer dat iemand een verwante vraag stelt, heeft de agent al een voorgecompileerde synthese om uit te putten. 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 dumpen en zeggen 'ingest dit' levert een dunne samenvatting op. De bron met de agent doornemen, takeaways bespreken en aangeven wat de nadruk moet krijgen, levert pagina's op die bruikbaar blijven naarmate de wiki groeit. Wij hanteren een strikt workflow: ruwe bestand opschonen, key takeaways bespreken, wachten op goedkeuring, dan volledig extraheren.

• Het indexbestand is het retrievalsysteem. Onze rootindex telt 22 regels. Elke submap heeft zijn eigen index met elk pagina's 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 je schrijft

Karpathy noemt het het schema. Wij noemen het CLAUDE.md. Sommige frameworks splitsen het op in een Knowledge Base Layer en een Brand Foundation. De naam maakt niet uit. 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 je onzekerheid markeert. Hoe je 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 je conventies. Het schema voorkomt die drift. Wij behandelen het als productiecode: elke wijziging is doelbewust en getest tegen echte ingests.

Hoe je er in 20 minuten een bouwt

Je hebt geen 17 bestanden, geen content skill graph en geen custom embedding-pipeline nodig. Je hebt vier dingen nodig:

• 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 jouw domein. Houd het om mee te beginnen onder de 200 regels.

• Een LLM-agent met bestandstoegang. Claude Code, OpenAI Codex of een andere agent die markdown-bestanden kan lezen en schrijven. Wijs hem naar de vault. Hij leest het schema bij het opstarten.

• Je eerste bron. Gooi een artikel, een set notities of een document in `raw/`. Zeg tegen de agent dat hij het moet ingesteren. Kijk 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 je toevoegt en elke vraag die je stelt de wiki verrijkt. De eerste ingest kost 10 minuten actieve aandacht. Bij de twintigste kent de agent je domein goed genoeg om te extraheren en kruisverwijzingen aan te leggen met minimale sturing.

Optionele tooling naarmate je schaalt: qmd van Tobi Lutke voor lokale hybride zoekopdrachten met BM25 en vector retrieval zodra je de 300 pagina's passeert. De Obsidian Web Clipper-extensie om snel webart ikelen in je 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 bijna nul omdat de LLM het bijhoudt. De enige echte kosten zijn de discipline om het schema eerlijk te houden en de ingest-kwaliteit hoog. Dat is een mensenprobleem, geen technologieprobleem.

Wat dit betekent 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. Al het andere is prompting in het luchtledige.

Bij webvise bouwen we knowledge layers voor bedrijven die willen dat hun AI-agents echt weten waar ze het over hebben. Als je meer tijd kwijt bent aan het uitleggen van context aan je tools dan aan het er waarde uit halen, is dit het probleem dat dit oplost. Neem contact op.