Ik testte OpenClaw twee weken: dit heb ik geleerd

Ik heb OpenClaw twee weken geleden geïnstalleerd. Sindsdien spreek ik er vijf tot tien keer per dag mee. Laten we beginnen met het slechte nieuws voor de liefhebbers van spectaculaire demonstraties: ik heb niemand ontslagen, mijn bedrijf draait niet vanzelf en er werkt geen leger agenten terwijl ik rustig mijn koffie drink.

De realiteit is minder spectaculair, maar ze interesseert me meer. OpenClaw is een goed verlengstuk van mijn handen geworden voor een paar specifieke taken. Ik praat normaal tegen hem; hij kiest zijn gereedschap, werkt in een repository, opent een merge request, schrijft een spraakbericht uit of bereidt het skelet van een publicatie voor. En sommige dagen verbrandt hij tokens op een opmerkelijke snelheid, breekt zijn eigen configuratie of vraagt om toegang die hij nooit zou mogen hebben.

Ik geef het maar meteen toe: dit verhaal wordt bewust heel nuchter. Geen 'mijn leven zal nooit meer hetzelfde zijn', geen screenshots waarin zes digitale agenten een bedrijf runnen terwijl ik slaap. Ik ga vertellen wat ik daadwerkelijk heb ingesteld, wat het me heeft gekost, wat er kapot ging en waarom ik het toch blijf gebruiken. Het is minder spannend, maar dat is precies het deel dat me interesseerde voordat ik het installeerde.

Wat OpenClaw eigenlijk toevoegt aan een LLM

Een groot taalmodel ontvangt tekst en stuurt tekst terug. Daar komt alle schijnbare magie vandaan. Een agent voegt een lus toe: met het bericht stuurt hij de beschrijving van de beschikbare tools naar het model. Het model reageert dan niet alleen met een zin; het kan ook, in een gestructureerde vorm, vragen om een actie uit te voeren.

Dit idee blijft voor mij een kleine intellectuele schok. We praten over modellen die code schrijven, een afbeelding analyseren of de indruk geven dat ze redeneren; toch zit er in de kern van het systeem altijd een transformatie van tekst naar tekst. In een klassieke chat typ ik een vraag en krijg ik een antwoord. Met een agent voegen we gewoon — 'gewoon' met veel aanhalingstekens — een lijst toe van dingen die het systeem rond het model kan uitvoeren.

Als ik tegen hem zeg 'herinner me eraan om over een uur een klant te bellen', herkent het model de bedoeling, maakt OpenClaw de taak aan, en daarna gaat het resultaat terug naar het model zodat het de bevestiging kan formuleren. Voor het verzenden van een e-mail, het raadplegen van een repository of het bedienen van een browser blijft het principe hetzelfde: het model adviseert, de gateway voert uit, en het resultaat gaat terug naar het model.

Concreet wordt mijn zin iets dat lijkt op een JSON-aanroep: naam van het hulpmiddel, tijd, herinneringstekst, eventueel een gespreks-ID. De gateway ontvangt die opdracht, maakt de herinnering aan en stuurt het resultaat met het ID terug naar het model. Het model kan me dan eindelijk antwoorden: "klaar." Zelfs die laatste zin is weer een nieuwe stap. De agent viert zijn succes niet alleen: hij vraagt aan het LLM hoe hij het netjes aan mij kan melden.

Dit detail is belangrijk, want het haalt een groot deel van het mysterie weg. OpenClaw is geen digitaal bewustzijn dat verborgen zit op mijn server. Zonder model 'denkt' het niet. Het is een orkestratielaag die context meeneemt, tools aanbiedt, hun aanroepen uitvoert en de resultaten terugstuurt. Bij elke ietwat onduidelijke stap gaat het terug om advies te vragen aan het LLM. Dat verklaart zowel de flexibiliteit als het verbruik ervan.

De eerste agents werkten al op deze manier, maar hun gereedschapskist stond vast. Om e-mails te kunnen versturen, schreef een ontwikkelaar een SMTP-functie, gaf deze aan als tool — eventueel via MCP — en implementeerde de applicatie opnieuw. Het model kreeg vervolgens de beschrijving van deze nieuwe functie bij elke aanvraag. Het werkte wel, maar het updaten van de agent bleef gewoon klassiek ontwikkelingswerk.

We hadden dus al agenten voor OpenClaw. Wanneer hen een functie ontbrak, kon ik mijn IDE openen, een code-assistent vragen om de integratie te schrijven, het opslaan in de applicatie en vervolgens opnieuw uitrollen. Het was zeker veel sneller geworden dan voorheen, maar er was nog steeds een mens nodig om de gegenereerde code te nemen en op de juiste plek aan te sluiten. Het idee dat door mijn hoofd spookte was duidelijk: als de agent dat onderdeel al kan schrijven, waarom zou hij het dan niet ook zelf kunnen installeren?

Waar OpenClaw echt interessant wordt, is dat het zijn eigen omgeving kan uitbreiden. Ik kan het vragen om mijn spraakberichten te accepteren: het leest de documentatie, inspecteert de machine, installeert of configureert een component, voegt een hook toe en herstart wat herstart moet worden. De gereedschapscatalogus staat niet langer vast. De agent draagt zelf bij aan het ontwikkelen van zijn mogelijkheden.

De reeks is bijna verwarrend de eerste keer: ik formuleer de behoefte, hij zoekt de documentatie van zijn eigen platform, vindt het configuratiebestand en het verwachte type hook, bereidt de wijziging voor en start zichzelf opnieuw op. In theorie hoef ik de ontwikkelaar van de agent niet langer te smeken om een functie toe te voegen in een volgende versie. In de praktijk word ik precies de persoon die moet controleren of de agent geen komma heeft gemist voordat hij zichzelf het woord ontneemt.

Het is opwindend. Het is ook precies het moment om op je hoede te zijn: een systeem dat zijn configuratie kan aanpassen, kan een komma vergeten, een ongeldig JSON produceren en daarna weigeren om opnieuw op te starten. Dat is mij natuurlijk ook overkomen.

Waarom het hele internet op hol is geslagen

Het idee van een agent die zichzelf kan aanvullen hing al een tijdje in de lucht. Met code-assistenten werd het schrijven van een nieuw hulpmiddel al veel sneller. OpenClaw heeft de stap weggehaald waarbij ik de gegenereerde code moest nemen, installeren, opslaan en het systeem opnieuw moest starten. De agent kan zijn eigen documentatie lezen, begrijpen welk bestand veranderd moet worden, de component klaarmaken en zijn service opnieuw starten.

