Op een doordeweekse ochtend kreeg ik in tien minuten 344 alarmberichten op mijn telefoon. Niet omdat er 344 dingen kapot waren. Er was één ding kapot, en mijn eigen automatisering vond het nodig om dat per gebeurtenis te melden. Dat was het moment waarop ik besefte: agents laten dráaien is niet het moeilijke deel. Ze laten draaien zonder dat ze je gek maken, je portemonnee leegtrekken of elkaars werk dupliceren: dát is het echte werk.

Inmiddels draaien er zo’n dertig Ai-agents op mijn homeserver, 24/7, naast al het andere werk in mijn bedrijven. Geen demo, geen proof-of-concept: ze doen elke dag echt werk. In dit stuk vertel ik wat er draait, welke architectuur het betaalbaar en veilig houdt, en minstens zo belangrijk: wat er misging.

Wat draait er eigenlijk?#

“Dertig agents” klinkt indrukwekkender dan het is. Het zijn geen dertig robots die zelfstandig beslissingen nemen over mijn leven. Het zijn dertig afgebakende taken, elk met een eigen opdracht, eigen grenzen en een eigen ritme. Grofweg vijf categorieën:

  • Monitoring en herstel. Agents die in de gaten houden of alles nog draait: containers, services, schijfruimte. Kleine, omkeerbare problemen lossen ze zelf op; de rest melden ze.
  • Pipeline-herstel. Als een geautomatiseerde test-pipeline rood wordt, kijkt een agent naar de foutmelding, reproduceert het probleem en stelt een fix voor. Als voorstel, nooit stilletjes rechtstreeks in de hoofdcode.
  • Code-review. Elke wijziging in mijn projecten wordt automatisch nagelopen op veiligheidsproblemen en slordigheden, met concrete verbetervoorstellen.
  • Boekhoudcontrole. Een agent die maandelijks een reeks controles draait die een accountant ook zou doen (balans, BTW-aansluiting, gekke afwijkingen), maar strikt read-only. Hij wijzigt nooit iets, hij wijst alleen aan. En hij vervangt je boekhouder of accountant niet; het is een extra paar ogen.
  • Chat en communicatie. Vragen die binnenkomen worden getrieerd, simpele vragen beantwoord, de rest netjes doorgezet naar mij.

Daarnaast draaien er een paar hobby-agents: op footballoracle.nl bewaakt en verbetert een set agents dagelijks een voorspelsite, en via Home Assistant stuurt vergelijkbare logica mijn energieverbruik aan. Andere domeinen, exact hetzelfde recept.

De architectuur die het betaalbaar houdt#

De grootste misvatting over Ai-agents: dat het duur móét zijn. Mijn belangrijkste besparing kwam niet van een slimmer model, maar van een dom script.

De gratis poortwachter. Een van mijn agents draaide oorspronkelijk vijftien keer per dag met een duur Ai-model, of er nou iets aan de hand was of niet. De fix was geen Ai, maar een simpel bash-script dat gratis voorwerk doet: is er überhaupt iets veranderd? Is er een signaal? Pas als het antwoord ja is, wordt de dure agent gestart. In pseudocode is de hele truc drie regels:

# Gratis voorcheck: start de dure Ai-agent alleen bij een echt signaal
if [ -n "$(nieuwe_events_sinds_vorige_run)" ]; then
  start_ai_agent
fi

Resultaat: van vijftien dure runs per dag terug naar één tot acht, met dezelfde dekking voor de signalen die vooraf benoemd zijn. Hetzelfde principe pas ik toe op security: gratis scanners draaien wekelijks, en alleen bij een kritieke bevinding komt de dure Ai-audit in actie.

Goedkoop tenzij. De tweede besparing: niet elke stap verdient het duurste model. De keten ziet er zo uit: een cron-taak (gratis) triggert een voorcheck-script (gratis), dat bij signaal een goedkope classifier aanroept (centen), en pas als díe zegt “dit is echt iets” wordt het dure model gespawnd (dubbeltjes tot euro’s). Verreweg de meeste runs komen nooit voorbij de eerste twee stappen. Het dure model doet alleen wat het dure model waard is: nadenken.

Tick-discipline. Elke agent draait volgens hetzelfde vaste ritme, dat ik een “tick” noem: lees de huidige stand van zaken, check wat er te doen is, doe het werk, en werk de administratie in één keer atomisch bij. Dat klinkt bureaucratisch, maar het voorkomt de twee klassieke agent-problemen: een agent die vergeten is wat hij vorige keer deed, en twee agents die tegelijk aan hetzelfde sleutelen.

De architectuur die het veilig houdt#

Betaalbaar is één ding. Maar dertig stukken software die zelfstandig handelen op een server waar ook mijn administratie op staat: dat vraagt om expliciete grenzen. Ik gebruik daarvoor een stoplichtmodel:

  • Groen: mag de agent zelf. Voorwaarde: de actie is omkeerbaar en de schade bij een fout is klein. Een gecrashte container herstarten, een logbestand opruimen.
  • Geel: mag de agent doen, maar hij méldt het altijd. Ik hoor het achteraf en kan ingrijpen.
  • Rood: nooit zonder mens. Productie-deploys, betalingen, alles wat onomkeerbaar is of externe partijen raakt.

De belangrijkste regel daarbij: schrijf die grenzen op vóórdat je bouwt, niet erna. En log alles: elke actie, elke beslissing, elke keer dat een agent besloot om níks te doen.

