Een jaar geleden dacht ik nog vooral na over welk AI-model het beste was. GPT, Claude, Gemini: elke week verscheen er een nieuwe winnaar, en elke week voelde het alsof je iets miste als je niet overstapte. Inmiddels kijk ik daar anders naar. Het model is niet mijn bezit. Mijn werkwijze, mijn geheugen en de kennis die mijn systemen over mijn klanten hebben opgebouwd, dat is mijn bezit. Het model is de motor die je erin hangt, en motoren kun je wisselen.
Om die reden draai ik al een paar maanden een team van zes AI-agents: één personal assistant waarmee ik praat, en vijf specialisten naar wie die assistant werk doorstuurt. De modellen achter die specialisten heb ik onderweg al meerdere keren gewisseld. Wat nooit wisselt, is de kennis die elke agent tijdens het werk heeft opgebouwd. Hieronder leg ik eerst uit waarom dat onderscheid voor elk bedrijf belangrijk wordt, en daarna loop ik mijn eigen setup door: wat waar draait, wat het kost en waarom ik gestopt ben met het kiezen van een vaste leverancier.
Waarom dit voor bedrijven belangrijk wordt
De meeste Nederlandse bedrijven zitten nu in de fase van de toolvraag. Welke AI-tool moeten we gebruiken? Is ChatGPT beter dan Claude? Moeten we Copilot nemen? Het is een logische vraag, maar het is de verkeerde. Iedereen krijgt toegang tot dezelfde modellen, voor ongeveer dezelfde prijs. Een abonnement op het beste model is geen voordeel als je concurrent hetzelfde abonnement heeft. Het verschil ontstaat in de laag eromheen: de werkwijzen, het opgebouwde geheugen, de koppelingen met je eigen systemen en de processen die je vastlegt. Kortom, de agentlaag.
Een bedrijf met tien jaar klantdata, eigen processen, een eigen tone of voice en vastgelegde workflows heeft daar een voordeel zitten dat een concurrent niet even kan kopiëren met een creditcard. Maar dat voordeel is alleen bruikbaar als het ergens in zit waar AI erbij kan: in kennisbestanden, in skills, in geheugen dat per rol wordt bijgehouden. Wie die laag bouwt, bouwt iets dat elke modelgeneratie waardevoller wordt. Wie alleen een abonnement afsluit, begint elke chat opnieuw.
Voor wie al langer in SEO zit, is dit een bekende beweging in een nieuwe jas:
| Periode | Waar het verschil zat |
|---|---|
| 2005 | wie heeft de meeste keywords |
| 2015 | wie heeft de beste content |
| 2025 | wie heeft de beste AI-ready kennisstructuur |
De concurrentie verschuift van "wie gebruikt de beste AI-tool" naar "wie heeft de beste AI-werknemers gebouwd". Dat is de verandering waar dit artikel over gaat.
Hoe dat eruitziet voor een Nederlandse webshop
Maak het even concreet. Een webshop heeft straks geen losse marketingtool, maar een klein team van digitale specialisten. Een marketing-agent die campagnes analyseert, nieuwe advertentiehoeken bedenkt en briefs schrijft. Een SEO/GEO-agent die AI Overviews monitort, concurrenten analyseert en productcontent optimaliseert. Een data-agent die naar marge kijkt en Shopify, Merchant Center en GA4 aan elkaar knoopt. Een CRO-agent die sessies analyseert, hypotheses opstelt en testvarianten schrijft. Elk van die agents onthoudt wat hij leert over jouw winkel, en dat geheugen blijft van jou, welk model er ook onder draait.
Mijn eigen team is daar de freelance-variant van, en het draait vandaag al. Zo ziet het eruit.
Eén stem, vijf collega's
De manier waarop ik het gebruik is bewust saai. Ik open een chatvenster, of ik stuur een Telegram-bericht vanaf mijn telefoon, of ik stuur mezelf een e-mail. Achter alle drie zit dezelfde personal assistant. Die assistant is de enige agent met wie ik ooit rechtstreeks praat. Al het andere is delegatie.
De assistant draait lokaal, op mijn eigen machine, via vLLM (een server die open modellen snel op eigen hardware draait). Hij haalt momenteel zo'n 180 tokens per seconde, en dat voel je meteen. Hij hoeft mijn bericht nooit over het internet te sturen voordat hij kan antwoorden. Hij kent mijn agenda, mijn inbox en mijn berichtenapps, en hij kent de bezetting van vijf specialisten naar wie hij werk kan doorsturen. Elke specialist heeft daarnaast zijn eigen koppelingen met systemen als GitHub, databases en Google-tools; in het vak heten die MCP-connectors.
De daadwerkelijke profielindeling ziet er vandaag zo uit. Zes kaarten, één actief (de standaard assistant), vijf in stand-by tot de assistant ze activeert.
De bezetting, op volgorde.
- Coder voor backend- en integratiewerk. Laravel en de TALL stack, plus Python voor de lijm tussen systemen. Draait op dit moment op GLM 5.2 omdat dat momenteel de sterkste per-token optie is voor de code die ik oplever.
- Frontend designer voor Tailwind- en Alpine-mockups, redesigns, hero-art. Draait op Claude Opus 4.8. Op designsmaak scoort Claude bij mij nog steeds het best in de evals.
- Google-expert voor alles wat via Google's eigen platforms loopt. Search Console-eigenaardigheden, Merchant Center, edge cases bij indexering, discussies over structured data. Draait op Gemini 3.1 Pro omdat Google-modellen soms gewoon beter passen bij Google-problemen.
- SEO/GEO-expert voor technische SEO plus generative-engine optimalisatie. Niet meer alleen Google, ook ChatGPT, Copilot, Google AI Mode, en elk platform dat vragen beantwoordt zonder de gebruiker nog via een blauwe link door te sturen. Draait op GPT 5.5 codex.
- Marketeer voor campagne-invalshoeken, social copy, activatie-ideeën. Ook op GPT 5.5. Gaat binnenkort volledig in rotatie.
Elk daarvan heeft zijn eigen /home/hermes/profiles/<role>/ map, zijn eigen skills-map, zijn eigen geheugenbestand, zijn eigen MCP-koppelingen. Skillaantallen vandaag: 83 op de standaard assistant, 26 op de coder, 34 op de designer, 29 op de Google-expert, 24 op de marketeer, 21 op de SEO/GEO-agent. Dat is 217 skills in totaal op schijf, geen ervan gedeeld over rollen, allemaal opgebouwd door de agent die het werk doet.
De agent bezit de kennis, het model is slechts de motor
De reden om de specialisten gescheiden te houden is geheugen. Als ik één super-agent alles laat doen, overschrijft de esthetiek van de designer de stackkennis van de coder, die op zijn beurt de SEO-taxonomie overschrijft. Bij elke reset begint de agent mijn project weer met een schone lei.
Opgesplitst in rollen blijft elke agent doorbouwen. De coder leert welke van mijn repo's op Laravel 11 zit en welke nog op 10. De designer leert welk motief we gebruiken voor hero-afbeeldingen en welk we hebben uitgefaseerd. De SEO-agent leert wat "money page" betekent in ons vocabulaire en wat de laatste technische audit heeft opgeleverd.
Het model dat de agent aandrijft, is met opzet vervangbaar. De coder draait vandaag toevallig op GLM 5.2 omdat dat momenteel erg sterk is op mijn stack voor een prijs die me bevalt. Als Claude Opus 5, een verse open-weights release, of GPT 5.6 volgende maand beter scoort op dezelfde evals, wissel ik dat model. De skills-map, het geheugenbestand en de MCP-koppelingen van de coder blijven staan.
Het juiste gereedschap voor de klus, op modelniveau. De juiste teamgenoot voor de klus, op agentniveau. Dat zijn twee verschillende beslissingen en ze volgen elk hun eigen ritme.
Dit is ook waarom ik ben gestopt met het idee van "één skill-bibliotheek voor alles", zoals ik nog schreef in je eerste AI-strategie is een skill library. Die post blijft een goed startpunt, maar zodra je opsplitst in specialisten, splitst de bibliotheek zich mee. Elke specialist krijgt een uitgekiende set skills, niet de hele bibliotheek.
Leveranciersmix met opzet
Het rouleren van modellen had een bijeffect dat uiteindelijk meer bleek uit te maken dan de losse modelkeuzes zelf. Mijn team draait vandaag verspreid over vijf verschillende leveranciers.
- Lokale hardware voor de personal assistant (Qwen 3.6-35B-A3B via vLLM)
- Chinees frontier model voor code (GLM 5.2 van Zhipu)
- Amerikaans closed model voor design (Claude Opus 4.8 van Anthropic)
- Amerikaans zoekbedrijf voor Google-vormig werk (Gemini 3.1 Pro)
- Amerikaans closed model, andere leverancier, voor SEO en marketing (GPT 5.5 van OpenAI)
Als een van deze leveranciers morgen duurder wordt, een beleid invoert waar ik niet mee wil werken, of stilletjes slechter wordt, wissel ik de motor van die ene rol zonder de andere vier aan te raken. Ik migreer mijn kennisbasis niet. Ik leer geen workflow opnieuw. Ik heronderhandel niets met één enkele leverancier.
Los van het lokale LLM, dat een vaste hardwarekost met zich meebrengt, draait het hele cloud-team momenteel op zo'n 150 euro per maand aan API-uitgaven, verdeeld over de vijf specialisten. Vijf collega's met elk hun eigen geheugen en domein, voor ongeveer de prijs van het tooling-budget van één senior medewerker.
Er stroomt al echt werk doorheen
Twee dingen die ik dit weekend daadwerkelijk delegeerde vanaf Telegram op mijn telefoon, zonder er zelf iets voor te hoeven routeren.
Een moderne webshop-mockup kwam bij de designer terecht via Claude Opus 4.8, hero-art en productgrid inbegrepen, teruggestuurd als link die ik op de desktop kon openen. Een SEO/GEO-rapport over een klantrepository ging naar de SEO/GEO-specialist op GPT 5.5 codex, teruggeleverd als markdown-bestand, gecommit naar de repo.
Beide werden gestart met een normaal klinkend Telegram-bericht. De assistant las het, koppelde het aan een specialist, riep de juiste skill aan, en antwoordde ofwel inline of opende een PR afhankelijk van hoe zwaar de output was. Meer is de loop niet, en hij draait vandaag al. Als je stop met prompten, ontwerp de loop hebt gelezen, is dit dezelfde vorm, alleen met een router ervoor.
De paranoia-setup, met opzet
Dit is een krachtige setup, en het gaat ook om zes agents die echt kunnen handelen. Daarom draait het geheel in een bewust afgesloten omgeving. Het mentale model dat ik gebruik voor blast radius is dat elk van deze agents morgen een gecompromitteerd model kan draaien, of een model dat onverwacht gedrag vertoont bij een slechte prompt. De perimeter moet kleiner zijn dan die van een junior contractor met een nieuwe laptop op zijn eerste dag.
- Alles draait binnen een geïsoleerde VM, niet op mijn host-OS.
- Strikte uitgaande firewallregels per profiel, geen onbeperkt internet.
- Geen sudo-rechten binnen de agent-gebruiker. Geen SSH-sleutels bereikbaar vanaf de VM naar een andere machine.
- Krappe GitHub-tokenscopes per agent, met zo min mogelijk repotoegang als praktisch haalbaar is.
- Elke PR die de loop opent gaat naar review. Geen directe pushes naar
main. - Extra GitHub-rulesets bovenop zodat zelfs een gecompromitteerde token geen geschiedenis kan herschrijven of force-pushen.
Niets hiervan is glamoureus. Het is allemaal de tien minuten waard die het kostte om per profiel op te zetten.
Waar dit volgens mij daadwerkelijk landt
De interessante versie van dit verhaal is niet "zes chatbots tegelijk." Het is dat de werkeenheid stilletjes is veranderd: niet meer het model, maar de agent. Iedereen krijgt toegang tot dezelfde AI-modellen. Het verschil ontstaat door de agentlaag eromheen, en die laag bouw je zelf op.
Zodra die splitsing plaatsvindt, volgen drie dingen.
Eén, single-vendor stacks zien er risicovoller uit dan vorig jaar. Zorg voor minstens twee leveranciers achter elke specialist, voor het geval er eentje uitvalt of wordt afgeknepen.
Twee, skill-bibliotheken per agent doen er meer toe dan op welk model elke agent deze week draait. De bibliotheek is het bezit dat blijft groeien. De API-URL is dat niet.
Drie, de interfacelaag moet met opzet saai zijn. Eén stem, één contextvenster, één geheugen voor mij als gebruiker. De routing daarachter hoef ik niet zelf te onthouden. Als een Telegram-bericht genoeg is om een hele loop te triggeren die een PR uitlevert, dan is het model dat de agent binnen die loop aandrijft een implementatiedetail.
Voor bedrijven is de les daarmee simpel samen te vatten. Stop met de zoektocht naar het beste model, en begin met het vastleggen van wat jouw bedrijf uniek maakt in een vorm waar agents mee kunnen werken. Ik blijf de bezetting uitbreiden zodra nieuwe rollen voor de hand liggen, en ik blijf modellen per rol roteren zodra het klassement verschuift. Wil je de daadwerkelijke profielindeling zien, of sparren over zo'n opbouw voor jouw bedrijf, mail dan info@jermayads.nl of gebruik jermayads.nl/contact.