← terug

10 juni 2026

Een supervisor-agent voor al mijn projecten, een kopie van mezelf

Op een willekeurige dinsdagochtend open ik mijn laptop en begint hetzelfde ritueel als altijd. Monitoring checken van het AI-platform. Logs bekijken van de LLM-router. Kijken of er dependency-alerts zijn binnengekomen. Even controleren of die ene klantomgeving nog draait. Een mailtje beantwoorden over een factuur. Pas daarna begint mijn echte werkdag.

Ik draai ruim tien producten en projecten in mijn eentje, en dat ochtendritueel is de prijs daarvan. Niet één van die taken is moeilijk. Maar samen vreten ze het waardevolste dat ik heb: aandacht. En al een tijdje knaagt er een gedachte: alles wat ik op zo'n ochtend doe is beschrijfbaar. Ik kijk naar signalen, vergelijk ze met wat normaal is, en beslis of er iets moet gebeuren. Dat is precies het soort werk waar je een agent voor zou bouwen.

Dus dat ben ik aan het doen: een supervisor-agent die over al mijn projecten waakt. Een soort kopie van mezelf, maar dan alleen het deel dat 's ochtends de boel naloopt. In deze blog leg ik uit hoe zoiets technisch in elkaar zit, waarom het iets anders is dan een stapel cronjobs, en welke vragen er gaan schuren zodra zo'n agent echt dingen mag doen.

Wat ik wil dat hij doet

Het takenpakket is op papier simpel:

Kortom: de eerste lijn. Ik blijf de tweede lijn, en alles wat lijkt op een productkeuze blijft sowieso bij mij.

Hoe zoiets technisch in elkaar zit

Onder de motorkap is een supervisor-agent geen magisch wezen. Het is een hoofdagent (een taalmodel in een loop, met tools en instructies) die periodiek wakker wordt en werk uitdeelt aan subagents.

De hoofdagent is de coördinator. Hij krijgt een vaste hoofdinstructie: dit zijn de projecten, dit zijn je taken, dit mag je zelf, hiervoor moet je toestemming vragen. Hij houdt het overzicht, bepaalt wat aandacht nodig heeft en schrijft uiteindelijk het rapport.

De subagents doen het eigenlijke werk, per project of per taak. Eén subagent kijkt naar de logs van de router. Een ander draait de dependency-check voor het AI-platform. Weer een ander controleert backups. Dat opsplitsen is geen architectuur-hobbyisme, het is noodzaak: een model heeft een beperkt werkgeheugen (het contextvenster), en tien projecten met logs, configuraties en historie passen daar niet tegelijk in. Subagents werken elk in hun eigen afgebakende context en geven alleen hun conclusie terug aan de hoofdagent.

Dan de toegang, want zonder handen kan de agent niets. In de praktijk betekent dat: leesrechten op repositories, toegang tot servers via SSH of een agent-omgeving die daar draait, toegang tot monitoring-APIs, en heel beperkte schrijfrechten. Hier zit meteen de belangrijkste ontwerpkeuze: je geeft de agent niet jouw rechten, je geeft hem zijn eigen account met zo min mogelijk rechten. Een eigen deploy-key per repository, een eigen gebruiker op de server, een API-sleutel die alleen kan lezen. Alles wat hij doet is daardoor herleidbaar en intrekbaar.

Per project komt er een vast instructiebestand: wat is dit project, wat is normaal gedrag, hoe deploy je, wat zijn bekende eigenaardigheden, wat mag je hier wel en niet aanraken. Dat klinkt als overhead, maar het is hetzelfde document dat je voor een menselijke collega zou schrijven. Sterker nog, het schrijven ervan dwong me om dingen op te schrijven die alleen in mijn hoofd zaten. Dat alleen al was de moeite waard.

En dan geheugen. Een taalmodel onthoudt zelf niets tussen sessies. Dus moet je dat organiseren: een logboek van wat de agent eerder zag en deed, en een notitiebestand per project dat hij zelf bijwerkt. Vorige week schijf vol op server drie, opgelost door oude logs te rotaten. Die notitie zorgt er de volgende keer voor dat hij niet opnieuw vanaf nul redeneert, en dat het wekelijkse rapport context heeft: dit is de derde keer deze maand, misschien is er iets structureel mis.

Waarom dit geen stapel cronjobs is

Een terechte vraag, want monitoring en automatische herstarts bestaan al decennia. Het verschil zit in twee dingen.

Ten eerste: een cronjob voert uit, een agent beoordeelt. Een cronjob die elke nacht een service herstart als die down is, doet dat ook als de service down is omdat de database corrupt raakt, en maakt het dan erger. Een agent kan eerst de logs lezen, zien dat dit geen gewone crash is, en besluiten om niet te herstarten maar mij te waarschuwen. Dat beoordelingsvermogen is precies wat je met klassieke automatisering niet krijgt, of alleen tegen de prijs van eindeloos veel if-statements die je toch nooit compleet krijgt.

Ten tweede: een cronjob kent één taak, een agent kent de samenhang. Tien projecten betekent bij mij ergens tussen de veertig en vijftig losse checks. Als cronjobs zijn dat vijftig eilandjes die elkaar niet kennen. Een supervisor ziet dwarsverbanden: dat de kostenpiek bij de router samenvalt met een nieuwe klant op het platform, en dat dat dus geen probleem is maar groei.