Natuurlijk gingen de demonstraties erg snel rond. We zagen assistenten e-mails sorteren, tickets boeken, formulieren invullen, dashboards in de gaten houden en andere medewerkers coördineren. Toen kwamen de gebruikelijke beloften: geen team meer nodig, geen kantoor meer nodig, alles werkt 's nachts vanzelf. Dit is het moment waarop mijn reflex als oude technicus in werking treedt.

Ik heb veel van deze demonstraties bekeken. Sommige gaven me heel goede ideeën; andere lieten me denken: 'mijn God, dat moet je echt niet doen.' Ik zet niet alle auteurs over één kam — ik kan trouwens niet elke installatie controleren — maar het mechanisme van de hype is duidelijk. Een video waarin de agent een reis boekt en met klanten praat trekt meer aandacht dan een verhaal waarin hij netjes een Git-branch aanmaakt. Toch is in mijn werk juist die tweede scène het meest waardevol.

Sinds het begin van mijn carrière heb ik al verschillende technologieën gezien die werden gepresenteerd als een onomkeerbare spelwijziging. Virtuele werelden zouden kantoren vervangen, virtual reality zou ons belangrijkste scherm worden, en elke nieuwe golf zou de vorige verouderd maken. Sommige bouwstenen overleven en worden nuttig. Het grote verhaal verdwijnt meestal veel sneller.

Ik werk sinds 2008 in de IT. Ik heb minstens vijf of zeven keer gehoord dat de regels definitief veranderd waren. Ze evolueren natuurlijk, maar zelden op de manier zoals aangekondigd in de week van de opwinding. Dat scepticisme weerhoudt me er niet van om OpenClaw te gebruiken: integendeel, ik gebruik het voldoende om elke dag nieuwe mogelijke gevallen te zien. Het voorkomt alleen dat ik het echte nut verwar met de trailer van dat nut.

Ik zeg niet dat OpenClaw een gadget is. Ik gebruik het echt meerdere keren per dag, wat al meer is dan veel zogenaamd revolutionaire tools die getest en daarna vergeten worden. Maar ik wilde iets bescheidener controleren: waar zit de waarde als je de demonstratie, de video-edit en de sciencefictionwoorden weglaat?

Waarom ik de agent niet op mijn hoofdcomputer heb geïnstalleerd

De kortste weg zou zijn om het installatiescript op mijn werkcomputer te draaien en dan OpenClaw toegang te geven tot de bestanden, de browser en de apps. In een demonstratie is het geweldig: de agent vindt een contract, past de data aan, vergelijkt tickets tussen Brussel en Amsterdam, vult een formulier in of hergebruikt een al geopende sessie.

De documentatie biedt inderdaad een heel korte installatieset voor macOS, Linux, WSL of PowerShell. Het downloadt de afhankelijkheden, installeert de service en zet het op de achtergrond. Het is handig, en juist daarom raad ik aan om het niet zomaar op de machine te draaien waar je hele digitale leven en werk staan. Eén opdrachtregel verkleint het vertrouwensgebied niet: het verdoezelt het alleen maar.

Op papier is het positieve aspect geweldig. Ik kan zeggen: "haal het contract van deze klant op, werk de datum en de contactgegevens bij, en stuur het document dan weer naar mij." Ik kan hem vragen de browser te openen, de dienstregelingen voor een rit Brussel–Amsterdam te bekijken en een reservering voor te bereiden met de reeds opgeslagen informatie. Het is de fantasie van Jarvis, niet meer in een film, maar zittend naast mijn echte bestanden en mijn echte bankkaart.

Het probleem zit in precies diezelfde demonstratie: hij ziet de bestanden, de browser en de sessies. Een deel van die context kan bij de modelprovider terechtkomen. Daarna is het genoeg met een hallucinatie, een verkeerd begrepen instructie of een verborgen injectie op een webpagina om een echte actie te triggeren. Ik heb echt geen zin om de documenten van mijn klanten, mijn sleutels en mijn dagelijkse browser aan een nog experimenteel hulpmiddel toe te vertrouwen.

Je kunt een filmscenario bedenken waarin de leverancier van het model opzettelijk mijn geheimen zou proberen te achterhalen. Ik geloof daar niet echt in. Ik vind mezelf niet interessant genoeg om een groot bedrijf een speciale operatie op mijn schijf te laten uitvoeren. Maar technisch gezien bestaat de vertrouwensketen wel: OpenClaw beschrijft zijn tools en een deel van mijn context aan een externe LLM; die LLM stelt tool-aanroepen voor; mijn machine voert ze uit. Het aan dit circuit de mogelijkheid geven om op de schijf te zoeken of een dienst te installeren verdient meer dan een enthousiaste klik op 'volgende'.

Het is niet eens nodig om een kwaadaardige leverancier voor te stellen. Het meest geloofwaardige scenario is veel banaler: een pagina bevat een instructie die de agent als een opdracht ziet, een tool krijgt een te breed pad, of het model begrijpt 'maak deze map schoon' iets te letterlijk. Het gevaar is niet alleen dat iemand mijn gegevens steelt. Het gevaar is ook dat een goedbedoelende assistent precies het verkeerde doet, met veel enthousiasme.

Modellen hallucineren. De beste maken minder vaak fouten bij eenvoudige optellingen, maar ze maken nog steeds fouten bij complexe situaties, precies die situaties waarvoor je ze een terminal en een browser geeft. Het is dus geen abstracte angst voor AI. Ik heb mensen gezien die aan OpenClaw vroegen om 'alles zelf te regelen', en dan hulp kwamen vragen wanneer de dienst niet meer opstartte. Het model had geen kwade bedoelingen: het had gewoon een verkeerd bestand geschreven.

De browser vergroot het bereik nog verder. Een open sessie bevat soms toegang tot facturen, een beheerdersconsole, betaalmiddelen of interne tools. Als de agent kan klikken in mijn plaats, kan hij me tien minuten besparen. Hij kan een redeneerfout ook omzetten in een aankoop, een verzonden bericht of een productiestand. Gemak en risico komen voort uit dezelfde bevoegdheid.

