Wat een agentsysteem aan onderhoud kost: 134 dagen gemeten

Wat kost een agentsysteem aan onderhoud?

Het onderhoud van een agentsysteem kost je ongeveer één blik per dag en één opruimbeurt per week. De rekening komt niet in euro's maar in aandacht. Dat is geen schatting. Wij draaien sinds maart 2026 onafgebroken een eigen agentsysteem dat ons bureau helpt runnen, en dat systeem logt alles wat het doet naar één database. Op 16 september 2026 stonden daar 44 duizend gebeurtenissen in, verzameld over 170 dagen. De geplande taken worden sinds 5 mei apart bijgehouden, dus daarvan hebben we 134 dagen aan cijfers.

Wat die cijfers zeggen, in één alinea: van de 1065 geplande runs haalden er 803 de eindstreep en 241 niet. Ruim drie op de vier slaagt dus. Van die 241 mislukkingen was bijna een derde geen storing maar onze eigen kwaliteitspoort die de uitvoer weigerde. Op 54 van elke 100 dagen ging er iets mis dat aandacht vroeg. En de meest voorkomende foutmelding in het hele logboek, goed voor 492 regels, is geen defect maar een tegoed dat op is bij een externe dienst.

Dat is de eerlijke versie. Niet "AI-automatisering is geweldig" en niet "het werkt toch niet". Hieronder staat de volledige meting, inclusief wat er niet uit te halen valt. Als je overweegt iets te automatiseren dat verder gaat dan een abonnement op een tool, is dit de onderhoudsrekening die je vooraf wilt zien. Wie eerst wil weten hoe je een aanbieder kiest, leest hoe je de echte AI-aanbieders van de rest scheidt.

Wat we precies gemeten hebben, en wat het logboek niet weet

Het systeem heet Milo. Het draait op één machine bij ons op kantoor, start taken volgens een vaste planning, en schrijft elke start, elk einde en elke fout weg naar een SQLite-database. Er zit geen meetopstelling omheen die speciaal voor dit artikel is gebouwd. Wij hebben de vragen achteraf op een bestaand logboek losgelaten, en dat is precies waarom de cijfers bruikbaar zijn: niemand heeft ze mooier kunnen maken terwijl ze ontstonden.

Vier dingen kun je uit dit logboek niet halen, en die noemen we eerst.

Er staan geen euro's in. Wij meten rekentijd, niet uitgaven. Er is geen bedragenlog, dus elk bedrag in dit artikel zou verzonnen zijn. Dit stuk gaat daarom over tijd en aandacht.

Het is één systeem, niet een benchmark. Andere opzet, andere taken, andere cijfers. Wat hier overdraagbaar is, zijn de verhoudingen tussen soorten taken, niet de absolute getallen.

Twee tellers zijn kapot en die gebruiken we niet. Het logboek bevat 5825 sessie-eindes tegen 122 sessie-starts. Dat is een artefact van hoe het schrijven werkt, geen herstartteller. Wie daar een beschikbaarheidsclaim op bouwt, bouwt op zand.

De correctietabel stopt in mei. Er is een tabel waarin staat wanneer een mens het systeem heeft gecorrigeerd, en die loopt van 30 maart tot 11 mei en dan niet meer. 24 rijen. Te weinig en te oud om te zeggen hoe vaak er is ingegrepen. Dat cijfer laten we dus weg in plaats van het te schatten.

Verder geldt: 1065 runs startten, 803 eindigden goed, 241 eindigden fout. Die drie tellen niet op. 21 runs hebben nooit een eindstand weggeschreven, wat betekent dat de machine of het proces eronder is weggevallen voordat er iets gelogd kon worden. Alle percentages hieronder zijn berekend over de 1044 runs met een eindstand.

Een op de vier geplande runs haalt de eindstreep niet

De hoofdcijfers passen in één tabel.