Tip: begin met álles op rood en verplaats een taak pas naar groen nadat die een paar weken foutloos en omkeerbaar is gebleken. Groen moet een agent verdienen, niet cadeau krijgen.

Dat is overigens geen eigen uitvinding. Wat ik bij grote techorganisaties en in vakliteratuur terugzie wijst dezelfde kant op: vrijwel niemand draait volledig autonome systemen in productie. De gangbare praktijk is advies-modus, met enkele goed afgebakende categorieën waar auto-fixes wél mogen. Bijbehorende vangrails die ik heb overgenomen: check de toestand vlak vóór je handelt (is het probleem er nog?), een klein maximum aan herstelpogingen, en een circuit-breaker: na een paar mislukte fixes stopt de agent met fixen en gaat hij alleen nog observeren en escaleren. En cruciaal: verifieer ná de actie of het probleem echt weg is, niet alleen of het commando slaagde.

Het patroon dat alles samenvat, en dat identiek werkt van mijn thermostaat tot mijn deploy-straat:

Ai beslist wát er moet gebeuren, dom scripting voert het uit.

Eén component mag schrijven naar het kritieke systeem, alles is omkeerbaar en gelogd, en escalatie naar mijn telefoon gebeurt alleen bij echte twijfel. Autonome Ai is architectuur, geen tool-aankoop.

Wat er misging (en wat dat leerde)#

Nu het eerlijke deel. Drie fouten die me echt iets gekost hebben.

De lege runs. Door een bug in een aansturend script werd een van mijn agents gestart zonder doelwit: geen code-wijziging om te reviewen, gewoon een lege opdracht. De agent startte netjes op (met het dure model), keek rond, concludeerde “niets te doen” en stopte weer. Elke keer een betaalde Ai-call voor precies nul werk. Toen ik het ontdekte: 181 van de 226 runs in zeven dagen waren leeg. Tachtig procent verspilling, wekenlang onzichtbaar, want de agent “draaide toch prima”. De les: zet een guard op de input vóórdat je iets duurs start, en audit regelmatig wat je agents daadwerkelijk gedaan hebben, niet of ze gedraaid hebben.

De PR-stapel. Mijn CI-hersteller deed zijn werk uitstekend: falende pipeline gezien, fix gemaakt, voorstel geopend. Maar niemand, mens noch machine, had de taak om die voorstellen af te ronden. Dus zag de agent bij de volgende ronde dezelfde falende pipeline, en opende hij nóg een voorstel. En nog een. Twaalf duplicaten later begreep ik het patroon: een agent die werk produceert dat door een andere stap geconsumeerd moet worden, loopt vast zodra die afsluitstap ontbreekt. Sindsdien ontwerp ik elke agent met een expliciete closure-conditie: wie of wat maakt dit af, en check vóór je begint of er niet al open werk ligt voor exact dezelfde bevinding.

De 344 berichten. Terug naar die ochtend uit de opening. De oorzaak was een ontwerpkeuze die iedereen intuïtief maakt: één gebeurtenis, één melding. Bij één incident dat honderden events genereert, betekent dat honderden meldingen. De herbouw: alle events gaan eerst naar een logopslag, en elk kwartier clustert een goedkope classifier de boel (in dat geval 236 events terug naar 4 clusters), en er gaat maximaal één bericht uit, alleen bij een echt signaal. Nooit meer melden-per-event.

De overkoepelende les uit alle drie: “draaien” is niet hetzelfde als “effect hebben”. Daarom draait er inmiddels ook een agent die de agents bewaakt: wekelijks classificeert die per agent wat er speelt: dood, ruisproducent, vastgelopen, of juist een trend die aandacht verdient. Het leidende principe van die bewakingslaag heb ik letterlijk in de instructies gezet: meld niet wat je zelf kunt oplossen, en los niets op wat je niet begrijpt. Het doel is niet meer automatisering; het doel is een stillere telefoon.

Wat betekent dit voor jouw bedrijf?#

Je hoeft geen dertig agents te draaien. Sterker: begin daar vooral niet mee. Maar de patronen hierboven schalen naar beneden verrassend goed, juist voor MKB:

  1. Begin met de poortwachter, niet met de Ai. Vraag je bij elke Ai-toepassing af: kan een gratis script eerst beslissen óf de Ai nodig is? Dat ene principe halveert vaak in z’n eentje je kosten.
  2. Teken het stoplicht vóór je bouwt. Wat mag de automatisering zelf, wat mag ze doen-en-melden, en waar moet altijd een mens tussen zitten? Een half A4’tje volstaat, maar schrijf het op voordat het misgaat, niet erna.
  3. Meet effect, niet activiteit. Een agent die honderd keer per week draait klinkt productief. De vraag is: wat is er deze week daadwerkelijk opgelost dat anders was blijven liggen?
  4. Ontwerp het falen vooraf. Elke automatisering gaat een keer stuk. De vraag is niet óf, maar of jij het dan merkt via één rustig bericht of via 344.

Zelf aan de slag#

De grens tussen groen, geel en rood is voor mij het fundament onder alles wat hierboven staat. Ik heb dat model uitgewerkt in het Ai-stoplicht: een gratis download waarmee je voor jouw processen bepaalt wat je een Ai-agent wél en niet uit handen geeft, inclusief de vangrails per categorie. Dat vind je op deze site bij de downloads.

Wil je liever sparren over jouw specifieke situatie, waar automatisering in jouw bedrijf het meeste oplevert en waar de risico’s zitten? Kijk dan op de consulting-pagina hoe ik werk. Geen dertig agents als belofte, wel een nuchter antwoord op de vraag waar je moet beginnen.