Ik heb het dus geïnstalleerd op een klein apart virtueel machientje. De volgende stap is waarschijnlijk een oude laptop met Ubuntu, met zijn eigen gebruiker en browser. Geen snelle machine nodig: het berekenen van het model gebeurt bij de leverancier. Waar het hier om gaat, is isolatie. Als de agent besluit alles te verpesten, laat ik hem liever zijn eigen sandbox slopen dan mijn werkstation.

De speciale laptop heeft ook een heel gewoon voordeel: ik kan er op afstand op inloggen, zelf een pagina openen en tegen de medewerker zeggen 'kijk hier' in plaats van hem permanente toegang tot mijn dagelijkse browser te geven. Zijn gebruiker, zijn geschiedenis en zijn sessies zijn van hem. Het ergste wat hij kan doen is zijn eigen werkruimte verknoeien. Dit is precies het soort vervelende grens dat demo's bij het monteren meestal weghalen.

Deze keuze voorkomt ook een veel voorkomende misvatting. Een high-end minicomputer is niet nodig om de gateway te laten draaien. In rust verbruikt OpenClaw weinig; het zware werk, de inferentie, wordt ergens anders uitgevoerd wanneer ik een extern model gebruik. Een oude laptop, een VM of een kleine server is vaak voldoende. Ik steek liever in een nette scheiding van accounts en geheimen dan in een indrukwekkende machine op het bureau.

Tenzij je het model lokaal wilt draaien, is het kopen van een krachtige machine alleen voor OpenClaw dus meer een plezier dan een noodzaak. De gateway is niet de motor: hij houdt het stuur vast en roept de externe motor aan. Mijn belangrijkste investering blijft een omgeving die ik opnieuw kan installeren, back-ups en rechten die ik kan intrekken.

• dedicated machine of VM, zonder automatische koppeling van mijn persoonlijke mappen;
• systeemaccount en browserprofiel specifiek voor de agent;
• toegang verleend één voor één, voor een herkenbaar gebruik en een bepaalde duur;
• gescheiden, intrekbare geheimen, beperkt tot het strikt noodzakelijke;
• genummerde configuratie om precies te zien wat de agent wijzigt;
• Geen gevoelige uitrol, aankoop of verzending zonder menselijke goedkeuring.

De huidige documentatie biedt beleidsregels voor tools, machtigingslijsten, een beveiligingsaudit en verschillende sandbox-modi. Je moet ze bewust gebruiken: de uitvoeringssandbox is geen perfecte grens en wordt niet automatisch ingeschakeld voor alle tools in een gewone installatie.

De stomste storing blijft een echte storing

Ik heb bij meerdere mensen een heel eenvoudig probleem zien terugkomen: de agent past zijn JSON-bestand aan, vergeet een komma of een accolade, en dan start het niet meer. Met een uitstekend model gebeurt dit minder vaak. Met een goedkoper model, gekozen om tokens te besparen, worden schemafouten daarentegen snel zichtbaar.

Voor een ontwikkelaar duurt het repareren soms maar twee minuten. Ik controleer de JSON, kijk naar de laatste diff en corrigeer de fout. Voor iemand die de agent juist heeft geïnstalleerd omdat hij niet aan de configuratie wil zitten, stopt de ervaring bij een stille service. Hetzelfde systeem dat zichzelf zou moeten repareren, kan niet meer opstarten om het bericht 'repareer jezelf' te lezen.

Ik hou de configuratiemap dus in Git. Voor een belangrijke wijziging wil ik weten wat er gaat veranderen. Daarna kijk ik naar de diff. Voor opstartinstellingen, permissies en mailkoppelingen bewerk ik het JSON-bestand nog steeds het liefst zelf. Het is niet erg futuristisch, maar het is een geweldige manier om een rustige dinsdagavond terug te vinden.

De verborgen kosten: elke 'hallo' draagt een koffer

OpenClaw zelf is licht. De rekening daarentegen kan snel zwaar worden. Elke beslissing vereist een inferentie en mijn simpele 'hallo' reist nooit alleen: het model ontvangt ook de systeemprompt, de regels van de agent, zijn tools, zijn vaardigheden, een deel van het geheugen en de geschiedenis die nuttig wordt geacht.

Tijdens mijn test, met de huidige instellingen en tarieven, begon een verse sessie rond de 10.000 invoertokens. De sessie resetten en het welkomstbericht ontvangen kostte ongeveer twee cent. Een simpele herinnering maken kwam op ongeveer 45.000 tokens en negen cent. Het toevoegen van twee pagina's aan een project verbruikte ongeveer 263.000 invoertokens en 6.000 uitvoertokens, waarvan 168.000 uit de cache werden gehaald: enkele tientallen centen voor een redelijk bescheiden wijziging.

Waarom 10.000 tokens voordat je zelfs maar begonnen bent? Omdat 'hallo' komt met een klein administratief koffertje: wie is de agent, hoe moet hij antwoorden, welke tools heeft hij, welke vaardigheden zijn geïnstalleerd, welke regels gelden, welk geheugen is relevant en welk deel van het gesprek moet bewaard worden. In een gewoon chatgesprek weegt mijn woord maar een paar tokens. In een agent wekt het een hele omgeving tot leven.

De herinnering van 45.000 tokens lijkt nog absurder totdat je naar het traject kijkt. Het model begrijpt het verzoek, kiest het juiste hulpmiddel, kijkt eventueel even hoe het correct aan te spreken, ontvangt het resultaat, controleert of de taak bestaat en bereidt een leesbaar antwoord voor. OpenClaw doet dit niet allemaal met een kleine deterministische motor: het vraagt het model op meerdere momenten.

Ik formuleer het opzettelijk een beetje bot: zonder LLM is OpenClaw een machine zonder hersenen of wil. Bij elk kruispunt gaat hij terug naar zijn adviseur: 'wat moet ik doen zodat de gebruiker tevreden is?' En eenmaal de actie voltooid: 'hoe moet ik hem vertellen dat ik goed werk heb geleverd?' Die flexibiliteit is het product. Het is ook de factuurlijn.

Neem deze cijfers niet als een universeel tarief. Het model, de cache, de provider en de prijzen veranderen. Ze laten gewoon zien wat er onder de motorkap gebeurt. Bij betalen per gebruik wordt een ongelukkig lusje een rekening. Bij een begrensd abonnement botst de agent uiteindelijk tegen de limiet en stopt. Het is irritant, maar tenminste springt de zekering.

