I put a 24/7 assistant on a Raspberry Pi

I didn’t want a better chatbot. I wanted an agent that picks up work on its own: hop on the internet, read tickets, dive into a repo, draft a first proposal for code changes and then report back where my team already works anyway.

The entry point had to be Slack. That’s where the questions, threads, files and half-finished ideas live. The agent had to be able to use tools, read files, stage branches and keep running when my laptop closes.

So now there’s a Raspberry Pi 5 with 4 GB RAM in my network. It runs OpenClaw. Slack in front, GPT-5.5 behind it, Tailscale as the gateway when I’m not home.

That sounds bigger than it is. The Pi doesn’t run a local language model. OpenClaw uses the Pi as an always-on Gateway: the layer that receives Slack messages, manages sessions and workspace context, starts an agent-run, makes tools available and sends the answer back to the same thread. In this setup the model runs through OpenAI.

That distinction matters. For fully local inference I use the DGX Spark, and I wrote about that earlier in the quantization post. This Pi is the agent layer next to it: always on, reachable in Slack, close to my files and workflows.

The thing I was missing

I already use plenty of AI tools. Claude Code for building. ChatGPT for one-off questions. For client projects I work with model APIs or local models, depending on what the data and infrastructure allow.

The missing layer sat in between those tools: an agent that sees work come in and gets started. In Slack you can start small. I type a messy instruction, the agent reads the repo, pulls in the right tone-of-voice rules and comes back with something I can review.

Publishing stays manual. So does trust. The first bit of groundwork is allowed to happen automatically.

The direction is bigger than writing drafts. Eventually I want to point at a ticket and say: figure out what’s needed here. The agent reads the context, checks documentation, looks in the codebase, proposes an approach and maybe stages a branch already.

That kind of work often gets left behind because it doesn’t fit anywhere neatly. Too small for a sprint. Too big to do “on the side”. Before you know it, that ticket is still open a week later with the same three vague comments under it.

What runs on the Pi

The base is small:

• Raspberry Pi 5, 4 GB RAM
• OpenClaw Gateway locally on the Pi
• OpenAI GPT-5.5 as the model in this setup
• Slack as the interface
• Tailscale for remote access

The Pi is mostly just available here. That’s its talent.

OpenClaw ties the layers together: channel, session, agent-runtime, model-provider and tools. A Slack message comes in through the channel layer. OpenClaw stages an agent-turn from it, with the right context and tools. The runtime runs that turn with the chosen model. Then OpenClaw delivers the answer back through Slack.

That way the same agent can read files, run shell commands, fetch web pages, check git status or prepare a PR, depending on which tools you allow. So the Pi isn’t a mini GPU. It’s the local control layer.

Tailscale keeps it practical. I can reach the Pi when I’m out. Opening a public port for a build-log would be a bit much honour.

Slack as the shop floor

Slack was the easiest choice because I’m in it all day already. My companies have workspaces, channels, threads, files and notifications. An extra dashboard would mostly collect extra tab dust.

For me this is the core: the agent has to be available where the team works. If it figures something out based on a ticket, I want the answer back in the same flow. The analysis belongs next to the question, in the same thread.

OpenClaw supports more entry points than Slack. It also works through, among others, Telegram, Microsoft Teams, Google Chat, WhatsApp, Discord and iMessage. Slack is my entry point. The broader idea is agents on existing communication channels, with tools and memory behind them.

The install was less exciting than I’d hoped

The install was less dramatic than I’d expected. That’s nice for me and bad for the genre “build-log with fireworks”.

Most of the time went into reading. OpenClaw has a lot of documentation, and you have to work out which part fits your setup. Slack, Gateway, agents, runtimes, channels, tools: they’re separate layers that eventually form one assistant together.

Setting up Slack took attention too. You decide which users may DM the bot, in which channels it may talk and whether it reacts to every message in group channels or only on an @mention. Those aren’t details for later. You have to pick those rules up front and share them with your team, otherwise nobody gets when the agent does or doesn’t join in.