Drieënzeventig procent, tachtig procent, zevenenzeventig procent: het maakt voor je planning niet uit welke van die getallen precies klopt. Wat uitmaakt is dat de vierde poging structureel iets anders doet dan de eerste drie. Je bouwt dus geen keten waarin stap vier op stap drie wacht, tenzij je ook bouwt wat er gebeurt als stap drie wegvalt.

Wij hebben dat op één manier opgelost die zichtbaar rendeert: een taak die faalt, krijgt automatisch een tweede poging. In deze periode slaagden 24 runs pas bij die retry. Dat zijn 24 taken die anders stil waren weggevallen, zonder foutmelding die iemand zou opvallen, want een taak die niet draait maakt geen geluid. Die tweede poging is het goedkoopste stuk techniek in het hele systeem en het levert het meeste op.

Waar het misgaat, gaat het overigens zelden spectaculair mis. Er is geen enkele run die data heeft vernietigd of iets naar buiten heeft gestuurd dat niet klopte. De mislukkingen zijn saai: iets liep vast, iets duurde te lang, iets ontbrak op de machine. Dat is goed nieuws, en het is ook precies waarom de foutenlijst zo makkelijk te negeren is.

Bijna een derde van alle mislukkingen is het systeem dat zichzelf tegenhoudt

Dit is het cijfer waar we zelf het meest van opkeken. "Mislukt" is geen categorie maar een verzamelbak, en als je hem openmaakt zit er iets in dat je niet als falen wilt tellen.

76 van de 241 mislukkingen, bijna een derde, is het systeem dat zijn eigen werk weigert. Dat is geen storing maar het ontwerp. Voor elke soort uitvoer die naar buiten kan, staat er een poort tussen die controleert of het klopt: staat er een bron bij elk getal, is er een Engelse versie, zit de toon goed, staat er geen placeholder in. Komt het er niet doorheen, dan gaat de run als mislukt het logboek in.

Breder gemeten, over alle taken en niet alleen de mislukte runs, hield die poort in deze periode 371 keer iets tegen, verdeeld over 205 verschillende taken. Hetzelfde stuk werk wordt bij een nieuwe poging opnieuw beoordeeld, dus die twee getallen mag je niet bij elkaar optellen. 205 unieke tegengehouden taken is het cijfer dat klopt. Tweehonderdvijf keer stond er werk klaar dat er zonder poort gewoon uit was gegaan.

Als je één ding uit dit artikel meeneemt, laat het dit zijn: bouw de rem voordat je de motor bouwt. In een telling ziet een kwaliteitspoort eruit als een bron van mislukkingen. In de praktijk is het het enige onderdeel dat voorkomt dat een systeem met hoge snelheid de verkeerde kant op rijdt. Anthropic schrijft in zijn eigen handleiding voor het bouwen van agents hetzelfde, in andere woorden: de succesvolste implementaties gebruiken eenvoudige, samenstelbare patronen in plaats van complexe zelfsturende constructies. Simpel en controleerbaar wint van slim en ondoorzichtig.

Waarom schrijven 97 procent haalt en publiceren 29 procent

Het interessantste patroon in de meting zit niet in het gemiddelde maar in de spreiding. Per taak uitgesplitst loopt het slagingspercentage van 97 tot 29, en die volgorde is geen toeval.

Bovenaan staan de taken die iets máken. Schrijven, onderzoeken, samenvatten: dat gebeurt volledig binnen de machine, met tekst als grondstof en tekst als uitkomst. Er is geen derde partij die halverwege nee kan zeggen.

Onderaan staan de taken die de buitenwereld nodig hebben. Netwerkgroei leunt op een ingelogde sessie die verloopt. Signalen op X leunen op een dienst waarvan het tegoed op is. Publiceren moet langs een reeks controles, een git-push en een externe bouwstap, en elke schakel kan de hele keten laten vallen.

Dat verschil zit niet in de techniek maar in wie de sleutel heeft. Een taalmodel dat een tekst schrijft heeft niemand nodig. Een taak die iets op een platform zet, hangt af van een sessie, een tegoed, een tarief en een beslissing van iemand anders. Wie een automatiseringsproject begint, moet dus niet kijken naar wat het spannendst is om te automatiseren, maar naar waar de sleutel ligt.