Bij langere ontwikkeltaken heb ik de teller een miljoen invoertokens zien naderen, met tienduizenden uitvoertokens en een deel van de context dat uit de cache werd gehaald. Dat is niet per se een miljoen 'nieuwe' tokens in menselijke zin: de regels, bestanden en toolfeedback circuleerden meerdere keren. Maar de facturering telt wel degelijk alle passages op.

Het meest misleidende is de snelheid. Een wijziging kan vijf minuten duren en de indruk wekken van een kleine bijna gratis dienst. In die vijf minuten heeft de agent misschien de repository gelezen, het model bevraagd, een tool gestart, de output herlezen, zijn code aangepast, de tests uitgevoerd en het resultaat samengevat. Mijn stopwatch geeft niet de hoeveelheid context aan die is verwerkt.

Het is ook daarom dat ik op mijn hoede ben voor de uitdrukking 'de agent vervangt een werknemer'. Hij kan een specifieke functie overnemen, bijvoorbeeld een samenvatting maken, een MR openen of een inbox controleren. Als je hem urenlang onbeperkt laat nadenken en handelen met een duur model, wordt de besparing een stuk minder aantrekkelijk. De agent is niet gratis omdat er niemand op het toetsenbord zit te typen.

En welke werknemer vervang je precies? Degene die alleen maar één keer per uur zijn mailbox opent en een samenvatting maakt? Als de hele functie van een persoon kan worden gereproduceerd door zo’n beperkte lus, zat het echte probleem misschien al in de organisatie van het werk. In mijn team verhogen de code-assistenten de productie, maar ik heb geen enkele ontwikkelaar ontslagen. Het is mogelijk dat ik even minder snel aanneem; dat is niet hetzelfde als zeggen dat 'de medewerkers het team hebben vervangen'.

Betalen per gebruik of abonnement?

Met een API die per token wordt gefactureerd, houd ik veel vrijheid, maar ik loop wel het hele risico van een loop of van een context die te groot wordt. Een abonnement beperkt het risico beter: wanneer het quota is bereikt, stopt het werk tot de volgende verlenging. Om te experimenteren stelt deze limiet me gerust, meer dan een onbegrensde bankkaart achter een nachtelijke automatisering.

Abonnementen maken inferentie niet oneindig. Betaalbare aanbiedingen hebben tijdslimieten en plafonds; de duurdere formules kosten al snel honderden dollars per maand. Voor één persoon kan dat nog acceptabel zijn. Voor een heel team verandert het flink als je accounts en pakketten moet vermenigvuldigen. Je moet de kosten vergelijken met de tijd die je echt bespaart, niet met een abstracte belofte van autonomie.

Op het moment van mijn test liet een persoonlijke instapformule vooral toe om het eens te proberen. Bij intensief gebruik met de agent was het quota van een paar uur snel op, en daarna kwam het wekelijkse plafond erachteraan. De veel duurdere aanbiedingen gaven meer ademruimte zonder echt onbeperkt te worden. Dat is een punt dat marketingtabellen slecht weergeven: een 'actief' menselijk gesprek en een agent die oproepen van tools vermenigvuldigt, verbruiken helemaal niet op hetzelfde tempo.

Op bedrijfsniveau is het niet automatisch de beste oplossing om voor elke ontwikkelaar een groot persoonlijk abonnement te kopen, en zakelijke contracten veranderen de berekening nog eens extra. Uiteindelijk hebben we verschillende modellen gecentraliseerd achter onze eigen gateway om de toegang en de kosten onder controle te houden. Ik presenteer dit niet als een universeel recept: het is gewoon het gevolg van een collectief gebruik waarbij de persoonlijke limieten te moeilijk voorspelbaar werden.

Mijn aanbeveling om te beginnen blijft dus prozaïsch: gebruik eerst een afgebakende enveloppe. Een limiet die de agent vijf uur onderbreekt, is frustrerend, maar is beter dan een nachtelijke lus die direct aan een onbeperkte facturering gekoppeld is. Zodra het verbruik duidelijk is, kun je bewust beslissen om de kraan verder open te draaien.

Cron en heartbeat: automatisering verbruikt zelfs als er niets gebeurt

Mijn berichten zijn niet de enige die verbruiken. Een geplande taak kan de agent elk uur wakker maken, hem de mailbox laten controleren, het model vragen wat te doen, constateren dat er niets gebeurt, en dan weer gaan slapen. Zelfs dat prachtige 'niets te melden' heeft context, een beslissing en een paar tokens gevraagd.

Ik reserveer de terugkerende automatiseringen dus alleen voor controles die echt een modelinterpretatie rechtvaardigen. Een deterministische check, een API-aanvraag of een paar regels script zijn goedkoper en vaak betrouwbaarder. Het LLM komt pas in beeld wanneer het resultaat taal vereist, een ambigue rangschikking of een contextuele beslissing.

Om het voorbeeld van de e-mailservice te nemen: een script kan eerst de server vragen of er nieuwe e-mails zijn. Als er geen zijn, stopt het zonder het model aan te roepen. Als er er tien zijn, geeft het alleen die tien berichten door voor classificatie en samenvatting. Het hele agent elke uur wakker maken om te ontdekken dat de inbox leeg is, is technisch mogelijk, maar het is een dure manier om te leren dat er niets is gebeurd.

Ik heb configuraties gezien die alles altijd wilden automatiseren. Na een dag of twee was het quotum verdwenen of had de factuur een veel minder leuke vorm aangenomen. Het probleem was geen uitzonderlijke taak: het was de opeenstapeling van kleine wekertjes, elk vergezeld van de systeem-prompt, de tools, het geheugen en een verzoek aan het model. De agentiekost zit vaak in de herhaling, niet in de grote rode knop.

Eerste nuttige toepassing: de herinneringen die me niet loslaten

Mijn meest voorkomende gebruik is bijna banaal. Ik zeg tegen hem: „Herinner me eraan deze klant over een uur te bellen, en blijf me elke tien minuten herinneren totdat ik bevestig.” Een klassieke agenda kan een waarschuwing weergeven. OpenClaw daarentegen houdt de intentie in gedachten en blijft doorgaan totdat ik bevestig. Het is soms vervelend. Maar juist daarom werkt het.

Het is niet revolutionair, maar het is een kleine wrijving die verdwijnt. De regel blijft hetzelfde: de herinnering mag geen toegang hebben tot mijn volledige berichten, mijn schijf en mijn productierepository gewoon omdat hij weet hoe hij een taak opnieuw kan starten.

