Ik zette een 24/7 assistent op een Raspberry Pi

Ik wilde een agent die uit zichzelf werk kan oppakken: het internet op, tickets lezen, een repo induiken, een eerste voorstel voor code-wijzigingen maken en daarna terugrapporteren waar mijn team toch al werkt.

De ingang moest Slack zijn. Daar zitten de vragen, threads, bestanden en half afgemaakte ideeën. De agent moest tools kunnen gebruiken, bestanden kunnen lezen, branches kunnen klaarzetten en blijven draaien als mijn laptop dichtgaat.

Daarom draait er nu een Raspberry Pi 5 met 4 GB RAM in mijn netwerk. Daarop draait OpenClaw. Slack ervoor, GPT-5.5 erachter, Tailscale als toegangspoort wanneer ik niet thuis ben.

De Pi draait in deze opzet geen lokaal taalmodel. OpenClaw gebruikt de Pi als always-on Gateway: de laag die Slack-berichten ontvangt, sessies en workspace-context beheert, een agent-run start, tools beschikbaar maakt en het antwoord weer terugstuurt naar dezelfde thread. Het model draait in deze setup via OpenAI.

Dat onderscheid is belangrijk. Voor volledig lokale inference gebruik ik de DGX Spark, en daar schreef ik eerder over in de quantization-post. Deze Pi is de agent-laag ernaast: altijd aan, bereikbaar in Slack, dicht bij mijn bestanden en workflows.

Het ding dat ik miste

Ik gebruik al genoeg AI-tools. Claude Code voor bouwen. ChatGPT voor losse vragen. Voor klantprojecten werk ik met model-API’s of lokale modellen, afhankelijk van wat de data en infrastructuur toelaten.

De ontbrekende laag zat tussen die tools in: een agent die werk ziet binnenkomen en alvast begint. In Slack kan dat klein starten. Ik typ een rommelige opdracht, de agent leest de repo, pakt de juiste tone-of-voice-regels erbij en komt terug met iets dat ik kan beoordelen.

Ik beoordeel en publiceer zelf. De agent mag het voorbereidende werk doen.

De richting is groter dan drafts schrijven. Ik wil uiteindelijk een ticket kunnen aanwijzen en zeggen: zoek uit wat hier nodig is. De agent leest de context, checkt documentatie, kijkt in de codebase, stelt een aanpak voor en zet eventueel alvast een branch klaar.

Dat werk blijft vaak liggen omdat het nergens netjes past. Te klein voor een sprint. Te groot om “even tussendoor” te doen. Voor je het weet staat zo’n ticket een week later nog open met dezelfde drie vage opmerkingen eronder.

Wat er op de Pi draait

De basis is klein:

• Raspberry Pi 5, 4 GB RAM
• OpenClaw Gateway lokaal op de Pi
• OpenAI GPT-5.5 als model in deze setup
• Slack als interface
• Tailscale voor remote toegang

De Pi blijft draaien wanneer mijn laptop dicht is.

OpenClaw knoopt de lagen aan elkaar: channel, sessie, agent-runtime, model-provider en tools. Een Slack-bericht komt binnen via de channel-laag. OpenClaw zet daar een agent-turn van klaar, met de juiste context en tools. De runtime voert die turn uit met het gekozen model. Daarna bezorgt OpenClaw het antwoord weer terug via Slack.

Op die manier kan dezelfde agent files lezen, shell-commands draaien, webpagina’s ophalen, git-status bekijken of een PR voorbereiden, afhankelijk van welke tools je toestaat. De Pi is dus geen mini-GPU. Hij is de lokale controle-laag.

Tailscale houdt het praktisch. Ik kan bij de Pi als ik onderweg ben. Daarvoor hoef ik geen publieke poort open te zetten.

Slack als werkvloer

Slack was de makkelijkste keuze omdat ik er al de hele dag in zit. Mijn bedrijven hebben workspaces, channels, threads, bestanden en notificaties. Zo hoef ik voor de agent geen apart dashboard te openen.

Voor mij is dit de kern: de agent moet beschikbaar zijn waar het team werkt. Als hij iets uitzoekt op basis van een ticket, wil ik het antwoord terug in dezelfde flow. De analyse hoort naast de vraag, in dezelfde thread.

OpenClaw ondersteunt meer ingangen dan Slack. Het werkt ook via onder meer Telegram, Microsoft Teams, Google Chat, WhatsApp, Discord en iMessage. Slack is mijn ingang. Het bredere idee is agents op bestaande communicatiekanalen, met tools en geheugen erachter.

De installatie was minder spannend dan gehoopt

De installatie verliep eenvoudiger dan ik had verwacht.

De meeste tijd zat in lezen. OpenClaw heeft veel documentatie, en je moet even uitzoeken welk deel bij jouw setup hoort. Slack, Gateway, agents, runtimes, channels, tools: het zijn losse lagen die uiteindelijk samen één assistent vormen.

Slack instellen kostte ook aandacht. Je bepaalt welke gebruikers de bot mogen DM’en, in welke channels hij mag praten en of hij in groepschannels op elk bericht reageert of alleen bij een @mention. Dat zijn geen details voor later. Je moet die regels vooraf kiezen en met je team delen, anders snapt niemand wanneer de agent wel of niet mee gaat doen.

