Hoe OpenClaw-agents Medewerkers Vervangen, Niet Taken
Ik bouw al maanden AI-agents. Aangepaste pijplijnen, Claude Code-automatiseringen, multi-agent-systemen — de hele stack. En het grootste deel van die tijd gebruikte ik ze verkeerd.
Niet verkeerd op de voor de hand liggende manier. Mijn agents werkten. Ze voltooiden taken. Ze produceerden outputs. Maar elke keer dat ik iets gedaan wilde hebben, moest ik gaan zitten, de prompt schrijven, de uitvoering bewaken, de output beoordelen, en daarna de volgende dag hetzelfde doen. Ik had het werk geautomatiseerd maar niet de workflow. De agent was een tool die ik oppakte en neerlegde. Geen teamlid dat opdaagde en zijn werk deed.
Toen keek ik naar Brian Castle's breakdown van hoe hij zijn bedrijf draait op OpenClaw-agents, en er klikte iets dat ik had gemist. Het onderscheid is bedrieglijk eenvoudig maar het veranderde hoe ik volledig denk over AI-delegatie: er is een enorm verschil tussen een agent een taak geven en een agent een baan geven.
Een taak is "vat dit artikel samen." Een baan is "elke ochtend om 7 uur, scan deze twaalf branchebronnen, identificeer de drie meest relevante aankondigingen, maak een briefing, en stuur die naar mijn Telegram."
Die herformulering — van taken naar banen — ontsloot iets waar ik al weken mee worstelde.
Waarom de Meeste Mensen een Plafond Bereiken met AI-agents
Er is een patroon dat ik constant zie — in mijn eigen werk en in elke AI-bouwcommunity waarvan ik deel uitmaak. Iemand ontdekt AI-agents. Ze raken enthousiast. Ze automatiseren een paar dingen. En dan... bereiken ze een plateau.
Het plateau treedt op omdat op taken gebaseerde delegatie niet schaalt. Elke keer dat je een eenmalige taak delegeert, betaal je een opzetkosten: context instellen, prompt schrijven, output beoordelen. Voor één complexe taak zijn die kosten de moeite waard. Maar wanneer je twintig dingen per dag delegeert, elk vereisend verse context, heb je in wezen een tweede baan voor jezelf gecreëerd — het beheren van de agents.
Brian Castle formuleert dit probleem perfect: je behandelt agents als aannemers die je inhuurt voor een klus, in plaats van medewerkers die je inhuurt voor een rol.
De verschuiving van aannemerdenken naar medewerkersdenken verandert alles over hoe je je agentsystemen architecteert. En het begint met een vraag die de meeste AI-bouwers nooit stellen: wat zijn de terugkerende banen in mijn bedrijf?
Wanneer ik dit werkelijk voor mijn eigen werk in kaart bracht, vond ik zeventien terugkerende banen die ik handmatig deed. Zeventien. Onderzoek scannen, content ontwerpen, code review-samenvattingen, klantrapportages, beveiligingsbulletinmonitoring, concurrentietracking.
Zeventien banen die mij niet nodig hadden. Ze hadden een agent nodig die het proces kende en op tijd opdaagde.
De Architectuur Achter een Zichzelf Runnend Agentteam
Brian's systeem draait op een stapel van specifiek gebouwde componenten.
De basis is OpenClaw zelf, draaiend op een Mac Mini. Denk eraan als het uitzendbureau — het host en voert de agents uit.
Dat is waar BMHQ (Builder Methods HQ) binnenkomt. Het is een aangepaste Rails-app die Brian bouwde als zijn mission control: taaksjablonen, planning, verzending, statusbewaking en outputbeoordeling — allemaal in één dashboard.
Hier is wat er in de praktijk gebeurt. Een terugkerende taak — zeg "AI-branchenieuws scannen en een dagelijkse briefing produceren" — bestaat als een sjabloon in BMHQ. De planner triggert het op het geconfigureerde tijdstip. Aangepaste verzendingscode stuurt de taak rechtstreeks naar de toegewezen agent via de gateway van OpenClaw. De agent pakt het op, voert het uit, produceert de output, en stuurt een voltooiingsmelding via Telegram.
Geen mens in de lus voor uitvoering. De mens beoordeelt outputs wanneer het uitkomt.
Het Telegram-stuk is subliem slim. De agents komen naar hem toe. Hij gaat niet naar hen.
Skills: Het Deel Dat Iedereen Verkeerd Begrijpt
Hier is waar Brian's raamwerk afwijkt van hoe de meeste mensen — inclusief ikzelf, tot recentelijk — AI-agents configureren.
Wanneer je een agent instelt om een terugkerende taak uit te voeren, is het natuurlijke instinct om alle instructies rechtstreeks in de taakprompt in te sluiten. "Dit is wat te doen, dit is hoe te formatteren, dit is waar op te slaan."
Het probleem: wanneer je het proces moet bijwerken, moet je elke taak vinden en aanpassen die naar die instructies verwijst.
Brian's oplossing is wat hij Skills noemt — modulaire procesdocumentatie opgeslagen als afzonderlijke markdown-bestanden. Taken bevatten de instructies niet. Ze verwijzen naar een skill.
Het skill-bestand is de enkele bron van waarheid voor hoe een specifiek type werk gedaan moet worden. Een skill bijwerken? Elke taak die ernaar verwijst gebruikt automatisch het bijgewerkte proces bij de volgende uitvoering.
Als je ooit in software-engineering hebt gewerkt, is dit het DRY-principe (Don't Repeat Yourself) toegepast op agentbeheer.
Skills creëren ook een natuurlijke verbeteringslus. Wanneer je de output van een agent beoordeelt en een hiaat vindt, werk je de skill bij. De update verspreidt zich naar elke toekomstige uitvoering.
Wat ik Bouwde (En Wat er Kapot Ging)
Ik besteedde een weekend aan het bouwen van mijn eigen versie van Brian's systeem.
Mijn stack: Claude Code-agents voor uitvoering. Een eenvoudige Python-planner met APScheduler voor terugkerende taakverzending. Markdown-skill-bestanden in een gedeelde directory. Telegram-bot voor meldingen. Obsidian-vault voor outputopslag en -beoordeling.
Dag één: ik stelde vijf terugkerende banen in. Ochtend-branchescan. Dagelijkse code-commit-samenvatting over mijn actieve repos. Tweewekelijkse concurrentieanalyse voor een klantproject. Wekelijks rapport over de status van de contentpijplijn. Maandelijkse compilatie van beveiligingsbulletins voor xcybersecurity.io-content.
Dag twee: drie van de vijf banen draaiden succesvol bij hun eerste geautomatiseerde uitvoering.
De concurrentieanalyse mislukte omdat het skill-bestand verwees naar een gegevensbron waarvoor authenticatie vereist was die ik niet had geconfigureerd in de omgeving van de agent.
De beveiligingsbulletinbaan produceerde output, maar het was rommel. Het skill-bestand was te vaag over wat een "opmerkelijk" beveiligingsevenement is.
Beide mislukkingen leerden me dezelfde les: skills moeten explicieter zijn dan je denkt. Wanneer je een baan zelf doet, draag je impliciete kennis met je mee over tientallen microbeslissingen die je onbewust neemt. De agent heeft geen impliciete kennis. Elk beslissingscriterium moet expliciet zijn in het skill-bestand.
Tegen dag vijf draaiden alle vijf banen betrouwbaar.
De Economie Die Niemand Bespreekt
Brian maakt een punt dat meer aandacht verdient: de economie van het inhuren van AI-agents is fundamenteel anders dan het inhuren van mensen.
Bij een menselijke medewerker is er een minimaal levensvatbare werklast die de kosten rechtvaardigt. AI-agents hebben geen minimale levensvatbare werklast. Een agent die één taak per dag uitvoert kost je een paar cent aan API-tokens.
Ik berekende mijn negen terugkerende agentbanen. Totale maandelijkse tokenkosten over alle agents: ongeveer $34. Totale tijd die die banen me zouden kosten om handmatig te doen: ongeveer 45 uur per maand. Zelfs bij een bescheiden waarde van mijn tijd van $50/uur, is dat een waarde van $2.250 voor $34 aan infrastructuurkosten.
Wat ik Anders Zou Doen Vanaf Nul
Begin met drie banen, niet negen. Ik was enthousiast en te aggressief ingezet.
Schrijf skill-bestanden alsof je iemand traint die de baan nooit heeft gedaan. Elke aanname die je impliciet laat, zal zich manifesteren als een mislukking.
Bouw de meldingslaag eerst. Voordat je plant, voordat je verzendt, voordat je iets anders doet — stel in hoe je agents met je communiceren.
Bouw geen aangepaste tooling totdat je de workflow handmatig hebt gevalideerd. Ik had zes uur kunnen besparen door mijn eerste vijf banen met handmatige verzending te draaien voordat ik een geautomatiseerde planner bouwde.
Het Grotere Plaatje: AI-agents als Infrastructuur, Niet als Features
Hier is wat me is bijgebleven since ik dit systeem heb opgezet.
De meeste gesprekken over AI-agents richten zich op wat ze kunnen doen. Kunnen ze code schrijven? Kunnen ze data analyseren? Die zijn mogelijkheidsvragen. Ze zijn belangrijk, maar ze zijn niet de belangrijkste vragen meer.
De belangrijkere vraag is: kunnen ze betrouwbaar opdagen, elke dag, en werk doen dat jij anders zou moeten doen of iemand anders voor zou moeten betalen?
Dat is een infrastructuurvraag. En het vereist infrastructuurdenken.
Brian's raamwerk klikte voor mij omdat het AI-agents behandelt als organisatorische infrastructuur in plaats van individuele productiviteitstools. De agents maken hem niet productiever aan zijn bureau. Ze verwerken werk dat plaatsvindt of hij nu aan zijn bureau is of niet.
Mijn ochtend begint niet met "wat moet ik vandaag delegeren?" Het begint met "wat heeft mijn team 's nachts geproduceerd?"
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je tech-infrastructuur opschalen? Ik help je graag.
- Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