Het carnaval van mogelijke gebruiksvormen

Zodra de agent verbonden is met de browser, de e-mail, de terminal en de API's, komen de ideeën vanzelf. Hij kan e-mails lezen, een rapport versturen, statistieken ophalen, een formulier invullen, een restaurant zoeken, tickets vergelijken of andere agenten in de gaten houden. Sommige demonstraties lijken bijna op een strategiespel: verschillende digitale personages verdelen de code, de implementatie en de monitoring.

Ik vind het fascinerend om naar te kijken. Ik weet niet zeker of ik zo zou willen werken. Een spectaculaire interface betekent niet noodzakelijk een goed proces. Wat ik zoek is iets eenvoudigers: verlengen wat ik al kan, in de momenten dat mijn toetsenbord niet beschikbaar is, terwijl ik een duidelijk controlepunt behoud.

In een privécommunity heb ik zelfs een installatie gezien die was omgevormd tot een strategiespel: verschillende agenten bewogen zich als eenheden, de een bouwde de site, de ander bereidde de uitrol voor, een derde hield het resultaat in de gaten. Ik had de demonstratie lang kunnen bekijken. Maar ik heb me geen seconde voorgesteld om zelf zo te werken. Het was een heel goede show-interface, niet per se een goede werkdag.

Mijn criterium is minder gericht op speciale effecten: verlengt het hulpmiddel echt mijn armen? Voert het, onder mijn controle, een actie uit die ik al kan, maar die ik op dat moment niet comfortabel kan doen? Op dat gebied begon OpenClaw een plek bij mij te veroveren.

Mijn echte gebruiksgeval: een code-agent in Telegram

Het idee kwam bij me op na een heel gewoon incident — het soort dat altijd gebeurt als je niet achter je computer zit. Een weergavefout had de prijzen van een dienst vermenigvuldigd. Twee minuten achter het toetsenbord zouden genoeg zijn geweest. Vanaf mijn telefoon probeerde ik de grote component in de monorepo aan te passen, ik verbrak de deployment en moest terugdraaien om de dienst weer draaiend te krijgen.

Ik was met verlof, op de pistes, toen een ontwikkelaar me de screenshot stuurde. De toegang tot dit project was toen alleen voor mij geconfigureerd. Ik opende de Git-interface vanaf mijn telefoon, probeerde de foute waarden te splitsen en slaagde er vooral in om de hele leverancier neer te halen, die in hetzelfde monorepo zat. Ik startte de rollback, het team kon weer aan het werk, en ik bleef met die vervelende gedachte zitten: achter mijn computer hadden de correctie en het uitrollen maar twee of drie minuten geduurd.

Ik heb dus mijn 'reddingsboot' gebouwd: een ontwikkelaar die bereikbaar is via een speciale Telegram-groep. Hij mag niet deployen en zit nooit direct aan de hoofdbranch. Zijn werkruimte bevat een kloon van het project. Hij maakt een branch, past de code aan, voert de checks uit, pusht de branch en maakt een merge request aan. Daarna neem ik het weer over: ik lees de diff, test en beslis over de merge.

Het woord 'canot' is opzettelijk. Dit is niet mijn belangrijkste ontwikkelomgeving. Voor mijn computer blijven de IDE en mijn gebruikelijke code-assistent sneller, comfortabeler en vooral transparanter. Ik wil deze agent voor de momenten dat ik onderweg ben, wanneer een simpele correctie lastig wordt vanaf een telefoon en wachten op meerdere uren niet redelijk is.

In mijn setup zijn de algemene assistent en de code-agent gescheiden. De eerste gebruikt het standaard algemene model. De tweede is alleen verbonden met het projectonderwerp en gebruikt een code-georiënteerd model. De Telegram-koppelingen bepalen welk account, welke groep en welk onderwerp welke agent activeren. Onbekende privéberichten worden geweigerd, de agent moet genoemd worden in gewone groepen en hij reageert automatisch alleen binnen zijn werkonderwerp.

In het begin schreef ik hem in de nieuwe groep: 'Ben je daar? ping'. Volledige stilte. Privé verzekerde de agent me echter dat alles zou moeten werken en bood steeds fantasierijkere verklaringen aan. De realiteit was minder slim: in deze groep moest je hem vermelden, en de bot moest de nodige rechten hebben om de berichten te lezen. Zodra ik hem tagde, kwam er een reactie en begon het gesprek.

Deze scheiding lijkt administratief, maar het voorkomt dat alle context door elkaar loopt. Een gesprek over een herinnering hoeft de monorepo-regels niet. Een code-taak heeft het geheugen van mijn algemene assistent niet nodig. Het routeren per account, groep en onderwerp stelt me in staat om het model en de workspace te kiezen nog voordat het bericht wordt verwerkt.

Het configuratieprincipe, zonder mijn inloggegevens, ziet er zo uit:

{
  "agents": {
    "default": { "workspace": "/srv/openclaw/general", "model": "general" },
    "provider-code": { "workspace": "/srv/openclaw/provider", "model": "coding" }
  },
  "bindings": [
    {
      "channel": "telegram",
      "chatId": "<groupe-code>",
      "topicId": "<sujet-projet>",
      "agent": "provider-code"
    }
  ]
}

Dit is geen kant-en-klaar bestand om te kopiëren: de exacte namen hangen af van de versie en de installatie. Het laat de logica zien die telt. Het Telegram-account komt in een groep, de groep bevat een onderwerp, en dat onderwerp wijst naar een specifieke agent, een specifiek model en een specifieke workspace. De routing wordt besloten voordat het model begint te improviseren.

Ik host ook meerdere agents op dezelfde server. Iedereen heeft zijn eigen identiteit, workspace en verbindingen. Een VM per assistent maken zou onnodig duur zijn, maar het proces delen betekent niet dat je alle rechten deelt. Het belangrijkste is dat je kunt zeggen: dit Telegram-account praat met deze agent, met dit model, in deze repository, en nergens anders.

In mijn echte bestand blijft de hoofd-bot de standaard voor algemene gesprekken. Het projectonderwerp heeft een meer specifieke koppeling naar de code-agent. Ik heb het onderwerp-ID opgehaald door het systeem te vragen waar het huidige bericht zich bevond, en dat vervolgens handmatig in de JSON gezet. Voor de demo had ik een opgeschoonde kopie van het bestand klaargemaakt: een beveiligingsvoorbeeld tonen met de echte tokens op het scherm zou toch een vrij slechte grap zijn geweest.