Na ongeveer twee uur werkte het. Ik typte in Slack, de Pi ving het bericht op, OpenClaw startte een run, GPT-5.5 dacht mee en het antwoord kwam terug in dezelfde thread.

Vanuit dat Slack-bericht kan de agent vervolgens de toegestane tools gebruiken.

Eerste test: deze site

De eerste plek waar ik dit voor gebruik is djangodevreng.nl.

Ik lever de inhoud uit mijn werk aan, waaronder testresultaten, gemaakte keuzes en problemen. De agent helpt met het structureren en uitwerken daarvan.

Met die input kan de agent een opzet maken, losse notities ordenen en formuleringen aanscherpen. Ik laat hem ook controleren op reclametaal en algemene zinnen die weinig toevoegen.

De workflow voor deze site begint meestal rommelig. Ik dump in Slack wat ik wil zeggen: een paar observaties, een half idee, soms alleen feedback op een bestaande post. De agent zoekt daarna de juiste repo erbij, leest de relevante files en pakt de schrijfgids uit de workspace.

Daarna vraag ik hem om een concrete wijziging: “herschrijf de intro”, “haal de marketing-taal eruit” of “maak deze technische uitleg preciezer”. Hoe scherper de opdracht, hoe bruikbaarder de diff. Hij past de markdown aan op een branch, draait de checks en pusht de wijziging naar een PR.

Daar begint mijn deel weer. Ik lees de diff, geef feedback in Slack en laat hem de volgende ronde verwerken. Pas als de post klopt, merge ik zelf. De agent doet het voorbereidende werk. Ik blijf verantwoordelijk voor wat er live gaat.

De agent heeft in deze workflow geen toestemming om zelfstandig te publiceren.

Waarom dit anders voelt dan chat

Veel AI-tools voelen alsof je je werk naar een chatvenster moet brengen. Je kopieert context, plakt logs, legt voor de derde keer uit waar het repo-pad staat en hoopt dat het model doet alsof het erbij was.

Deze setup draait dichter op de context. De agent kan zelfstandig beginnen omdat hij de workspace ziet, de branch kent, de regels voor de site kan lezen en weet welke checks gedraaid moeten worden.

Dat maakt hem nog geen autonome developer. Hij schuift vooral het eerste saaie stuk naar voren.

Voor mij is dat de interessante agent-laag: alvast meelezen, een eerste versie maken, aanwijzen waar het wringt. Ik controleer zijn voorstellen, omdat ze ook overtuigend kunnen klinken wanneer ze niet kloppen.

Ik ga hier nog een losse post over schrijven, want OpenClaw verdient eigenlijk meer uitleg dan in deze build-log past. Welke kanalen het ondersteunt. Welke tools je eraan hangt. En vooral: waarom dit interessant wordt.

We schuiven langzaam van AI als sparringpartner naar AI als uitvoerende laag. De afgelopen jaren praatten we vooral met modellen: brainstormen, samenvatten, herschrijven, meedenken. Dat blijft nuttig, maar het echte verschil zit in agents die werk kunnen uitvoeren in bestaande systemen.

Agents nemen het werk van mensen niet één-op-één over. Zo simpel is het niet, gelukkig. De verschuiving zit in workflows: tickets uitzoeken, context verzamelen, drafts voorbereiden, code-wijzigingen voorstellen, checks draaien, terugrapporteren. Werk waar je normaal iemand voor vraagt omdat het tijd kost, terwijl het weinig diepe menselijke oordeelskracht nodig heeft.

Volgende stap: tickets en MCP

De volgende stap is MCP. Ik wil tools netjes aan deze workflow hangen, te beginnen met Linear.

Het scenario is simpel: er komt een ticket binnen, de agent leest de relevante repo-context, zoekt de waarschijnlijke files, schrijft een korte analyse en komt terug met een voorstel of een lijst vragen.

Autonoom mergen sla ik over. Eerst wil ik weten waar de grens ligt tussen nuttige voorbereiding en gevaarlijke dadendrang.

Daarna komen GitHub, repo-context en misschien een lokale knowledge base. Sommige context hoort gewoon beschikbaar te zijn, zonder dat ik hem steeds opnieuw in een prompt plak.

Workflow voor workflow

Deze Pi-setup is klein. Dat is precies waarom ik hem prettig vind.

Ik kan de opzet overzien en de Pi aan laten staan. De bestanden en tools zijn lokaal bereikbaar; het taalmodel draait bij OpenAI.

Voor productie-AI bij klanten is dit hooguit één laag in de architectuur. Voor mijn eigen workflow werkt hij al prima: Slack als ingang, OpenClaw als Gateway, OpenAI als model-provider, GitHub als plek waar werk klaar komt te staan.

De komende tijd ga ik hier lekker mee rommelen. Eerst deze site. Daarna tickets. Daarna MCP-tools. Daarna waarschijnlijk iets waarvan ik nu nog denk dat het te specifiek is om te automatiseren.

Dat is de interessante route: workflow voor workflow vervangen door een agent die voorwerk doet, context verzamelt en voorstellen klaarzet. Stap voor stap bouw ik mijn OpenClaw-setup uit. Gewoon als praktische assistent die steeds iets meer werk uit mijn handen haalt.

Als een run vastloopt, kan ik die op de Pi stoppen en de logs bekijken.