Er zit een voorbehoud bij deze tabel en dat hoort erin. De steekproeven lopen ver uiteen. Content schrijven heeft 100 runs achter zich, de validatieronde 17. De onderkant van deze tabel is een aanwijzing, geen conclusie. De bovenkant, met 100 en 152 runs, is dat wel.

En dan de nuance die publiceren minder erg maakt dan 29 procent suggereert: van de 27 mislukte publicatieruns waren er 21 de eigen poort die de publicatie tegenhield. Dat is dus geen kapotte machine maar een streng ingestelde controle voor de stap waar een fout het duurst is. Onze publicatiewrapper brak in deze periode 111 keer af over 86 verschillende artikelen, meestal omdat er een cijfer zonder bron in stond of een Engelse versie ontbrak. Dat is precies waarvoor hij bestaat, en het is dezelfde discipline die we beschrijven in hoe je merkcijfers terugbrengt naar de bron.

Wat er stuk gaat, en vooral hoe lang het stuk blijft

Nu de foutmeldingen. Er staan er 791 in het logboek. Dat klinkt als een systeem dat in brand staat. Het is iets anders: het zijn een handvol oorzaken die maandenlang blijven doorpiepen.

Twee dingen springen eruit. Ten eerste: 552 van de 791 foutmeldingen, zeventig procent, komen uit één taak. Een radar die reacties ophaalt op onze eigen berichten. Die taak blijft een dienst aanroepen waarvan wij al maanden weten dat hij dicht zit.

Ten tweede: de grootste "storing" is helemaal geen defect. Het tegoed bij een van de platformen waar we publiceerden is op, en dat is een abonnementskwestie. Er is niets kapot. Maar de taak die het aanroept staat nog in de planning, dus schreeuwt hij drie maanden lang elk uur opnieuw dat er iets niet lukt. De laatste melding is van vanochtend, drie maanden na de eerste.

Dat is de les die het meeste waard is en die je nergens in een verkooppraatje leest: de foutenlijst raakt vervuild, en in die vervuiling verdwijnt het echte probleem. Zesenzestig procent van alle meldingen komt uit één geparkeerde oorzaak. Zeventig procent komt uit één taak. Wie op aantallen alarmeert, alarmeert op ruis. Erger nog: wie drie maanden lang dezelfde melding ziet en er niets aan doet, leert zichzelf aan om die hele lijst te negeren. En dan mis je de melding die er wél toe doet.

Kijk ook naar de kolom levensduur. Het ontbrekende programma was in acht dagen opgelost, want dat blokkeerde direct zichtbaar werk. De berichtverzending piept al sinds 2 mei, want die faalt zelden en zonder gevolgen. De onderhoudslast zit niet in de grote storingen. Die zijn snel weg, omdat ze pijn doen. De last zit in de kleine dingen die niemand dwingen iets te doen.

Wat het aan aandacht kost

Dit is het deel waar de meeste ondernemers naar op zoek zijn: hoeveel van jouw week gaat hier in zitten?

Op 61 van de 133 gemeten dagen ging er niets mis. Op de overige 72 dagen wel. Afgerond: op 54 van elke 100 dagen vraagt het systeem om aandacht. Dat is de eerlijke prijs en het is meteen het belangrijkste tegengif tegen de verkooppraat. Dit is geen apparaat dat je aanzet en vergeet.

Tegelijk: aandacht is niet hetzelfde als werk. De meeste van die 72 dagen kostten geen halve dag maar een blik van twee minuten op een lijst, met de conclusie "dat is die bekende, morgen weer". Het echte werk zit in de dagen waarop je besluit een van die bekende oorzaken definitief op te ruimen, en dat zijn er een paar per maand.