De repository bevat ook een regelsbestand: monorepo-architectuur, testcommando's, conventies, verplichte aanmaak van een branch en een MR, verbod op deployen. Voor een complexe taak vraag ik hem eerst om een tekstplan. De GitLab-token is speciaal en kan ingetrokken worden; de SSH-sleutel hoort bij deze omgeving, niet bij mijn hoofdaccount.

Ik heb voor hem een apart GitLab-account aangemaakt, een speciaal e-mailadres, een eigen SSH-sleutel en een beperkt access token. De agent heeft zijn sleutel gegenereerd en het token in zijn omgeving geïnstalleerd, maar ik heb de rechten bepaald. Zijn regelbestand zegt dat hij een branch moet maken, pushen en een MR openen. Voor complexe verzoeken moet hij eerst een plan indienen voordat hij code schrijft, zodat ik kan controleren of hij het juiste probleem begrijpt.

Ik begon met een opzettelijk belachelijke test: een versienummer vervangen door een ander. De agent heeft het bestand aangepast, de branch aangemaakt en de MR geopend. Ik heb de diff gelezen, gemerged en daarna de automatische deployment gecontroleerd. Pas na deze generale repetitie gaf ik hem de twee nieuwe pagina’s. Een agent verdient geen rechten voor een groot project alleen omdat hij een mooie zin in Telegram heeft gemaakt.

Deze eerste test bewees bijna niets over zijn vermogen om te coderen. Het bewees iets dat voor mij belangrijker was: de hele keten werkte. Het bericht kwam bij de juiste agent aan, de repository was de juiste, de branch verscheen, de MR was zichtbaar en de pipeline startte pas na mijn merge. Voordat ik om intelligentie vroeg, wilde ik de basis controleren.

Wat werkte

Ik heb hem gevraagd om een aanbodpagina en een tijdelijke privacy-pagina te maken naar het model van een bestaande voorwaardenpagina. Twee minuten later bevatte de MR beide routes, de tijdelijke teksten en zelfs de thema-selector die overeenkomt met de rest van de site. Daarna liet ik een opmerking achter om een 'concept'-blok te verwijderen: de agent heeft de opmerking gelezen, de branch aangepast en de MR bijgewerkt.

Op Telegram verscheen de indicator 'aan het typen...' terwijl hij werkte. Onder de motorkap las hij de opmerking, vond hij de branch, bewerkte hij het bestand en pushte hij de nieuwe revisie. Toen het antwoord binnenkwam, controleerde ik de diff in plaats van zijn 'klaar' als bewijs te zien. De merge-knop bleef onder mijn vinger, niet onder de zijne.

Die laatste heen-en-weer is belangrijker dan de eerste generatie. Een eerste versie van code is makkelijk te laten zien in een demo. Een reviewcommentaar lezen, de juiste branch vinden, een kleine wijziging toepassen en dan de MR bijwerken voelt al als een echt stuk workflow. Ik kon het resultaat volgen in GitLab in plaats van te moeten geloven dat 'het gedaan is'.

Het is precies het niveau van autonomie waar ik naar op zoek ben. Wanneer ik voor mijn IDE zit, blijft mijn gebruikelijke codeerhulpmiddel sneller en transparanter. OpenClaw wordt interessant wanneer ik buiten ben, dat ik de correctie via een spraakbericht kan uitleggen en dat de wijziging op me wacht in de vorm van een controleerbaar diff.

Ik benadruk dit punt omdat het de belofte volledig verandert. Ik ga niet voor mijn zeven schermen zitten om code in Telegram te dicteren. Op mijn bureau open ik de IDE, zie ik de bestanden en controleer ik de lus veel sneller. Deze agent is een reddingsboot voor het moment dat ik in een auto zit, in een trein of ver weg van mijn werkplek — niet de theatrale vervanging van mijn dagelijkse omgeving.

Wat de eerste keer niet werkte

De 'automatische' configuratie verloor snel zijn magische kant. In een nieuwe groep bleef de agent volledig stil terwijl hij me verzekerde dat alles zou werken. De oorzaak was heel simpel: je moest hem vermelden en hem de toestemming geven om de berichten te lezen. Uiteindelijk heb ik het JSON-bestand zelf gecorrigeerd. Een model zonder controle zijn eigen opstartbestand laten herschrijven leek me een vrij slechte manier om de avond af te sluiten.

De echte opstart vergde meerdere stappen: de groep en de onderwerpen aanmaken, de inloggegevens ophalen, de bindings declareren, het projectonderwerp koppelen aan de code-agent, de vermeldingen regelen, de workspace klaarmaken, de SSH-sleutel installeren en een beperkt GitLab-token voorzien. OpenClaw hielp me bij een deel van dit werk, maar hij maakte er geen éénknopsproces van.

In gewone groepen geef ik hem een expliciete vermelding. Zonder die vermelding luistert hij, maar antwoordt niet. In het onderwerp dat voor de code is gereserveerd, is de vermelding niet nodig: elk bericht is voor hem bedoeld. Privéberichten van onbekende identiteiten worden geweigerd. Het zijn kleine instellingen, maar zij maken het verschil tussen een nuttige assistent en een bot die overal tussenkomt.

Dit detail vat OpenClaw goed samen: het kan een overtuigende codewijziging uitvoeren, en dan hallucineren over zijn eigen configuratie. Intelligentie is niet uniform. Daarom controleer ik de permissies, de gewijzigde bestanden en het werkelijke resultaat, niet alleen het geruststellende antwoord van de bot.

Spraakberichten: de extensie die het mobiele gebruik verandert

Ik wilde met de agent praten in plaats van een bestek op mijn telefoon te typen. OpenClaw kan de beschikbare middelen bekijken en Whisper lokaal voorstellen. Mijn kleine VM was niet geschikt voor deze transcriptie, dus ik heb hem de documentatie van onze bestaande transcriptieservice gegeven.

In onze infrastructuur is deze service geen simpele directe oproep naar een model. We hebben een interne gateway voor meerdere AI-functies: transcriptie, LLM en beeldgeneratie. Voor spraak probeert het eerst een interne bron, schakelt over naar een andere motor als die faalt, en pas daarna naar een betaalde service. Sommige verwerkingen zijn asynchroon: je maakt een taak aan, wacht, en haalt dan het resultaat op. Het was nodig om al deze bedrading uit te leggen zonder dat OpenClaw de helft zou verzinnen.

