de kennisbank

Mijn Teams-folder is een GitHub-repository. Toen ik dat op LinkedIn schreef, kwam steeds dezelfde vraag terug: klinkt goed, maar hoe zet ik dat zelf op? Het antwoord is minder spannend dan mensen verwachten. Een map met markdown-bestanden, een instructiebestand, en een AI die toegang heeft tot die map. Meer infrastructuur is het niet.

Het interessante zit niet in de tool. Het zit in de vraag wie die kennisbank onderhoudt, en voor wie hij eigenlijk geschreven is.

In een eerder essay beschreef ik hoe ik projectkennis structureer: ruwe bronnen, een wiki, een schema. Dat was de persoonlijke kant. Dit essay gaat over de laag daarboven. Wat gebeurt er als die kennisbank niet één werkplek is, maar het fundament waar mens en AI allebei uit werken?

het archief dat niemand leest

Vrijwel elke organisatie heeft een kennisgraveyard. Een gedeelde schijf, een intranet, een wiki die met goede moed is opgezet en na drie maanden stilviel. Het patroon is altijd hetzelfde: de onderhoudslast groeit sneller dan de waarde, dus mensen geven het op. En omdat het archief veroudert, vertrouwt niemand het meer, dus wordt het nog minder bijgehouden. Een documentenmap is een archief. Je gooit er bestanden in en zoekt er later in, als je het al probeert.

Intussen gebruiken diezelfde organisaties AI als een chatbot met een geheugen van goudvis-formaat. Elke vraag begint bij nul. De documenten staan er wel, maar elke sessie moet ze opnieuw doorploegen, en elke samenvatting wordt opnieuw afgeleid.

Mijn omkering: maak van het archief een kennismodel. De AI leest een nieuwe bron, haalt de kern eruit en verwerkt die in bestaande pagina’s. Tegenstellingen worden gemarkeerd, samenvattingen aangescherpt, verbanden gelegd. De kennis wordt één keer gecompileerd en daarna actueel gehouden, niet bij elke vraag opnieuw opgebouwd. Het concept komt van Andrej Karpathy, die het in april 2026 de LLM Wiki noemde. Ik pas het dagelijks toe met Claude Cowork op mijn eigen bestanden.

twee lezers, één bron

Wat dit patroon anders maakt dan elke eerdere kennisbank-poging: er zijn nu twee soorten lezers, en ze lezen hetzelfde bestand.

De AI leest de wiki als werkgeheugen. Bij elke vraag pakt hij eerst de index, een catalogus waarin elke pagina met één regel is samengevat, en duikt dan gericht in de juiste pagina’s. Dat werkt verrassend goed tot in de honderden pagina’s, zonder embeddings en zonder aparte zoekinfrastructuur.

De mens leest dezelfde wiki als naslagwerk. Wie het prettiger wil, wijst Obsidian naar de wiki-map: een gratis programma dat markdown-mappen toont als een doorklikbare kennisbank, met een grafiekweergave die in één oogopslag laat zien wat met wat verbonden is en welke pagina’s losse eindjes zijn. De AI maakt aanpassingen op basis van het gesprek, jij bladert er realtime doorheen. De AI is de schrijver, Obsidian is je leesomgeving, de wiki is het resultaat.

Dat is het architectuurpunt. Geen aparte documentatie voor mensen en aparte context voor machines, maar één bron van waarheid in het enige formaat dat beide vloeiend lezen: platte tekst in mappen. Geen vendor, geen abonnement, geen migratie als de tool van volgend jaar anders heet.

wie onderhoudt wat

De rolverdeling is de kern van de methode, en hij is strikt.

Jij bent de redacteur. Je draagt bronnen aan, geeft richting, stuurt bij waar de AI de plank misslaat. De ruwe bronnen zijn heilig: de AI leest eruit maar wijzigt er nooit iets aan.

De AI is de schrijver. Alle kruisverwijzingen, samenvattingen, indexregels en logboekvermeldingen zijn zijn werk. Dat is precies het saaie werk waar mensen wiki’s voor laten versloffen.

In de praktijk zijn er maar drie operaties. Ingest: een nieuwe bron verwerken, de betrokken pagina’s bijwerken, index en log aanvullen, en markeren wat in tegenspraak is met wat er al staat. Query: een vraag beantwoorden met verwijzingen naar de eigen pagina’s, en een waardevol antwoord terugschrijven als nieuwe pagina, zodat ook je vragen kennis opbouwen. Lint: een periodieke gezondheidscheck op tegenstellingen, verouderde claims, pagina’s zonder inkomende links en begrippen die nog geen eigen pagina hebben.

En één gewoonte die alles draagt: elke werksessie eindigt met de opdracht om de wiki bij te werken met wat we die sessie hebben geleerd. Vijf minuten, geen aparte documentatietijd. Dit is de hele truc.

van map naar fundament

Beginnen kan lokaal, in een gewone map op je eigen machine. De stap die er een organisatiefundament van maakt is de repository. Zet de map op GitHub en je krijgt versiegeschiedenis, een back-up en de mogelijkheid om met een team te werken er in één beweging bij. Elke wijziging van de AI is een zichtbare wijziging in versiebeheer, terug te draaien en te reviewen zoals code.

Daar komt de Teams-folder-uitspraak vandaan. Niet omdat een repo hip is, maar omdat het de enige gedeelde opslag is waar een AI-agent volwaardig in kan werken en waar tegelijk elke wijziging traceerbaar blijft.

Eerlijk is eerlijk: met een heel team tegelijk in dezelfde wiki schrijven zonder conflicten heb ik nog niet opgelost. Versiebeheer vangt een deel op, maar de redactievraag blijft staan: wie bepaalt bij een tegenstelling welke pagina wint? Voor mij alleen, en voor een klein team met één duidelijke redacteur, werkt het vandaag al. De governance voor tien gelijktijdige schrijvers is werk in uitvoering.

Het rendement zit intussen niet in sneller zoeken maar in scherper zien. Toen ik na een CRM-traject bij de ene klant een vergelijkbaar proces bij een tweede tegenkwam, hoefde ik mijn projectgeschiedenis niet opnieuw uit te leggen. De wiki bevatte het patroon, de AI paste het toe op de nieuwe context en zag verschillen die ik allang vergeten was.

Dat is uiteindelijk wat een gedeelde kennisbank tot fundament maakt. Elke eerdere generatie kennissystemen was een plek waar werk naartoe moest, na het echte werk, door mensen die betere dingen te doen hadden. Dit is de eerste generatie waarin de kennisbank zelf meewerkt: hij leest mee, schrijft bij en wordt beter van elke sessie. Een fundament dat terugduwt is geen archief meer. Het is een collega die nooit van project wisselt.