De rekentijd zegt iets anders: 119 uur machinetijd over 681 runs, met een mediaan van net geen negen minuten per run. Dat is de tijd die het systeem aan jouw werk besteedde terwijl jij iets anders deed. Daar staat tegenover dat het in dezelfde periode 359 stukken content vastlegde, 2128 taken verwerkte en 563 risicovolle acties van een controlespoor voorzag. De verhouding tussen die twee kolommen, uren van de machine tegenover minuten van jou, is de hele businesscase. Niet een percentage in een folder.

Wat dit betekent voor een Nederlands bedrijf dat hier nog aan moet beginnen

Eerst even de omgeving, want die is relevanter dan de meeste mensen denken. Het aantal bedrijven dat AI gebruikt verdubbelde in twee jaar tijd, en inmiddels zet 35% van de AI-gebruikende bedrijven het in voor marketing of verkoop. Dat is het grootste toepassingsgebied. Interessanter is de andere kant van dezelfde meting: van de bedrijven die AI overwogen en er toch van afzagen, noemt 73% gebrek aan ervaring als belangrijkste reden. Niet de kosten. Niet de techniek. Ervaring.

Dat is precies waarom een artikel als dit bestaat. Wat ondernemers missen, is niet een tool maar een beeld van hoe het eruitziet als het draait. Eén voorbehoud hoort erbij en de statistiekdienst zet het er zelf bij: de cijfers over 2026 komen pas in december 2026 beschikbaar, dus dit zijn gegevens over 2025.

Concreet, vertaald naar een bedrijf van vijf tot vijftig mensen:

Begin bij wat binnenshuis blijft. Teksten, samenvattingen, onderzoek, sorteerwerk in je inbox. Dat is de kant van de tabel waar 97 en 82 procent staat. De verleiding is om te beginnen bij het zichtbaarste stuk, meestal publiceren of adverteren, en dat is de kant waar 29 staat.

Bouw de weigering voordat je de uitvoer bouwt. Wat mag er absoluut niet naar buiten? Schrijf dat op als een controle die de uitvoer kan tegenhouden, en bouw hem vóór de taak die de uitvoer maakt. Onze poort hield 205 stukken werk tegen. Zonder die poort waren dat 205 dingen die wél naar klanten waren gegaan.

Zet een vervaldatum op elke foutmelding. Als dezelfde melding er over twee weken nog staat, hoort hij niet meer in de lijst. Dan is het een besluit dat je moet nemen, geen fout die je moet zien. Wij hebben zelf drie maanden te lang naar dezelfde melding gekeken, dus dit advies komt uit eigen falen.

Reken in aandacht, niet in uren. De vraag is niet "hoeveel tijd bespaart dit". De vraag is "wie kijkt er elke ochtend naar, en wat doet die persoon als er iets rood staat". Is er geen antwoord op die tweede vraag, dan is het systeem nog niet af, hoe goed het ook werkt.

Een praktische manier om dit te doorgronden zonder zelf iets te bouwen: kijk hoe agents nu al langs je merk lopen. Dat beschrijven we in merkpositionering in een wereld van AI-agenten en in wat agents.md doet op een Shopify-webshop.

Hoe wij dit bij Oase Creative inzetten

Wij zijn een merkbureau in Arnhem, geen softwarebedrijf. Milo bestaat omdat wij hetzelfde probleem hadden als onze klanten: te veel uitvoerend werk, te weinig handen, en geen zin in een team dat alleen maar knoppen indrukt. In zes jaar hebben we honderden merken opgeleverd, en het patroon is altijd hetzelfde: het denkwerk is schaars en het doewerk is eindeloos.

Wat wij hieruit hebben geleerd en meenemen naar klantwerk, staat in drie regels.

Een mens op de kwaliteitscontrole, altijd. Het creatieve concept komt van een mens. Een systeem voert uit en scherpt aan. Die volgorde draaien we niet om, en de cijfers hierboven zijn precies waarom: een systeem dat 77 procent haalt, heeft iemand nodig die de andere 23 procent ziet.

Automatiseer de herhaling, niet de beslissing. Alles wat elke week hetzelfde is, mag weg. Alles waar een oordeel in zit, blijft bij een mens. Het verschil tussen die twee is meestal binnen tien minuten te bepalen en het scheelt maanden werk.

