Then I read a Cisco blog post about its security risks.

A third-party skill in the OpenClaw ecosystem was quietly exfiltrating data and running prompt injection attacks on its users. Not theoretical. Not a proof of concept. It was doing it. And the skill marketplace had no meaningful vetting process to stop it from happening again.

That made me slow down and think about what OpenClaw is. It is an agent with shell access, browser control, and the ability to send email on your behalf, running on a loop, connected to a community-maintained skill library (.md prompt files) you did not write and probably have not read. That is a lot of trust to extend to a project that is, at the time of this writing, a few months old. I think this was a cool thing to have built and shared. The AI wakes up and acts without being prompted? genuinely interesting. But interesting and ready to run on my machine with access to my accounts are two different things.

So what is here that I can’t roll on my own? A lot if I needed everything it does. But I don’t and likely nobody needs everything it does.

So here is what I decided to build…

The stack is not exotic. A Slack Bolt app handles the interface. I already live in Slack, so there is no new surface to learn. It’s on my phone and my desktop. LM Studio runs a local model (OpenAI GPT OSS 20b is my go-to), which means nothing leaves my machine. A set of tools I wrote myself covers the things I actually need: summarizing my email, checking my calendar, updating a task list, flipping a few switches in the Home App. Cron jobs handle the proactive piece. The AI sends me a morning briefing, monitors a few things I care about, nudges me when something needs attention. Obsidian, which I was already using, acts as the memory layer. Context gets written out as Markdown files the same way I was already taking notes.

The whole thing took a weekend to get working and another weekend to get working well. Claude wrote a lot of it.

What I gave up compared to OpenClaw is a lot I guess. I do not have fifty integrations. I cannot talk to it over WhatsApp (but I only use that to talk to the school parents group anyway). The skills marketplace is just me, adding tools when I need them. For some people that trade-off would not be worth it. If you want a robot assistant that can do almost anything out of the box, OpenClaw is probably right for you and you should read their security documentation carefully before you set it up.

But I do not need fifty integrations. I need maybe eight. And the eight I have, I understand completely. I know exactly what they can do and what they cannot. There is no surface in my setup for a malicious skill to land on because there is no skill marketplace. The blast radius of something going wrong is small and I can see it clearly.

If you want to do something similar, the pieces are all there. Slack Bolt, LM Studio, cron, and whatever note-taking app you already use as a memory layer. The interesting part is not the plumbing. The interesting part is deciding what you actually want it to do. You also get to do a fun project.

That doesn’t happen as much for me now. I still love music, but I just don’t have time to get out to shows these days. So I end up relying on KCRW (which is excellent if you don’t listen to them) and streaming recommendations (which are fine). I miss that feeling of finding a small local unsigned (possibly not even on Apple Music yet) band who managed to get on the bill with a band who is signed.

So I built bands.standardpixel.com.

Give it a band or artist name and it maps out the bands they have shared a bill with. The theory is: independent bands have more say in who they tour with. When a festival organizer books around an artist you love, they are making a curatorial choice. These are human decisions, not statistical ones. Not better, but different. Another way of finding.

It is not perfect. Plenty of bands end up on the same bill for reasons that have nothing to do with sound. But hey, it’s good enough for rock and roll.

Under the hood it is built with Next.js and pulls data from MusicBrainz, which is a gem of a data source. When you search for an artist, a Python script queries the MusicBrainz API to find touring relationships, then caches the results in PostgreSQL so you are not waiting two minutes every time someone searches for a band. A WebSocket connection gives you real-time progress while it works. MusicBrainz is generous but it can take time to query within their rate limit. This allows me to keep the user updated on progress and I respectfully get data from MusicBrainz.

The results come back as a network graph you can explore, with Apple Music players embedded so you can listen immediately to what you find (if they are on there). Each artist gets a shareable URL so if you find something good you can pass it along.

I can tackle 1-3 bug fix, prototype, or otherwise simple tasks concurrently (sometimes up to 5 for straightforward work). After months of working with this I realized opening Zed automatically was just a security blanket. Removed it from the automation - now I only launch it with !zed . from Claude’s prompt when actually needed.

This lets me keep all concurrent worktrees visible on screen. It can be draining to context-switch between multiple AI-assisted tasks. The tricky part is predicting which tasks work well in this “AI batch mode” vs requiring traditional focused coding. Some tickets that look simple need deep architectural thinking, while complex-seeming ones are just tedious work Claude handles beautifully.

Still learning how to describe and categorize work by AI-suitability rather than just complexity and communicate this to stakeholders.