After about two hours it worked. I typed in Slack, the Pi caught the message, OpenClaw started a run, GPT-5.5 thought along and the answer came back in the same thread.

A lot of plumbing for a text message. Except that text message can now use tools.

First test: this site

The first place I use this for is djangodevreng.nl.

The content has to come from real work: what we built, what broke, which choices stuck, where a tool looked nice until it started to sweat under load. The agent gets to help with form and execution.

Once that raw input is there, it can do a lot. Structure a dump. Make a first outline. Rewrite a draft in my tone. Strip out marketing language. Check whether a post sounds like it fell out of a generic LinkedIn carousel.

The workflow for this site usually starts messy. I dump in Slack what I want to say: a few observations, a half idea, sometimes just feedback on an existing post. The agent then finds the right repo, reads the relevant files and grabs the writing guide from the workspace.

Then I ask it for a concrete change: “rewrite the intro”, “strip out the marketing language” or “make this technical explanation more precise”. The sharper the instruction, the more usable the diff. It edits the markdown on a branch, runs the checks and pushes the change to a PR.

That’s where my part starts again. I read the diff, give feedback in Slack and let it process the next round. Only when the post is right do I merge it myself. The agent does the prep work. I stay responsible for what goes live.

An agent that publishes without me looking isn’t a workflow. That’s a slot machine with commit rights.

Why this feels different from chat

A lot of AI tools feel like you have to bring your work to a chat window. You copy context, paste logs, explain for the third time where the repo path is and hope the model acts like it was there.

This setup runs closer to the context. The agent can start on its own because it sees the workspace, knows the branch, can read the rules for the site and knows which checks need to run.

That still doesn’t make it an autonomous developer. It mostly pushes the first boring bit forward.

For me that’s the interesting agent layer: reading along ahead of time, making a first version, pointing out where it chafes. A junior colleague with infinite patience, no agenda and sometimes a worrying confidence in its own sentences.

I’m going to write a separate post about this, because OpenClaw really deserves more explanation than fits in this build-log. Which channels it supports. Which tools you hang on it. And above all: why this gets interesting.

We’re slowly shifting from AI as a sparring partner to AI as an executing layer. The past few years we mostly talked to models: brainstorming, summarizing, rewriting, thinking along. That stays useful, but the real difference is in agents that can carry out work in existing systems.

Agents don’t take over people’s work one-to-one. It’s not that simple, luckily. The shift is in workflows: figuring out tickets, gathering context, preparing drafts, proposing code changes, running checks, reporting back. Work you’d normally ask someone for because it takes time, while it needs little deep human judgement.

Next step: tickets and MCP

The next step is MCP. I want to hang tools onto this workflow neatly, starting with Linear.

The scenario is simple: a ticket comes in, the agent reads the relevant repo context, finds the likely files, writes a short analysis and comes back with a proposal or a list of questions.

Autonomous merging I’m skipping. First I want to know where the line is between useful preparation and dangerous eagerness to act.

After that come GitHub, repo context and maybe a local knowledge base. Some context should just be available, without me pasting it into a prompt every time again.

Workflow by workflow

This Pi setup is small. That’s exactly why I like it.

Small enough to understand. Real enough to learn something from. Cheap enough to leave on all the time. Local enough to sit close to my work, without pretending the model itself runs locally.

For production AI at clients this is at most one layer in the architecture. For my own workflow it already works fine: Slack as the entry point, OpenClaw as the Gateway, OpenAI as the model provider, GitHub as the place where work ends up staged.

For the time being I’m going to happily tinker with this. First this site. Then tickets. Then MCP tools. Then probably something I currently still think is too specific to automate.

That’s the interesting route: replacing workflow by workflow with an agent that does the groundwork, gathers context and stages proposals. Step by step I build out my OpenClaw setup. Just as a practical assistant that takes a bit more work off my hands each time.

And if it breaks down, it’s close enough to pull the plug.