Toon het logboek. Wij laten klanten zien wat er draait, wat er faalde en wat er is tegengehouden. Dat voelt kwetsbaar en het werkt beter dan een presentatie, want het is het enige bewijs dat er echt iets draait. Wie een aanbieder overweegt: vraag om het logboek. Wie er geen heeft, heeft geen systeem maar een demo.

Wil je weten wat er in jouw geval te automatiseren valt zonder dat je er een tweede baan bij krijgt, kijk dan naar onze diensten of neem gewoon contact op. We zeggen ook geregeld dat iets niet de moeite waard is, en dat is meestal het nuttigste antwoord. Voor de webshopkant staat de bredere uitleg in AI in je webshop en de laatste 20 procent en in agentic commerce op Shopify. Wie het meetbaar wil maken: zo meet je AI-verwijzingen in GA4.

Wat een agentsysteem aan onderhoud kost, samengevat in vier getallen

Niet als afsluitende samenvatting maar als de vier getallen die je meeneemt naar een gesprek met een aanbieder.

77. Het percentage geplande taken dat de eindstreep haalt, in een systeem dat al maanden draait en waar dagelijks iemand naar kijkt. Belooft iemand je meer dan negentig, vraag dan naar zijn logboek.

76 van de 241. Het aandeel mislukkingen dat bestaat uit het systeem dat zichzelf tegenhoudt. Als een aanbieder geen enkel getal heeft voor "hoe vaak weigerde jullie systeem zijn eigen werk", heeft hij die poort niet.

97 tegenover 29. Het verschil tussen een taak die niets van buiten nodig heeft en een taak die dat wel heeft. Dit is het getal dat bepaalt waar je begint.

54 van de 100. Het aandeel dagen waarop het systeem om aandacht vraagt. Dit is de post die in geen enkele offerte staat en die je zelf moet inplannen.

Wie dat weet voordat hij begint, bouwt iets dat blijft draaien. Wie het niet weet, bouwt iets dat drie maanden lang in een lege kamer staat te schreeuwen. Voor een technische inleiding op hoe agents hun taken uitvoeren en waar de controle hoort te zitten, is de documentatie over gereedschapsgebruik een goede eerste stap, en verder helpt onze uitleg over AI-branding als merksysteem.

Veelgestelde vragen

Wat kost het onderhoud van een agentsysteem in tijd? In ons eigen logboek ging op 54 van de 100 dagen iets mis dat aandacht vroeg. Dat is geen dagtaak, maar het is ook geen nul. Reken op een dagelijkse blik van vijf tot tien minuten op de foutenlijst, plus een half uur per week om de oorzaken op te ruimen die blijven terugkomen.

Hoe vaak mislukt een geplande AI-taak echt? Van de 1065 geplande runs haalden er 803 de eindstreep en 241 niet. Van die 241 waren er 76 de eigen kwaliteitspoort die de uitvoer weigerde, 90 een proces dat vastliep en 67 een tijdslimiet die werd overschreden.

Welke taken kun je het beste als eerste automatiseren? Taken die niets van een derde partij nodig hebben. Schrijven haalt bij ons 97 procent, onderzoek 82 procent, publiceren 29 procent. Dat verschil zit niet in de techniek maar in wie de sleutel heeft.

Is een agentsysteem iets dat je aanzet en vergeet? Nee. In deze periode produceerde ons systeem 791 foutmeldingen, waarvan 552 uit één taak en 492 uit één bekende oorzaak die al sinds 16 juni open staat. De onderhoudslast zit in het opruimen van die ruis, niet in het bouwen.

Hoeveel Nederlandse bedrijven gebruiken eigenlijk AI? Eén op de zes bedrijven gebruikte in 2025 AI, een verdubbeling ten opzichte van twee jaar eerder. Van die gebruikers zet 35% het in voor marketing of verkoop, en bedrijven die afhaakten noemen gebrek aan ervaring als belangrijkste reden.