Eerlijk is eerlijk: voor de saaie, voorspelbare checks blijven cronjobs en klassieke monitoring gewoon beter. Goedkoper, sneller, deterministischer. De agent vervangt ze niet, hij zit erboven. De alerts van de bestaande monitoring zijn zijn input, niet zijn concurrent.

De lastige vragen

Tot zover de techniek. Nu het deel waar het echt om gaat.

Hoeveel mag hij zelf beslissen? Mijn antwoord is op dit moment: weinig, en alleen omkeerbaar. Een service herstarten kan, want dat kan ik ongedaan maken door niets te doen. Een patch-update met groene tests kan, want die kan ik terugdraaien. Maar alles wat data raakt, alles wat klanten raakt, en alles wat geld kost boven een drempel, gaat langs mij. De vuistregel die ik hanteer: de agent mag zelfstandig doen wat ik een stagiair in week één zonder overleg zou laten doen. Niet meer.

Hoe voorkom je dat hij stilletjes dingen sloopt? Dit is het engste scenario, en terecht. Niet de agent die crasht, maar de agent die elke dag kleine dingen "verbetert" die je pas weken later opmerkt. Daar helpen drie dingen. Eén: alles via dezelfde route als een mens, dus wijzigingen aan code via een branch en een pull request, nooit direct op productie. Twee: een logboek dat de agent niet zelf kan aanpassen, zodat er altijd een onafhankelijk spoor is van wat hij deed. Drie: het wekelijkse rapport als verplicht nummer, waarin elke actie staat, ook de geslaagde. Een agent die alleen rapporteert wat misging, leert je precies verkeerd kijken. En daarbovenop geldt de gewone discipline die je toch al wilt: backups die getest zijn, en infrastructuur die je opnieuw kunt opbouwen vanuit configuratie.

Er is nog een risico dat hier vaak vergeten wordt: prompt injection. Mijn agent leest logs, mails en issue-teksten, en dat is allemaal tekst die deels door buitenstaanders geschreven kan zijn. Tekst die het model leest, kan het model proberen te sturen. Daarom is de strakke rechtenscheiding geen detail maar de kern: ook als iemand de agent overhaalt om iets geks te willen, moet hij het simpelweg niet kúnnen.

En dan de vraag die meer filosofisch klinkt dan hij is: blijft het jouw bedrijf als een agent het runt? Mijn antwoord: ja, zolang de agent uitvoert en jij beslist. De grens ligt niet bij hoeveel werk de agent doet, maar bij of jij nog begrijpt en kunt verdedigen wat er draait. Op het moment dat ik het wekelijkse rapport alleen nog scan in plaats van lees, of een voorgelegde beslissing goedkeur zonder hem te snappen, is er iets verschoven. Dan run ik geen bedrijf meer met een agent, dan kijk ik toe bij een bedrijf dat zichzelf runt. De handtekening onder klantcontracten blijft van mij, dus dat begrip is geen luxe maar de baseline.

Wat vandaag al werkt en wat wensdenken is

Tijd voor eerlijkheid, want hier wordt veel overdreven.

Wat vandaag al goed werkt: het lees- en rapporteerwerk. Een agent die logs, alerts en advisories doorneemt en daar een leesbaar dagrapport van maakt, is met de huidige modellen en agent-tooling gewoon te bouwen. Net als de voorbereide beslissing: hier is het probleem, hier is de context, dit zijn je opties. Dat scheelt mij nu al merkbaar ochtendwerk.

Wat werkt met begeleiding: de kleine fixes. Dependency-updates met tests erachter, herstarts, opschoonwerk. Het lukt vaak, maar niet altijd, en de mislukkingen zijn soms creatief. Dit is het terrein waar je strakke kaders en omkeerbaarheid nodig hebt, en waar je begint met voorleggen voordat je iets autonoom maakt.

Wat nog wensdenken is: de echte kopie van mezelf. Een agent die wekenlang zelfstandig draait, context vasthoudt over maanden, zelf prioriteiten stelt over tien projecten heen en daarbij consistent goede afwegingen maakt. Daarvoor zijn de modellen nog te wisselvallig en is het geheugenprobleem nog te onopgelost. Wie je vertelt dat zijn bedrijf al volledig door agents wordt gerund, laat meestal het deel weg waar hij zelf dagelijks bijstuurt.

Tot slot

De supervisor-agent is geen kopie van mij. Het is een kopie van mijn dinsdagochtend, en dat is precies genoeg. Het saaie, beschrijfbare waakwerk gaat naar de agent. Het beoordelen, kiezen en verantwoordelijkheid dragen blijft hier.

Wie hier zelf mee wil beginnen: begin niet bij autonomie, begin bij rapportage. Een agent die alleen mag kijken en vertellen kan weinig slopen en leert je vanzelf waar hij te vertrouwen is. Geef hem eigen, minimale rechten in plaats van de jouwe. Schrijf per project op wat normaal is en wat verboden terrein is. En lees zijn rapporten echt, want op de dag dat je dat niet meer doet, is niet de agent het probleem. 

↘︎ ALLE ARTIKELEN