Quevin Bot Is Actually Running Now

In February I wrote about building a personal AI agent with OpenClaw — Docker on an old MacBook, Telegram integration, Claude Sonnet as the model, memory that barely worked, and cautious optimism.

A month later, almost none of that is the same.

The Site Got a Redesign

I didn’t plan this one. I started the year with a working but dated personal site — the kind you build once and stop looking at. At some point I sat down with Claude Code and said: let’s do it.

Claude Code handled the bulk of the conversion. Existing content in, Astro-based structure out, deployed on Cloudflare Pages. I made the architectural decisions, directed the edge cases, fixed the things that required understanding what the old system was doing. Claude handled the transformation work — component scaffolding, frontmatter schema, redirect mapping, the mechanical parts that would have taken me a full weekend alone.

The result is what you’re reading now. Faster, cleaner, and something I’m glad to share.

One pattern keeps proving itself: Claude Code performs markedly better when you spend twenty minutes writing a clear brief before you start, versus diving in with a vague instruction. The effort up front compounds through the whole session.

Off Docker, On macOS

I moved off Docker entirely.

Running OpenClaw in a container works, but it’s friction at every turn. The docs assume native install. The tooling assumes native install. Every troubleshooting step starts with “run this command” and ends with me translating it into a Docker exec invocation. Not wrong — just unnecessary overhead.

The native OpenClaw binary runs directly on my MacBook Pro now. The difference is immediate. The gateway starts and stops with a command. Skills install the way the docs say they will. No more fighting the environment.

The tradeoff: “always on” depends on the laptop being on, which mine usually is. If I needed true persistence I’d move to a server. For now, the MacBook is enough with caffeinate -i running when I want it to stay active.

iMessage and WhatsApp

Getting Quevin Bot onto my phone was the goal from the beginning. Telegram worked, but Telegram is where I check groups. iMessage is where I actually communicate. WhatsApp is how I stay in touch with people outside the US.

iMessage integration runs through BlueBubbles, an open-source project that bridges iMessage to a REST API. You need a Mac running as a BlueBubbles server, and you connect OpenClaw to it as a skill. Some configuration, but it works. I now iMessage Quevin Bot from my phone the same way I’d iMessage anyone else.

The first time I did this — sitting on the couch, sent a message to my own agent, got a useful response with full context about my projects — was genuinely strange. Not uncanny valley strange. More like: this is the thing I was trying to build, and it works, and I wasn’t sure it would.

WhatsApp followed a similar path. Different integration, same end result.

Phone access changes the usage pattern fundamentally. I’m not reaching for it only when I’m at a laptop. I can ask it something while I’m making coffee. That sounds trivial. In practice, it’s the difference between a tool and a habit.

What It Has Access To Now

Since February, the surface area has expanded:

Calendar. Read access to my calendar. Immediately useful for the things I always forgot to check: schedule conflicts, the week ahead, recurring meeting times.

File system. Scoped to the workspace and the quevin.com repo. The agent reads, creates, and edits files in those directories. It used this access to read my existing posts before writing this one.

Email. Via Himalaya, a CLI email client talking IMAP/SMTP to iCloud Mail. Read and send. It tells me what’s in my inbox without me opening mail — more useful than I expected — and it can send on my behalf when I ask it to. Fast search still goes through Fruitmail, which queries Mail.app’s local SQLite database in milliseconds instead of iterating via AppleScript.

Image generation. A skill calls Gemini’s image generation model, saves the result, and uploads it to R2. The hero image on this post was generated by the agent from a prompt I gave it, then uploaded automatically as part of the workflow that produced this draft.

Claude Code. OpenClaw has a Claude Code plugin that lets the agent invoke Claude Code as a tool. This is the self-improvement loop: the agent can write and refine its own skills, harden its own security configuration, audit its workspace files, and fix its own tool integrations — all through Claude Code sessions it initiates itself. Day-to-day, the bot runs on Claude Sonnet 4.6 to keep API costs and rate limits manageable. But when it hits something that needs deeper reasoning — rewriting a skill, auditing permissions, debugging a complex integration — it escalates to Claude Code running Opus. That separation matters: Sonnet handles the conversational volume, Opus handles the hard problems, and I’m not burning through rate limits on my Anthropic key every time I ask what’s on my calendar.

The security posture from February holds: read before write, scoped access, no public-facing ports. Each new integration proved itself before the next one got wired up.

The Meta Part

This post was drafted by the agent.

The agent read my previous posts, understood the brief I gave it, and produced a draft in my voice that I then edited. The hero image was generated by the same process. The commit to the repository was made by the agent.

I’m the author in the meaningful sense — I set the direction, edited the draft, and I’m responsible for what’s published. But the agent did the heavy lifting, using access to my files and my voice as source material.

The interesting question isn’t “did AI write this” — it’s “would I have published something worse or nothing at all without it.” I have a backlog of posts I’ve meant to write. This one happened because the friction was lower.

What’s Still Rough

Memory remains the core problem. The agent wakes up fresh each session, reads a set of files to reconstruct context, and does a reasonable job. But it’s reconstruction, not continuity. I notice the seams. I’ve explained the same thing about my infrastructure across sessions without the agent connecting them the way a person would.

The daily log system helps. The long-term memory file helps more. But capturing the right things at the right level of compression is ongoing work. The mechanism exists. Using it well is a habit I’m still building.

Reliability is the other open question. If the MacBook sleeps, the gateway stops. If a skill has a bug, it fails silently. Both are solvable — a server handles sleep, better logging handles tracing — but I haven’t prioritized them yet. What I have works well enough for a side project.

Where This Goes

The roadmap from February evolves. The Jira ticket quality agent will wait. The documentation-driven code review remains. The Asana-to-Jira intake bridge is on hold, because we can’t use this at work yet. This is hobby-level fun.

But the immediate priority is using what I’ve built. The site is redesigned. The agent is on my phone. It has real access to real things. The experiment is no longer aspirational — it’s operational.

What I want to figure out next is the daily rhythm over a sustained period. Not “what’s possible” — I have that picture. But “what do I actually reach for, and what turns out not to matter.” That takes time and real use, not more setup.