Why I dropped OpenClaw for a smaller agent runtime

The initial OpenClaw craze was incredible to experience and be a part of. My main agent Otto ran on it daily via Discord, and his personality and memory were stored in OpenClaw workspace files.

Unfortunately, the project itself was very unstable and very difficult to untangle and patch when issues came out and keep parity with the mainline. Their release cycle and testing strategy got increasingly burdensome for me as new features were gated behind upgrades that were sure to break things.

Reapers and memory caps

The most glaring example of this was a memory leak. A plugin would continue to spawn agent sessions and never clean them up. After 19 hours, I had 1,163 orphaned processes eating 43 GB of RAM on a server sitting at 30 of 31 GB used. The upstream fix to implement session time limits is still an open issue. I contained it by putting a hard memory cap on the service and writing a reaper on a 10-minute timer that killed processes like these older than 30 minutes. It worked, but I couldn’t help but wonder if I’d fixed anything or if I’d just built a fence around it.

Upgrades weren’t any easier. I had four different versions of OpenClaw over the course of ten days or so. One didn’t like my existing streaming configuration because the schema had changed underneath. Another had a plugin that flatly refused to load, even though the service was still reporting the old version number.

So I patched my way forward. I wanted to use Gemini on Google Vertex, but OpenClaw’s Vertex provider was just an alias for the regular Gemini one, which was making requests to a URL that returned a 404. So I wrote my own provider plugin. That was maybe 250 lines of code and four hours of work. Then all three of my model fallbacks broke at the same time, so I emptied out the fallback chain and made the failures loud. Each fix kept me on a platform that needed the next fix.

If you spend more time fixing your automation and harnesses than enjoying what they can do to automate your life, sometimes you need to take a step back and evaluate what you’re running.

One migration day

Thankfully I came upon NanoClaw, which is a smaller project and a very lightweight runtime (also extremely easy to modify), and so far I have been really happy with it.

The migration itself took me one day (about five hours of work). I took inventory of what I had set up in OpenClaw (five scheduled jobs, all of which were already failing.. a clear sign that I was spending more time keeping the old platform alive than actually using it). I wired 11 Discord channels to Otto, merged the separate personality and memory files into a single memory file, and made the changes in my public fork.. the same framework I described in Always be curious.

Each agent in its own container

Each agent group is its own container with its own memory and tools, so adding “Sentinel” weeks later didn’t touch my main agent “Otto”. This security isolation is indeed a huge feature: agents running in containers with specific grants to the things they need only, and strict agent-to-agent allowlists as well. And when something broke I could fix it in my fork instead of wrapping fixes in reapers and memory caps.

I applied the same thinking to notes: Otto has a read-only vault mount, with one writable inbox folder beneath it. The inbox-only write rule is enforced by the filesystem, not just instructions. An agent can only reach another agent through a deliberately wired link.

I could also interact with a smaller community via Discord and found the community behind it was really intelligent, not only from a forward-thinking agentic perspective but from a security and operations perspective.

Building on it

I have built a memory layer based on OKF (Open Knowledge Format) and continue to build on top of NanoClaw. My custom agent runtime leverages Claude Code containerized in tmux sessions with a custom messaging bridge, roles and tools, and it has been very stable. Now that I also integrated Codex and Gemini agents into the fold, a few more specialist agents and further stability enhancements and quality of life improvements are on the horizon.

Before NanoClaw, I used Memento as my agent memory, which is just my Markdown notes in Obsidian. I’m still using plain Markdown for my OKF layer, but each agent group now has its own memory tree, with one concept per file. Next up: Sentinel, the agent that watches my infra.