De agent stelde een paar vragen, voegde een hook toe en wijzigde de instellingen. Vanaf nu gaat een Telegram-bericht eerst door de transcriptiesoftware; de tekst komt terug in de normale lus en wordt als elke andere instructie behandeld. De wijzigingen blijven onder versiebeheer, waardoor ik precies kan bijhouden welke hooks zijn toegevoegd.

Onze transcriptiedienst werkt asynchroon: het ontvangt de media, maakt een taak aan, wacht op het resultaat en stuurt dan de tekst terug. In plaats van dit protocol mondeling aan de agent uit te leggen, heb ik mijn code-assistent gevraagd er een gedetailleerde integratiedocumentatie van te maken op basis van een bestaand project. Ik heb dit document aan OpenClaw gegeven, zijn vragen beantwoord en hem vervolgens het aansluiten laten voorbereiden.

Ik had al een klein intern botje dat deze gateway gebruikte: we stuurden het een spraakbericht, het schreef het uit en zette de ideeën een beetje op volgorde. Ik heb de code van dit botje aan mijn ontwikkelingsassistent gegeven met een heel specifieke instructie: maak een integratiedocument, beschrijf de authenticatie, het formaat van de tokens, het aanmaken van een taak, het wachten op het resultaat en de foutgevallen. Dit Markdown-bestand werd het contract tussen onze service en OpenClaw.

De uiteindelijke pipeline is makkelijk te begrijpen: er komt een bericht van Telegram; als het een spraakbericht bevat, stuurt de hook het naar de transcriptiedienst; de verkregen tekst vervangt het medium in de normale loop. Vanaf dat punt behandelt de agent mijn stem net als elke andere geschreven instructie. Dit is precies het soort uitbreiding dat het project de moeite waard maakt: het verandert echt hoe ik het gebruik wanneer ik ver van kantoor ben.

Ik kon zien hoe de verzoeken bij ons binnenkwamen, de transcriptietaak afgerond werd, en dan de tekst terugkwam in OpenClaw. Het resultaat was dus niet alleen 'de bot zegt dat hij de spraakinvoer begrijpt'. Ik zag het echte traject. En omdat de OpenClaw-configuratie versiebeheer heeft, kon ik de toegevoegde hook en de regel die hem in de pipeline zet voor de normale berichtverwerking bekijken.

Niet alles is perfect gebleven. De dag voor de opname was ik nog aan het experimenteren met de hooks en ik heb de verwerking van spraakberichten tijdelijk onderbroken. Het is bijna een ideale demonstratie van het product: heel krachtig, echt handig, en voldoende aanpasbaar zodat ik het zelf onbruikbaar kan maken voordat ik ga slapen.

Dit was het beste voorbeeld van zijn vermogen om uit te breiden: ik heb de integratie niet met de hand geschreven, maar ik heb ook geen blinde toestemming gegeven. Ik heb een gedocumenteerde interface, een beperkt token en een versiebeheerde repository geleverd.

Tweede nuttige toepassing: mijn posts voorbereiden zonder mijn stem te verliezen

Ik schrijf al lang voor mijn kanaal. Ik heb mijn oude publicaties in JSON geëxporteerd en vervolgens een model gevraagd om er een gedetailleerde stijlgids uit te halen: ritme, uitdrukkingen, structuur, overgangen en fouten om te vermijden. Ik heb deze gids in de prompt van een agent geplaatst die voor het schrijven is gereserveerd.

Op een gegeven moment plaatste ik praktisch elke dag iets. Maar de kosten van de eerste versie – de pagina openen, de ideeën op een rijtje zetten, de juiste invalshoek vinden – begonnen uiteindelijk het tempo te vertragen. Het is dat heel gewone probleem dat ik wilde oplossen. Niet een machine maken die mijn meningen voor me zou hebben, maar het pad verkorten tussen een idee dat ik op straat opschrijf en een concept dat ik zin heb te verbeteren.

Exporteren is belangrijk. Ik heb hem niet gevraagd om drie geselecteerde publicaties na te doen omdat ik ze leuk vond. Ik heb hem jaren aan teksten gegeven, met mijn gewoontes, herhalingen en fouten. Het model heeft dat materiaal omgezet in bruikbare richtlijnen. Pas daarna heb ik een apart onderwerp voor het schrijven aangemaakt, zoals ik ook voor de code had gedaan.

Ik zeg niet alleen tegen hem ‘schrijf over OpenClaw’. Ik stuur hem een concept, enkele kernpunten of een lang spraakbericht. Hij maakt een structuur en een eerste versie die dicht bij mijn toon ligt. Daarna werk ik de tekst bij, vervang ik sommige passages en beslis ik zelf om het te publiceren.

Voor de demonstratie had ik hem zoiets vaags kunnen vragen als 'schrijf een post over de gevaren van OpenClaw'. In het echte leven werk ik niet zo. Ik geef hem stukjes, tegenwerpingen, een anekdote en soms een nog wat verwarde conclusie. Hij doet vooral het montagewerk. Als ik geen feiten, geen standpunt en geen ruwheid aanbreng, levert hij me precies wat ik verdien: een gladde tekst die iedereen had kunnen ondertekenen.

Ik beweer niet dat hij voor mij schrijft. Hij laat de lege pagina verdwijnen en geeft me een skelet dat goed genoeg is om te beginnen. Daarna knip ik, herschrijf ik en voeg ik mijn eigen rafelige kanten toe. De inhoud, het oordeel en de verantwoordelijkheid blijven bij mij; de machine bespaart me vooral het pijnlijke eerste uur.

Het voordeel was meteen merkbaar: ik begon weer regelmatig concepten te maken. Het is niet omdat de agent auteur zou zijn geworden. Het is omdat het voor mij duurste moment — een hoop aantekeningen omzetten in structuur — korter is geworden. Daarna kan ik mijn energie besteden aan wat de agent niet heeft: mijn ervaring, mijn mate van twijfel en de beslissing om elke zin publiekelijk te dragen.

Het kanaal dat het beste werkt is trouwens niet 'geef me een onderwerp'. Ik stuur hem mijn ideeën door elkaar, soms in bulletpoints, soms in een lange spraakopname terwijl ik aan het wandelen ben. Hij zet de elementen in een leesbare volgorde en stelt een tekst voor. Hoe meer mijn concept een mening en persoonlijke voorbeelden bevat, hoe minder het resultaat op een generieke soep lijkt.

