Op LinkedIn kwam ik een post van GenAI Works tegen, met een infographic die in allerlei varianten rondgaat. De redenering is deze: een taalmodel kan op zichzelf drie dingen niet. Het kan niet bij je tools en systemen, het kent jouw documenten niet, en het kan alleen antwoorden, niet handelen. Voor elk van die gaten bestaat een aparte techniek: MCP, RAG en skills. Volgens de post halen veel mensen die drie door elkaar, alsof je moet kiezen, terwijl ze elk een ander deel van hetzelfde probleem oplossen. Pas wie ze combineert, krijgt een assistent die ophaalt, beslist en uitvoert.
Ik gebruik alle drie. Toch ziet mijn systeem er anders uit dan de indeling. Hieronder eerst de indeling zoals die bedoeld is, voor wie de termen niet kent. Daarna mijn assistent, en dan de drie lagen naast elkaar.
De indeling in drie lagen
Verbinding. Een taalmodel kan uit zichzelf niet bij je agenda, je database of je tools. Vroeger bouwde je voor elke koppeling een apart stukje code. MCP is een standaard die dat vervangt: een vaste afspraak over hoe een model en een dienst met elkaar praten. Elke dienst die zich aan die afspraak houdt, kan het model meteen gebruiken, zonder eigen koppeling. Het model vraagt, de dienst antwoordt, het model gaat verder.
Kennis. Een model kent je documenten niet, en wat het wel weet is van vóór zijn trainingsdatum. RAG lost dat op: je knipt je documenten in stukjes, zet elk stukje als reeks getallen in een vectordatabase, en bij elke vraag worden de stukjes erbij gepakt die het dichtst bij de vraag liggen. Het antwoord komt dan uit jouw materiaal. De post belooft er meteen bij: geen hallucinaties.
Uitvoering. Van antwoorden naar doen. Een skill laat het model code draaien, bestanden lezen en schrijven, een dienst aanroepen of een reeks stappen afwerken. Het model kiest per vraag: beantwoorden, of een skill inzetten.
De indeling sluit af met een waarschuwing: de meeste mensen kennen het verschil tussen de tools, weinigen weten hoe ze die in de hand houden. Daar kom ik op terug.
Mijn assistent
Kai is de assistent die ik ruim een jaar bouw. Hij draait op Claude, op twee plekken: in de chat, en op mijn laptop als Claude Code, waar hij bij bestanden en scripts kan. Hij beheert mijn takenlijst in Notion, publiceert mijn site en doorzoekt een archief van twee jaar AI-gesprekken. Hoe hij ontstond, staat in een eerder artikel.
Leg je de indeling naast Kai, dan klopt één laag precies, doe ik er twee bewust anders, en ontbreekt er een vierde. Eerst het overzicht, dan per laag.
- Verbinding. De indeling: één standaardkoppeling voor al je tools. Bij Kai: MCP voor het gesprek, eigen webhooks voor het bulkwerk.
- Kennis. De indeling: stukjes in een vectordatabase. Bij Kai: een wiki van tekstbestanden, zoeken op woorden, en een citeerregel.
- Uitvoering. De indeling: skills die code draaien. Bij Kai: skills als vaste werkwijze.
- Controle. De indeling: een waarschuwing, geen laag. Bij Kai: code die nee zegt.
Verbinding: klopt, met een omweg
De indeling zegt: één standaardkoppeling voor alles. Kai gebruikt MCP de hele dag: met Notion, met mijn beeldgenerator, met mijn automatiseringsserver. Voor het gesprek werkt het goed. "Wat is de status van die ene taak" is één aanroep en één antwoord.
Het bulkwerk is een ander verhaal. In april schreef ik het voor mezelf op, toen ik uitzocht waarom mijn assistent zo traag was op overzichten: de koppeling met Notion geeft bij een zoekopdracht alleen titels terug, geen inhoud. Een statusoverzicht van tien taken kost daardoor elf aanroepen. Bij honderden taken loopt een sessie vast voordat hij klaar is.
De oplossing werd een omweg. Voor alles wat bulk is (overzichten, wekelijkse tellingen, updates in serie) draait een flow op mijn server die de database in één keer uitleest en het antwoord kant-en-klaar teruggeeft. MCP voor het gesprek, webhooks voor het werk. Twee ingangen dus, elk voor wat hij goed kan.
Kennis: geen vectordatabase
De indeling zegt: stukjes in een vectordatabase. Hier wijk ik het meest af. Mijn kennisarchief is een map met tekstbestanden. Twee jaar gespreksgeschiedenis onderin, en daarboven een wiki die de AI zelf samenstelt uit die gesprekken: per onderwerp een pagina met wat erover geleerd is, met verwijzingen terug naar de gesprekken waar het vandaan komt. Zoeken gebeurt op woorden, met een korte routekaart bovenin die zegt waar wat staat. Zo werkt mijn tweede brein.
De vectorlaag heb ik wel overwogen. In juli evalueerde ik een kant-en-klare aanpak die precies dat toevoegt, met een nette benchmark erbij. Het oordeel was verwerpen, om één reden: ik had geen gemeten probleem. Op ruim honderd sterk geïndexeerde pagina's bestond het gat alleen voor vragen in andere woorden dan de tekst zelf, en de routekaart ving dat op. De afspraak sindsdien: pas als ik een reeks gevallen heb waarin de zoekfunctie iets mist dat er wél staat, is er een probleem dat een vectordatabase rechtvaardigt. Die reeks is er nog niet.
En die belofte uit de post, "geen hallucinaties"? Dat is de zin die ik het minst geloof. Ophalen brengt de juiste passage in beeld. Het weerhoudt een model er niet van een dunne passage aan te vullen met iets aannemelijks, en dunne passages zijn precies wat een kennisarchief vol heeft. Bij mij is dat een regel, geen techniek: eerst de zin letterlijk citeren, mét vindplaats, en dan pas antwoorden. Geen citaat, dan is het antwoord "dat staat hier niet". Hoe die regel er kwam, staat in de vijf regels die mijn AI controleerbaar houden.
Uitvoering: skills als vaste werkwijze
De indeling zegt: skills laten de agent code draaien, en in de infographic is een skill een tekstbestand met instructies en acties. Dat laatste klopt bij mij precies. Een skill is een werkwijze in een tekstbestand: hoe een taak wordt aangemaakt, hoe een post wordt beoordeeld, hoe ik beslis of ik een nieuwe tool gebruik. Twintig stuks inmiddels.
Het verschil zit in waar ze voor dienen. Een skill zorgt bij mij dat een klus elke keer op dezelfde manier gaat, ook als ik haast heb. Code draaien is daarbij bijzaak.
De vierde laag: controle
De indeling eindigt met een waarschuwing: weinig mensen weten hoe ze de tools in de hand houden. Daar stopt die. Bij mij zit daar de meeste tijd in.
Controle bestaat bij mij uit code die nee zegt. Een wijziging zonder lijst van bestanden wordt geweigerd, sinds een dag in augustus waarop werk van verschillende sessies door elkaar raakte. Een script gaat pas vast als zijn test aantoonbaar groen draaide. En alles wat van buiten bereikbaar wordt, moet eerst netjes fout gaan zonder sleutel of met rare invoer.
De richting is steeds dezelfde: minder regels die ik moet onthouden, meer regels die het systeem afdwingt.
Dus ja: verbinding, kennis, uitvoering. Combineer ze. Maar zonder controle bouw je een assistent die veel kan en waarvan je achteraf niet weet wat hij deed.
Beoordeel jezelf op vier lagen, op basis van hoe wij tot nu toe samenwerken en wat je over mijn werk weet. Geef per laag drie dingen: wat er nu is, wat ontbreekt, en de kleinste stap die het verschil maakt. 1. Verbinding: met welke systemen kun je nu zelf iets doen, en waar moet ik nog knippen en plakken? 2. Kennis: waar haal je je antwoorden over mijn werk vandaan, en wanneer heb je iets ingevuld dat je niet kon nazoeken? 3. Uitvoering: welke terugkerende taken doe je van begin tot eind, en waar stop je halverwege omdat een stap ontbreekt? 4. Controle: welke afspraken tussen ons bestaan alleen in mijn hoofd, en welke daarvan kun je zelf afdwingen? Sluit af met de ene laag waar ik zou moeten beginnen, en waarom.
De aanleiding is de post 'MCP, RAG, and Skills are not alternatives' van GenAI Works op LinkedIn (september 2026), met de infographic 'MCP vs RAG vs Skills'. De indeling zelf gaat in allerlei varianten rond en is gemeengoed. Alle voorbeelden komen uit mijn systeem: mijn notitie over de Notion-koppeling van april 2026, de tool-evaluatie van 4 juli 2026 en de regels voor het vastleggen van wijzigingen die op 26 augustus 2026 zijn ingevoerd.