« Hij leert helemaal alleen » verdient een asterisk

OpenClaw kan onderdelen installeren, zijn bestanden aanpassen en zijn vaardigheden uitbreiden. Zeggen dat hij 'zelf leert' is echter nog steeds een versimpeling. Hij wordt niet spontaan wijzer. Hij voert een verzoek uit met de tools en het model waartoe ik hem toegang heb gegeven. Een verkeerde instructie of een verkeerd model leidt gewoon tot een nieuwe fout in een systeem dat inmiddels complexer is geworden.

De recente versies hebben juist het standaardgedrag aangescherpt. Om het meest permissieve profiel te krijgen, moet je het bewust inschakelen in de configuratie. Ik vind die rem gezond. Een nieuwe installatie moet beginnen met bespreken en observeren, niet met meteen de terminal, de browser, geheimen en alle bestanden ter beschikking hebben.

Met andere woorden, de kortere versie 'hij maakt zichzelf slimmer' mengt verschillende dingen door elkaar. Hij kan documentatie lezen, een pakket installeren, een skill maken, een hook toevoegen of een prompt aanpassen. Het is een zeer krachtige uitbreidingsmogelijkheid. Maar zijn oordeel blijft afhangen van het model, de context en de permissies. Een nieuwe sleutel aan een gereedschapskist toevoegen garandeert niet dat de gebruiker het juiste slot zal kiezen.

Mijn regel is stapsgewijs: eerst een kanaal, dan een lege workspace, daarna een testrepository, vervolgens een beperkte sleutel, en pas uiteindelijk een nuttige workflow. Bij elke stap kijk ik naar de logs en de gewijzigde bestanden. Autonomie is geen schakelaar die je aanzet; het is een grens die ik uitbreid nadat ik het echte gedrag heb gezien.

Het is misschien mijn beroepsdeformatie: ik hou er niet van dat een software, een leverancier of zelfs een persoon volledige controle over mijn apparaten heeft. Ik beweer niet dat ik deze mening moet opleggen. Ik zeg alleen, met de nodige bescheidenheid, dat het absoluut correct is en dat de anderen fout zijn. Serieuzer: als je een ander risicobeleid kiest, kies het dan op zijn minst met kennis van zaken.

De drang om alles te automatiseren is een valstrik

OpenClaw veroorzaakt een zeer herkenbaar syndroom: zodra het werkt, wil je het overal aansluiten. Het doet me denken aan de dag dat ik mijn rijbewijs haalde: ik had zin om de auto te pakken, zelfs voor de winkel aan de andere kant van de straat. Het was duurder, soms langzamer en objectief gezien absurd, maar ik had zin om te rijden.

Te voet was de reis gratis, waarschijnlijk sneller als je het parkeren meerekende, en zelfs beter voor mijn gezondheid. Met de auto verbruikte ik brandstof, zocht ik een parkeerplaats en bracht ik een nieuwe kans met me mee om iets te raken. Toch nam ik de auto, gewoon omdat ik eindelijk het recht en de zin had om hem te gebruiken. Het enthousiasme van OpenClaw veroorzaakt precies die technische jeuk.

Voor veel taken is OpenClaw precies die auto. Je zou kunnen lopen — of, hier, een paar regels script schrijven, een webhook instellen, een geplande functie starten. Dat zou minder leuk zijn, maar eenvoudiger, voorspelbaarder en goedkoper. Ik houd de agent voor de verzoeken die veranderen, beter in natuurlijke taal beschreven worden en meerdere tools samen laten werken.

Wat ik onthoud na twee weken

Na twee weken heeft OpenClaw noch mijn team noch mijn werk vervangen. Daarentegen zet het een spraakbericht om in MR, dringt aan als ik een herinnering negeer, stelt het eerste concept van een tekst samen en koppelt een gedocumenteerd hulpmiddel aan een discussiekanaal. Het is geen dagelijkse revolutie. Het is al nuttig genoeg om ermee te blijven praten.

Ik zal het blijven gebruiken en er nieuwe mogelijkheden aan toevoegen. Maar elke nieuwe mogelijkheid moet drie vragen beantwoorden: is het echt effectiever dan een script? Wat kan het in het ergste geval kosten? Wat is de maximale schade als het model fout zit?

Ik ga waarschijnlijk gewoon doorgaan met het breken van hooks, het vergelijken van modellen en het vinden van nieuwe toepassingen. Het verschil is dat ik niet langer op zoek ben naar een demonstratie waarin OpenClaw almachtig lijkt. Ik zoek een beetje saaie automatiseringen die een echte werkweek doorstaan. Mijn twee huidige successen — de reddingsboot voor code en de schrijfassistent — horen precies in die categorie thuis.

Ik ben dus niet langer op zoek naar 'een agent die alles kan doen'. Ik geef de voorkeur aan meerdere kleine agenten, elk met een eigen model, onderwerp, repository en permissies, met menselijke controle op plekken waar een fout pijn doet. Het is minder magisch, veel minder verkooppraat — en naar mijn idee veel serieuzer.

Technische verwijzingen

• OpenClaw: definitie en algemene architectuur
• OpenClaw: installatie en eerste gebruik
• OpenClaw: beveiligings- en auditmodel
• OpenClaw: tools uitvoeren in een sandbox
• OpenClaw: automatiseringen, cron en heartbeat
• OpenClaw: officiële repository

Daarna lezen

• Zo configureerde ik Pi als code-agent: LSP, MCP, skills en extensies AI en ontwikkeling · 34 min
• Synology AI verbinden met een lokaal LLM via Ollama of LM Studio Synology, AI en zelfhosting · 12 min

Over de auteur

Jeremy Kraft beheert de infrastructuur en de zelfgehoste diensten van het IBCSC. Deze gidsen beschrijven configuraties die echt zijn uitgerold en voor publicatie opnieuw zijn nagekeken.

Een vraag stellen Alle gidsen

Discussie

Reacties

0

Nog geen reacties. U kunt de discussie openen met een vraag of uw eigen ervaring.

Website

Uw naam Hebt u een account? Aanmelden

Uw reactie

Platte tekst, maximaal 2 000 tekens. Nieuwe reacties worden gemodereerd. Uw naam wordt bij de reactie getoond. Er wordt geen e-mailadres gevraagd; alleen een onomkeerbare vingerafdruk van uw IP-adres wordt bewaard tegen spam.

Reactie versturen